From java at stefan-marr.de Tue Oct 1 06:31:55 2013 From: java at stefan-marr.de (Stefan Marr) Date: Tue, 1 Oct 2013 15:31:55 +0200 Subject: [Truffle] Generated type system overrides isObject()/asObject() methods. Message-ID: <5F73CC9C-FE29-4848-99F8-BBAB97EC81F0@stefan-marr.de> Hi: In order to use return-type specialization for TruffleSOM, I extended the TypeSystem [1] to include more than 'som.Object'. My first experiment using it is to introduce typed literal nodes with specialized methods for the native type. However, I ran into some issues and would like to verify whether I am understanding the ideas behind it correctly. The type system now includes the native Java types for the literals that map directly to them, and the SOM Object type (int, BigInteger, double, String, boolean, som.Object). For each of these types I created TypeChecks and TypeCasts that basically are supposed to pair up native types and their wrapped counter parts, for example int and som.Integer. That seems to work well, and the generated TypeSystem does look ok. However, then I added `boolean isObject(j.l.Object)` and `som.Object asObject(j.l.Object)` to the type system, and the generated type system overrides these methods. [I tried to mark the methods as final, but that doesn't prevent the code generator from creating the unadapted variants. It leads just to a compilation error because of the overrides.] The intent of the TypeCast function asObject(.) on line 151 [2] was to convert between the unboxed native types and the SOM object types as necessary. But since the generated type system class includes a generic version of this TypeCast, I am wondering whether that is the correct approach. When finally implementing the specialized literal nodes, I got the feeling that it should indeed be possible to customize the asObject TypeCast, because the generated specialized literal nodes had generated `executeGeneric(frame)` functions, which seemed to do the right thing if my TypeCast would have been preserved. But with the generic TypeCast in place, I had to work around it, and for instance for my string literal node, I needed to implement a custom `executeGeneric(frame)` function (cf. line 19 in [3]). Comparing the generic with my custom execute methods shows that the custom one is probably a little more efficient, but it feels like I am working a bit against the framework and thus, I am wondering whether it is the correct approach. So, my general questions is whether I am using the type system correct, i.e., is the intent to use it to map unboxed and boxed types as in my case. And furthermore, whether there is a design reason to provide a generic type cast for `asObject()` that prevents custom versions of it. Thanks Stefan [1] https://github.com/smarr/TruffleSOM/blob/master/src/som/interpreter/Types.java [2] https://github.com/smarr/TruffleSOM/blob/master/src/som/interpreter/Types.java#L151 [3] https://github.com/smarr/TruffleSOM/blob/master/src/som/interpreter/nodes/literals/StringLiteralNode.java#L19 -- 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 Tue Oct 1 09:02:54 2013 From: christian.humer at gmail.com (Christian Humer) Date: Tue, 1 Oct 2013 18:02:54 +0200 Subject: [Truffle] Generated type system overrides isObject()/asObject() methods. In-Reply-To: <5F73CC9C-FE29-4848-99F8-BBAB97EC81F0@stefan-marr.de> References: <5F73CC9C-FE29-4848-99F8-BBAB97EC81F0@stefan-marr.de> Message-ID: Hi Stefan, As a workaround please do not use class names that are already used in the java.lang package because the code generator currently produces erroneous code for them. (i am working on a fix for that) This should also solve the described conflict with asObject(). The @TypeCast and @TypeCheck annotations should not be used to customize the boxing behavior of a type. It is currently not possible to define custom boxing for primitive types in the TypeSystem. But this is on my TODO list for the next weeks. The current workaround for boxing is to define primitive types and boxed types in the type system and specialize for each type separately. There is also an experimental feature called implicit casts which could help you with a workaround. However I think you should first think about which kind of specializations you want implement and then think about the actual types you will have to use. I would recommend to start with generic versions of your operations and then specialize/optimize your operations step by step. Could you briefly introduce or point me to some operations/nodes you want to optimize? Its also possible that Truffle-DSL is not the right tool for you. Your definition of the literal nodes do not require a method with the @Specialization annotation. Just implementing the execute methods should be fine since they are already stable (they do not specialize anymore) after parsing. (This can also be done the simple language [1], I will change that) [1] http://hg.openjdk.java.net/graal/graal/file/aeeab846e98c/graal/com.oracle.truffle.sl/ - Christian Humer On Tue, Oct 1, 2013 at 3:31 PM, Stefan Marr wrote: > Hi: > > In order to use return-type specialization for TruffleSOM, I extended the > TypeSystem [1] to include more than 'som.Object'. My first experiment using > it is to introduce typed literal nodes with specialized methods for the > native type. > > However, I ran into some issues and would like to verify whether I am > understanding the ideas behind it correctly. > > The type system now includes the native Java types for the literals that > map directly to them, and the SOM Object type (int, BigInteger, double, > String, boolean, som.Object). > > For each of these types I created TypeChecks and TypeCasts that basically > are supposed to pair up native types and their wrapped counter parts, for > example int and som.Integer. > That seems to work well, and the generated TypeSystem does look ok. > However, then I added `boolean isObject(j.l.Object)` and `som.Object > asObject(j.l.Object)` to the type system, and the generated type system > overrides these methods. [I tried to mark the methods as final, but that > doesn't prevent the code generator from creating the unadapted variants. It > leads just to a compilation error because of the overrides.] > > The intent of the TypeCast function asObject(.) on line 151 [2] was to > convert between the unboxed native types and the SOM object types as > necessary. But since the generated type system class includes a generic > version of this TypeCast, I am wondering whether that is the correct > approach. > > When finally implementing the specialized literal nodes, I got the feeling > that it should indeed be possible to customize the asObject TypeCast, > because the generated specialized literal nodes had generated > `executeGeneric(frame)` functions, which seemed to do the right thing if my > TypeCast would have been preserved. > But with the generic TypeCast in place, I had to work around it, and for > instance for my string literal node, I needed to implement a custom > `executeGeneric(frame)` function (cf. line 19 in [3]). > Comparing the generic with my custom execute methods shows that the custom > one is probably a little more efficient, but it feels like I am working a > bit against the framework and thus, I am wondering whether it is the > correct approach. > > So, my general questions is whether I am using the type system correct, > i.e., is the intent to use it to map unboxed and boxed types as in my case. > And furthermore, whether there is a design reason to provide a generic > type cast for `asObject()` that prevents custom versions of it. > > Thanks > Stefan > > > > [1] > https://github.com/smarr/TruffleSOM/blob/master/src/som/interpreter/Types.java > [2] > https://github.com/smarr/TruffleSOM/blob/master/src/som/interpreter/Types.java#L151 > [3] > https://github.com/smarr/TruffleSOM/blob/master/src/som/interpreter/nodes/literals/StringLiteralNode.java#L19 > -- > 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 Oct 1 10:41:30 2013 From: java at stefan-marr.de (Stefan Marr) Date: Tue, 1 Oct 2013 19:41:30 +0200 Subject: [Truffle] Generated type system overrides isObject()/asObject() methods. In-Reply-To: References: <5F73CC9C-FE29-4848-99F8-BBAB97EC81F0@stefan-marr.de> Message-ID: <26C40E19-0E50-4852-B171-5F999F5ACB61@stefan-marr.de> Hi Christian: On 01 Oct 2013, at 18:02, Christian Humer wrote: > As a workaround please do not use class names that are already used in the java.lang package because the code generator currently produces erroneous code for them. (i am working on a fix for that) > This should also solve the described conflict with asObject(). I already experimented with renaming som.Object to SOMObject, and ran into another issue. The generated `expectSOMObject()` is throwing the UnexpectedResultException in a generated `executeGeneric()` method. And that exception remains unhanded. So, well, again, out of luck. More below. > The @TypeCast and @TypeCheck annotations should not be used to customize the boxing behavior of a type. It is currently not possible to define custom boxing for primitive types in the TypeSystem. But this is on my TODO list for the next weeks. > The current workaround for boxing is to define primitive types and boxed types in the type system and specialize for each type separately. There is also an experimental feature called implicit casts which could help you with a workaround. Ok, for my understanding: What is the intent of the TypeSystem? Which kind of types should it contain? And, how do the types related to each other? One thing that I am a little confused about is that the generated code does not seem to have any notion of type hierarchy or so. While there are indications in the TypeSystem comments, that the list should indicate some order, and that a subtype should go before a super type (if I recall correctly), my SOMObject class does not seem to be recognized as the root type. Consequently, the UnexpectedResultException is thrown in a situation where it should never happen. If I try to think about what I would want to write down in the TypeSystem, I would probably want to indicate a mapping between box and unbox types as well as the root type. That way, I imagine, `expectSOMObject()` would always succeed, because the SOM language has one root type (Object) and does not allow for any other kind of things outside that hierarchy. [I guess for languages such as Java, the TypeSystem definition would need to allow for different things.] At the moment, my understanding is rather that the TypeSystem contains a list of types for which operations can be specialized. (That's derived from your comment above.) > However I think you should first think about which kind of specializations you want implement and then think about the actual types you will have to use. I would recommend to start with generic versions of your operations and then specialize/optimize your operations step by step. > Could you briefly introduce or point me to some operations/nodes you want to optimize? > Its also possible that Truffle-DSL is not the right tool for you. Well, in general, TruffleSOM is functional. So, I don't plan to implement any new 'generic operations'. My current goal is to get it fast, and to make the compilation on top of Graal work properly. [I still haven't sorted out my VirtualFrame escaping issues, had hope some specialization could make the partial evaluator a little happier.] With fast, I mean, I want a TruffleSOM that is as fast as the C++-based SOM interpreter, and ideally as fast as the PyPy/RPython-based SOM. But I am still way off of that. To get there, I envision I need to specialize at the very least for integers: - access to frame slots (guided by SimpleLanguage's Read/WriteLocalNode) - message sends (I already got a monomorphic/polymorphic/megamorphic message nodes and started experimentation with inlining of monomorphic messages. I also bit the bullet an added a nodes for IfTrue/IfFalse messages on booleans) - primitives The primitives (addition, subtraction, array access operations, etc, e.g. [1]) are I think the most important issue right now. At the moment, their implementation uses a couple of indirections that are probably not really helping the optimizer to remove any overhead. So, what I envision is that all primitives for addition should become a truffle node with the various specializations. A SOM method would than refer to just the truffle node implementing that primitive, instead of being something custom made. With the inlining functionality, I should be able to get monomorphic message sends to primitives closer to optimal performance. But to get there, I was first trying to understand the specialization techniques provided by Truffle better, and how the TypeSystem fits in there. Because, so far I ran into a lot of dead ends. Thanks for the help Stefan [1] https://github.com/smarr/TruffleSOM/blob/master/src/som/primitives/IntegerPrimitives.java -- 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 thomas.wuerthinger at oracle.com Tue Oct 1 12:40:18 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Tue, 1 Oct 2013 21:40:18 +0200 Subject: [Truffle] Generated type system overrides isObject()/asObject() methods. In-Reply-To: <26C40E19-0E50-4852-B171-5F999F5ACB61@stefan-marr.de> References: <5F73CC9C-FE29-4848-99F8-BBAB97EC81F0@stefan-marr.de> <26C40E19-0E50-4852-B171-5F999F5ACB61@stefan-marr.de> Message-ID: Stefan, Based on the results we are seeing on Truffle/Ruby versus Topaz, we expect that TruffleSOM will be able to outperform the PyPy version. Before introducing the type system for specialisations, we should check that the Truffle-level inlining works as expected and frame materialisation is avoided wherever possible. We'll take a look at running some of your examples. Do you have a particular one we should look at first? - thomas On Oct 1, 2013, at 7:41 PM, Stefan Marr wrote: > Hi Christian: > > On 01 Oct 2013, at 18:02, Christian Humer wrote: > >> As a workaround please do not use class names that are already used in the java.lang package because the code generator currently produces erroneous code for them. (i am working on a fix for that) >> This should also solve the described conflict with asObject(). > > I already experimented with renaming som.Object to SOMObject, and ran into another issue. > The generated `expectSOMObject()` is throwing the UnexpectedResultException in a generated `executeGeneric()` method. > And that exception remains unhanded. So, well, again, out of luck. > > More below. > >> The @TypeCast and @TypeCheck annotations should not be used to customize the boxing behavior of a type. It is currently not possible to define custom boxing for primitive types in the TypeSystem. But this is on my TODO list for the next weeks. >> The current workaround for boxing is to define primitive types and boxed types in the type system and specialize for each type separately. There is also an experimental feature called implicit casts which could help you with a workaround. > > Ok, for my understanding: What is the intent of the TypeSystem? Which kind of types should it contain? And, how do the types related to each other? > > One thing that I am a little confused about is that the generated code does not seem to have any notion of type hierarchy or so. While there are indications in the TypeSystem comments, that the list should indicate some order, and that a subtype should go before a super type (if I recall correctly), my SOMObject class does not seem to be recognized as the root type. Consequently, the UnexpectedResultException is thrown in a situation where it should never happen. > > If I try to think about what I would want to write down in the TypeSystem, I would probably want to indicate a mapping between box and unbox types as well as the root type. That way, I imagine, `expectSOMObject()` would always succeed, because the SOM language has one root type (Object) and does not allow for any other kind of things outside that hierarchy. [I guess for languages such as Java, the TypeSystem definition would need to allow for different things.] > > At the moment, my understanding is rather that the TypeSystem contains a list of types for which operations can be specialized. (That's derived from your comment above.) > > >> However I think you should first think about which kind of specializations you want implement and then think about the actual types you will have to use. I would recommend to start with generic versions of your operations and then specialize/optimize your operations step by step. >> Could you briefly introduce or point me to some operations/nodes you want to optimize? >> Its also possible that Truffle-DSL is not the right tool for you. > > Well, in general, TruffleSOM is functional. So, I don't plan to implement any new 'generic operations'. My current goal is to get it fast, and to make the compilation on top of Graal work properly. > > [I still haven't sorted out my VirtualFrame escaping issues, had hope some specialization could make the partial evaluator a little happier.] > > With fast, I mean, I want a TruffleSOM that is as fast as the C++-based SOM interpreter, and ideally as fast as the PyPy/RPython-based SOM. But I am still way off of that. > > To get there, I envision I need to specialize at the very least for integers: > - access to frame slots (guided by SimpleLanguage's Read/WriteLocalNode) > - message sends (I already got a monomorphic/polymorphic/megamorphic message nodes and started experimentation with inlining of monomorphic messages. I also bit the bullet an added a nodes for IfTrue/IfFalse messages on booleans) > - primitives > > The primitives (addition, subtraction, array access operations, etc, e.g. [1]) are I think the most important issue right now. At the moment, their implementation uses a couple of indirections that are probably not really helping the optimizer to remove any overhead. > So, what I envision is that all primitives for addition should become a truffle node with the various specializations. > A SOM method would than refer to just the truffle node implementing that primitive, instead of being something custom made. With the inlining functionality, I should be able to get monomorphic message sends to primitives closer to optimal performance. > But to get there, I was first trying to understand the specialization techniques provided by Truffle better, and how the TypeSystem fits in there. Because, so far I ran into a lot of dead ends. > > Thanks for the help > Stefan > > [1] https://github.com/smarr/TruffleSOM/blob/master/src/som/primitives/IntegerPrimitives.java > > -- > 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 thomas.wuerthinger at oracle.com Tue Oct 1 12:51:30 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Tue, 1 Oct 2013 21:51:30 +0200 Subject: volatile read and writes In-Reply-To: References: Message-ID: <65977F33-69EC-4A01-93F1-3F798A7FD007@oracle.com> Daniel, You can consider customising the code in HotSpotRuntime for Aarch64 that creates the memory barrier pattern for volatile loads/stores. Currently we create pre- and post-barriers for both volatile loads and stores. We could consider making the kind of nodes introduced dependent on the platform. - thomas On Sep 29, 2013, at 12:55 AM, D.Sturm wrote: > The Aarch64 ISA allows to fold most memory barriers into special load and > store instructions - similar to IA64. That means we can get away with only > explicitly generating StoreLoad barriers and use load-acquire/store-release > for volatile read/writes and when publishing newly constructed objects with > final fields. > > What is the best approach for getting this information when generating > load/stores or maybe during a peephole optimization? > > There's a lastLocationAccess for the FloatingReadNode which should point to > a MembarNode if it's a volatile read (and there's a next field for > storenodes which should do the same), but that seems rather fragile. > > > - Daniel From java at stefan-marr.de Tue Oct 1 13:57:52 2013 From: java at stefan-marr.de (Stefan Marr) Date: Tue, 1 Oct 2013 22:57:52 +0200 Subject: [Truffle] Generated type system overrides isObject()/asObject() methods. In-Reply-To: References: <5F73CC9C-FE29-4848-99F8-BBAB97EC81F0@stefan-marr.de> <26C40E19-0E50-4852-B171-5F999F5ACB61@stefan-marr.de> Message-ID: Hi Thomas: On 01 Oct 2013, at 21:40, Thomas Wuerthinger wrote: > Based on the results we are seeing on Truffle/Ruby versus Topaz, we expect that TruffleSOM will be able to outperform the PyPy version. Sounds promising. > Before introducing the type system for specialisations, we should check that the Truffle-level inlining works as expected and frame materialisation is avoided wherever possible. We'll take a look at running some of your examples. Do you have a particular one we should look at first? Well, that's where I am stuck. I am not yet making the toolchain happy with my use of VirtualFrames. Here the steps to check out a concrete version: git clone --recursive https://github.com/smarr/TruffleSOM.git cd TruffleSOM git checkout 1f6c74149f17b888094f6a953a854a32d83705f2 ant tests This is using the latest, unmodified Graal code. In my Graal folder, I can then execute the following: export SOM=/Users/smarr/Projects/SOM/TruffleSOM ./mx.sh --vm server vm -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/Loop.som So, my problems start with: "Frame escapes at: [?] ExpressionNode.executeGeneric(VirtualFrame)". Any other of the benchmarks results in the same, I think. On the branch 'poc/constant-args-and-temps', I tried to get rid of the materialization of the frame during initializing it, but that didn't had a lot of success. Get the branch with: `git checkout -b const origin/poc/constant-args-and-temps` The main commit is [1]. So, well, if you got suggestions how to approach these escaped frames, I would be more than happy to try something new. Thanks Stefan [1] https://github.com/smarr/TruffleSOM/commit/8be69f33677dd7738d3e437cd74e4f1d151f09da -- 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 Oct 2 07:29:59 2013 From: christian.humer at gmail.com (Christian Humer) Date: Wed, 2 Oct 2013 16:29:59 +0200 Subject: Truffle-DSL: API cleanup. Message-ID: Hey folks, I am considering a few removals from the Truffle-DSL API package truffle.api.dsl. Annotation - Reason @NodeContainer - Enables minor code sugar for declaring multiple operations within one class but introduces a lot of complexity. @NodeId - Only required to disambiguate some cases in classes with @NodeContainer. @SpecializationListener - Same as putting some code in the copy constructor of the node. As far as I know these annotations are barely ever used. However if you are using it, please let me know so I can work out a migration strategy for you. - Christian Humer From D.Sturm42 at gmail.com Wed Oct 2 09:58:54 2013 From: D.Sturm42 at gmail.com (D.Sturm) Date: Wed, 2 Oct 2013 18:58:54 +0200 Subject: volatile read and writes In-Reply-To: <65977F33-69EC-4A01-93F1-3F798A7FD007@oracle.com> References: <65977F33-69EC-4A01-93F1-3F798A7FD007@oracle.com> Message-ID: Thanks Thomas, yes I see where that would be changed. One alternative to introducing additional methods (for read/write) that can be overwritten by subclasses if they want custom behavior would be to just add a boolean "isVolatile" field to the WriteNode/ReadNode/FloatingReadNode nodes. Looking at the layout of those classes the additional boolean field would be for "free" i.e. just fill up some of the padding, so it wouldn't cost extra memory for architectures that don't need that information. The unnecessary memory barriers get just ignored in the LIRGenerator so no problem there. Would avoid having to subclass the nodes and then handling the different classes in the LIR generator. -Daniel On 1 October 2013 21:51, Thomas Wuerthinger wrote: > Daniel, > > You can consider customising the code in HotSpotRuntime for Aarch64 that > creates the memory barrier pattern for volatile loads/stores. Currently we > create pre- and post-barriers for both volatile loads and stores. We could > consider making the kind of nodes introduced dependent on the platform. > > - thomas > > On Sep 29, 2013, at 12:55 AM, D.Sturm wrote: > > > The Aarch64 ISA allows to fold most memory barriers into special load and > > store instructions - similar to IA64. That means we can get away with > only > > explicitly generating StoreLoad barriers and use > load-acquire/store-release > > for volatile read/writes and when publishing newly constructed objects > with > > final fields. > > > > What is the best approach for getting this information when generating > > load/stores or maybe during a peephole optimization? > > > > There's a lastLocationAccess for the FloatingReadNode which should point > to > > a MembarNode if it's a volatile read (and there's a next field for > > storenodes which should do the same), but that seems rather fragile. > > > > > > - Daniel > > From thomas.wuerthinger at oracle.com Wed Oct 2 13:31:13 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Wed, 2 Oct 2013 22:31:13 +0200 Subject: volatile read and writes In-Reply-To: References: <65977F33-69EC-4A01-93F1-3F798A7FD007@oracle.com> Message-ID: <940F3F10-2965-4D6A-9B7A-F364C12CE875@oracle.com> The memory barriers are currently necessary to also ensure the ordering of volatile loads and normal loads [1]. We should still consider changing the system later, but for now it would be best if you can implement your volatile accesses according to the existing architecture so we get a complete picture of requirements. Thanks, thomas [1] http://g.oswego.edu/dl/jmm/cookbook.html On Oct 2, 2013, at 6:58 PM, D.Sturm wrote: > Thanks Thomas, yes I see where that would be changed. One alternative to introducing additional methods (for read/write) that can be overwritten by subclasses if they want custom behavior would be to just add a boolean "isVolatile" field to the WriteNode/ReadNode/FloatingReadNode nodes. Looking at the layout of those classes the additional boolean field would be for "free" i.e. just fill up some of the padding, so it wouldn't cost extra memory for architectures that don't need that information. The unnecessary memory barriers get just ignored in the LIRGenerator so no problem there. Would avoid having to subclass the nodes and then handling the different classes in the LIR generator. > > -Daniel > > > On 1 October 2013 21:51, Thomas Wuerthinger wrote: > Daniel, > > You can consider customising the code in HotSpotRuntime for Aarch64 that creates the memory barrier pattern for volatile loads/stores. Currently we create pre- and post-barriers for both volatile loads and stores. We could consider making the kind of nodes introduced dependent on the platform. > > - thomas > > On Sep 29, 2013, at 12:55 AM, D.Sturm wrote: > > > The Aarch64 ISA allows to fold most memory barriers into special load and > > store instructions - similar to IA64. That means we can get away with only > > explicitly generating StoreLoad barriers and use load-acquire/store-release > > for volatile read/writes and when publishing newly constructed objects with > > final fields. > > > > What is the best approach for getting this information when generating > > load/stores or maybe during a peephole optimization? > > > > There's a lastLocationAccess for the FloatingReadNode which should point to > > a MembarNode if it's a volatile read (and there's a next field for > > storenodes which should do the same), but that seems rather fragile. > > > > > > - Daniel > > From Vasanth.Venkatachalam at amd.com Wed Oct 2 13:48:12 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Wed, 2 Oct 2013 20:48:12 +0000 Subject: questions about decoupling GPU target runtimes from host runtime Message-ID: <5DD1503F815BD14889DC81D28643E3A73F919C2C@SATLEXDAG02.amd.com> Doug- We're scoping out the changes needed to isolate the GPU target runtimes (HSAIL, PTX) from the host runtime, so that the host runtime (e.g., AMD64HotspotRuntime) does not get instantiated when we generate code for HSAIL or PTX. This is in part intended to address the comments you sent in sent about http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-r15changes/webrev/ (forwarded below). We had some questions below. 1) All of the platform-specific runtime classes defined so far (PTXHotSpotRuntime, AMD64HotSpotRuntime) are subclassing HotSpotRuntime, which implements the CodeCacheProvider interface. If we understood you correctly, the GPU target runtimes (PtX, HSAIL) should not subclass HotSpotRuntime, because in doing so they would be inheriting code that is HotSpot specfic and not relevant to the GPU target. They should instead be independent classes which extend the DelegatingCodeCacheProvider class and delegate to HotSpotRuntime any functionality that is not target GPU specific. Is this what you had in mind? 2) The routine graalRuntime( ) in graalVMToCompiler.cpp is checking to see if the UseGPU flag is enabled and if it is (and if the GPU target is PTX) it is instantiating PTXHotSpotGraalRuntime. It sounds like we need to add some logic to check if the GPU target is HSAIL and if so to instantiate the HSAIL runtime class. Am I on the right track? a. Can you send us the command line to use to check that the UseGPU functionality is working? When I run a PTX test case in NetBeans with -XX:+UseGPU the JVM crashes even before it gets to generate any code. 3) PTXHotSpotGraalRuntime is creating a PTXHotSpotBackend which looks similar to PTXBackend. What is the purpose of having both the PTXHotSpotBackend and a PTXBackend? It looks like these two classes are duplicating some functionality. Do we need to have an HSAILHotSpotBackend in addition to HSAILBackend? I have a similar question for PTXHotSpotRegisterConfiguration vs. PTXRegisterConfiguration. How should we deal with these pairs of classes in the refactoring you're recommending in 1)? It seems to me like these PTXHotspot* classes should go away if we're truly decoupling the GPU target runtimes from Hotspot. 4) Is there a reason why we need both PTXHotspotGraalRuntime in addition to PtXHotSpotRuntime instead of just having a single class that combines the work of both? Vasanth -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Wednesday, September 11, 2013 9:54 AM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: Re: webrev: workaround for threadRegister handling Hi Vasanth, I think you are tackling this problem at the wrong level. All the logic that uses threadRegister and stackPointerRegister is in snippets. The point of snippets is they are the interface the compiler uses to do runtime-specific lowering. I somehow very much doubt that the snippets using these registers will make any sense in the context of the GPU. Even if you plan on implementing new/newarray/monitorenter/monitorexit etc on the GPU, the code will be quite different than that for HotSpot's "host" runtime. After all, they are very specific to HotSpot data structures such as thread local allocation buffers, G1 barriers, etc. In my opinion, you need to have a GraalCodeCacheProvider implementation that does all the GPU specific lowering. To ensure you've got this separation right/complete, your GraalCodeCacheProvider subclass probably shouldn't even subclass HotSpotRuntime. -Doug From thomas.wuerthinger at oracle.com Thu Oct 3 00:04:32 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 3 Oct 2013 09:04:32 +0200 Subject: [Truffle] Generated type system overrides isObject()/asObject() methods. In-Reply-To: References: <5F73CC9C-FE29-4848-99F8-BBAB97EC81F0@stefan-marr.de> <26C40E19-0E50-4852-B171-5F999F5ACB61@stefan-marr.de> Message-ID: <5016C2B2-755E-49E6-B5E0-57AF89265BE6@oracle.com> Stefan, The recommended way to initialise local variables from arguments is via WriteLocalNode and ReadArgumentNode instances (one for each argument) that are added at the beginning of the method. This way the local variable can also be specialized on primitive type (and the FrameSlot can be a final field in the WriteLocalNode instance). There is one question I have about the determineContext and getSelfFromMaterialized methods. Could the self value be transmitted via an argument? The lookup over the chain of frames seems slow (and forces materialisation), so is there some other way one could pass these values? Could you describe the requirements for this self value in the system? Thanks, thomas On Oct 1, 2013, at 10:57 PM, Stefan Marr wrote: > Hi Thomas: > > On 01 Oct 2013, at 21:40, Thomas Wuerthinger wrote: > >> Based on the results we are seeing on Truffle/Ruby versus Topaz, we expect that TruffleSOM will be able to outperform the PyPy version. > > Sounds promising. > >> Before introducing the type system for specialisations, we should check that the Truffle-level inlining works as expected and frame materialisation is avoided wherever possible. We'll take a look at running some of your examples. Do you have a particular one we should look at first? > > Well, that's where I am stuck. I am not yet making the toolchain happy with my use of VirtualFrames. > > Here the steps to check out a concrete version: > > git clone --recursive https://github.com/smarr/TruffleSOM.git > cd TruffleSOM > git checkout 1f6c74149f17b888094f6a953a854a32d83705f2 > ant tests > > This is using the latest, unmodified Graal code. > > In my Graal folder, I can then execute the following: > > export SOM=/Users/smarr/Projects/SOM/TruffleSOM > ./mx.sh --vm server vm -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/Loop.som > > So, my problems start with: "Frame escapes at: [?] ExpressionNode.executeGeneric(VirtualFrame)". > Any other of the benchmarks results in the same, I think. > > On the branch 'poc/constant-args-and-temps', I tried to get rid of the materialization of the frame during initializing it, but that didn't had a lot of success. > > Get the branch with: `git checkout -b const origin/poc/constant-args-and-temps` > The main commit is [1]. > > So, well, if you got suggestions how to approach these escaped frames, I would be more than happy to try something new. > > Thanks > Stefan > > [1] https://github.com/smarr/TruffleSOM/commit/8be69f33677dd7738d3e437cd74e4f1d151f09da > > -- > 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 Thu Oct 3 01:02:55 2013 From: java at stefan-marr.de (Stefan Marr) Date: Thu, 3 Oct 2013 10:02:55 +0200 Subject: [Truffle] Generated type system overrides isObject()/asObject() methods. In-Reply-To: <5016C2B2-755E-49E6-B5E0-57AF89265BE6@oracle.com> References: <5F73CC9C-FE29-4848-99F8-BBAB97EC81F0@stefan-marr.de> <26C40E19-0E50-4852-B171-5F999F5ACB61@stefan-marr.de> <5016C2B2-755E-49E6-B5E0-57AF89265BE6@oracle.com> Message-ID: Hi Thomas: (cc Michael) On 03 Oct 2013, at 09:04, Thomas Wuerthinger wrote: > There is one question I have about the determineContext and getSelfFromMaterialized methods. Could the self value be transmitted via an argument? The lookup over the chain of frames seems slow (and forces materialisation), so is there some other way one could pass these values? Could you describe the requirements for this self value in the system? I guess `self` could be passed as an argument somehow, but I wouldn't know immediately how to get that right. What's called the context here is the lexical scope of a block/lambda, which is always defined within a particular method of an object. Thus, `self` is always the object on which the method was invoked, in which the block was defined. Now `self` is not the only issue here, I think. (I guess you are mostly thinking of getting rid of all materialized blocks.) The main issue is that nesting blocks happens quite often, and you want to be able to access the lexical scope. I am not entirely familiar with all the kind of possible techniques to avoid such 'materialization', but there are a couple of approaches in the Smalltalk world, for instance the one described by Eliot Miranda [1]. So, I could imagine that blocks get compiled into different variants depending on whether they actually access `self` or their outer contexts. This could avoid materialization for an interesting number of cases. Michael, you got some more insight into what might be possible here? Thanks Stefan [1] http://www.esug.org/data/Articles/misc/oopsla99-contexts.pdf -- 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 D.Sturm42 at gmail.com Thu Oct 3 03:05:06 2013 From: D.Sturm42 at gmail.com (D.Sturm) Date: Thu, 3 Oct 2013 12:05:06 +0200 Subject: volatile read and writes In-Reply-To: <940F3F10-2965-4D6A-9B7A-F364C12CE875@oracle.com> References: <65977F33-69EC-4A01-93F1-3F798A7FD007@oracle.com> <940F3F10-2965-4D6A-9B7A-F364C12CE875@oracle.com> Message-ID: Not sure I can follow you: Do you want me to not change the HotSpotRuntime class at all and just explicitly generate all those memory barriers for now? To clarify: ldar is "load; LoadLoad, LoadStore" while stlr is "LoadStore, StoreStore; store" so those cover everything but the post-volatile-write barriers from the cookbook and what graal does. The post-volatile-write StoreLoad barrier has to be explicitly generated in all cases. -Daniel On 2 October 2013 22:31, Thomas Wuerthinger wrote: > The memory barriers are currently necessary to also ensure the ordering of > volatile loads and normal loads [1]. We should still consider changing the > system later, but for now it would be best if you can implement your > volatile accesses according to the existing architecture so we get a > complete picture of requirements. > > Thanks, thomas > > [1] http://g.oswego.edu/dl/jmm/cookbook.html > > On Oct 2, 2013, at 6:58 PM, D.Sturm wrote: > > Thanks Thomas, yes I see where that would be changed. One alternative to > introducing additional methods (for read/write) that can be overwritten by > subclasses if they want custom behavior would be to just add a boolean > "isVolatile" field to the WriteNode/ReadNode/FloatingReadNode nodes. > Looking at the layout of those classes the additional boolean field would > be for "free" i.e. just fill up some of the padding, so it wouldn't cost > extra memory for architectures that don't need that information. The > unnecessary memory barriers get just ignored in the LIRGenerator so no > problem there. Would avoid having to subclass the nodes and then handling > the different classes in the LIR generator. > > -Daniel > > > On 1 October 2013 21:51, Thomas Wuerthinger > wrote: > >> Daniel, >> >> You can consider customising the code in HotSpotRuntime for Aarch64 that >> creates the memory barrier pattern for volatile loads/stores. Currently we >> create pre- and post-barriers for both volatile loads and stores. We could >> consider making the kind of nodes introduced dependent on the platform. >> >> - thomas >> >> On Sep 29, 2013, at 12:55 AM, D.Sturm wrote: >> >> > The Aarch64 ISA allows to fold most memory barriers into special load >> and >> > store instructions - similar to IA64. That means we can get away with >> only >> > explicitly generating StoreLoad barriers and use >> load-acquire/store-release >> > for volatile read/writes and when publishing newly constructed objects >> with >> > final fields. >> > >> > What is the best approach for getting this information when generating >> > load/stores or maybe during a peephole optimization? >> > >> > There's a lastLocationAccess for the FloatingReadNode which should >> point to >> > a MembarNode if it's a volatile read (and there's a next field for >> > storenodes which should do the same), but that seems rather fragile. >> > >> > >> > - Daniel >> >> > > From thomas.wuerthinger at Oracle.com Thu Oct 3 06:38:47 2013 From: thomas.wuerthinger at Oracle.com (Thomas Wuerthinger) Date: Thu, 3 Oct 2013 15:38:47 +0200 Subject: [Truffle] Generated type system overrides isObject()/asObject() methods. In-Reply-To: References: <5F73CC9C-FE29-4848-99F8-BBAB97EC81F0@stefan-marr.de> <26C40E19-0E50-4852-B171-5F999F5ACB61@stefan-marr.de> <5016C2B2-755E-49E6-B5E0-57AF89265BE6@oracle.com> Message-ID: <7C00ABB6-E49A-4930-A7AC-4EFC0A8D488F@Oracle.com> OK, so "self" sounds exactly like the kind of value you would put into the arguments. You can subclass the Argument class to have a specific field for "self" and pass it on / set it at the call sites. Regarding nesting blocks: I guess leaving them as method calls is a good first choice. Inlining those calls is however critical for performance (and will then also help with avoiding the materialisation of the frame). How would you simulate the Smalltalk behavior of blocks and calls to blocks in a language like e.g. JavaScript? - thomas On Oct 3, 2013, at 10:02 AM, Stefan Marr wrote: > Hi Thomas: > > (cc Michael) > > On 03 Oct 2013, at 09:04, Thomas Wuerthinger wrote: > >> There is one question I have about the determineContext and getSelfFromMaterialized methods. Could the self value be transmitted via an argument? The lookup over the chain of frames seems slow (and forces materialisation), so is there some other way one could pass these values? Could you describe the requirements for this self value in the system? > > I guess `self` could be passed as an argument somehow, but I wouldn't know immediately how to get that right. > > What's called the context here is the lexical scope of a block/lambda, which is always defined within a particular method of an object. > Thus, `self` is always the object on which the method was invoked, in which the block was defined. > > Now `self` is not the only issue here, I think. (I guess you are mostly thinking of getting rid of all materialized blocks.) > The main issue is that nesting blocks happens quite often, and you want to be able to access the lexical scope. > > I am not entirely familiar with all the kind of possible techniques to avoid such 'materialization', but there are a couple of approaches in the Smalltalk world, for instance the one described by Eliot Miranda [1]. So, I could imagine that blocks get compiled into different variants depending on whether they actually access `self` or their outer contexts. This could avoid materialization for an interesting number of cases. > > Michael, you got some more insight into what might be possible here? > > Thanks > Stefan > > [1] http://www.esug.org/data/Articles/misc/oopsla99-contexts.pdf > > -- > 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 morris.meyer at oracle.com Thu Oct 3 07:21:41 2013 From: morris.meyer at oracle.com (Morris Meyer) Date: Thu, 03 Oct 2013 10:21:41 -0400 Subject: questions about decoupling GPU target runtimes from host runtime In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73F919C2C@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73F919C2C@SATLEXDAG02.amd.com> Message-ID: <524D7D75.9070004@oracle.com> Vasanth, Regarding 2 and 4 Bharadwaj and Christian Thalinger have been looking at this area and may want to expand on this. Regarding UseGPU it seems necessary for now, but testing two different code paths for with and without GPU capability seems like burden we might want to avoid. Would hope we could present developers with a path of least surprise - and have an optional flag to set or turn off explicit GPUs. Regarding 3 there were some changes recently to the PTX side of things for parallel invocation. The register config is no longer Register based, but Variable based. The extra classes in the backend might need refactoring. Regarding 2a, you can use this as for a unit test with working PTX hardware. $ /mx.sh unittest -XX:+TraceGPUInteraction -XX:+UseGPU ArrayPTXTest I recently added two Sumatra annotations (ParallelOver and Warp) to the PTX backend specific to the PTX LIR. These annotations are currently in com.oracle.graal.lir.ptx. These might wind up in com.oracle.graal.lir.warp and the Warp annotation might be renamed to ThreadOverride or something more specific. Something for a longer cross-teams discussion. Given the int[] array { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; and the input '2'. ParallelOver and Warp produce: public static void testStoreArray1I(int[] array, int i) { array[i] = 42; } testStoreArray1I: [1, 2, 42, 4, 5, 6, 7, 8, 9] public static void testStoreArrayWarp0(int[] array, @Warp(dimension = X) int i) { array[i] = 42; } testStoreArrayWarp0: [42, 2, 3, 4, 5, 6, 7, 8, 9] public static void testStoreArrayWarp1I(@ParallelOver(dimension = X) int[] array, @Warp(dimension = X) int i) { array[i] = 42; } testStoreArrayWarp1I: [42, 42, 42, 42, 42, 42, 42, 42, 42] testStoreArray1I is a simple array store. testStoreArrayWarp0 stores into the array offset by the thread index. testStoreArrayWarp1I spawns a 1-dimensional thread warp of the size of the array and each thread assigns itself into the array offset by the thread index. Finally, in PTXTestBase there is a warp size limiter (for now): assert dimensionX * dimensionY * dimensionZ < PTXTargetMethodAssembler.getAvailableProcessors(); r = ((HotSpotNmethod) installedCode).executeParallel(dimensionX, dimensionY, dimensionZ, executeArgs); To echo the point above - it might be a good time for a cross-teams meeting on terms and a comparison of underlying parallel execution semantics in the AMD and PTX architectures. It would be good to specify our operating assumptions in a GPU environment for folks that are hoisting vector operations and looking at presenting a path to the JDK8 streams APIs. --mm On 10/2/13 4:48 PM, Venkatachalam, Vasanth wrote: > Doug- > > > We're scoping out the changes needed to isolate the GPU target runtimes (HSAIL, PTX) from the host runtime, so that the host runtime (e.g., AMD64HotspotRuntime) does not get instantiated when we generate code for HSAIL or PTX. This is in part intended to address the comments you sent in sent about http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-r15changes/webrev/ (forwarded below). We had some questions below. > > > 1) All of the platform-specific runtime classes defined so far (PTXHotSpotRuntime, AMD64HotSpotRuntime) are subclassing HotSpotRuntime, which implements the CodeCacheProvider interface. If we understood you correctly, the GPU target runtimes (PtX, HSAIL) should not subclass HotSpotRuntime, because in doing so they would be inheriting code that is HotSpot specfic and not relevant to the GPU target. They should instead be independent classes which extend the DelegatingCodeCacheProvider class and delegate to HotSpotRuntime any functionality that is not target GPU specific. Is this what you had in mind? > > 2) The routine graalRuntime( ) in graalVMToCompiler.cpp is checking to see if the UseGPU flag is enabled and if it is (and if the GPU target is PTX) it is instantiating PTXHotSpotGraalRuntime. It sounds like we need to add some logic to check if the GPU target is HSAIL and if so to instantiate the HSAIL runtime class. Am I on the right track? > > a. Can you send us the command line to use to check that the UseGPU functionality is working? When I run a PTX test case in NetBeans with -XX:+UseGPU the JVM crashes even before it gets to generate any code. > > 3) PTXHotSpotGraalRuntime is creating a PTXHotSpotBackend which looks similar to PTXBackend. What is the purpose of having both the PTXHotSpotBackend and a PTXBackend? It looks like these two classes are duplicating some functionality. Do we need to have an HSAILHotSpotBackend in addition to HSAILBackend? I have a similar question for PTXHotSpotRegisterConfiguration vs. PTXRegisterConfiguration. How should we deal with these pairs of classes in the refactoring you're recommending in 1)? It seems to me like these PTXHotspot* classes should go away if we're truly decoupling the GPU target runtimes from Hotspot. > > 4) Is there a reason why we need both PTXHotspotGraalRuntime in addition to PtXHotSpotRuntime instead of just having a single class that combines the work of both? > > Vasanth > > > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Wednesday, September 11, 2013 9:54 AM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev: workaround for threadRegister handling > > > > Hi Vasanth, > > > > I think you are tackling this problem at the wrong level. All the logic that uses threadRegister and stackPointerRegister is in snippets. The point of snippets is they are the interface the compiler uses to do runtime-specific lowering. I somehow very much doubt that the snippets using these registers will make any sense in the context of the GPU. Even if you plan on implementing new/newarray/monitorenter/monitorexit etc on the GPU, the code will be quite different than that for HotSpot's "host" runtime. After all, they are very specific to HotSpot data structures such as thread local allocation buffers, G1 barriers, etc. > > > > In my opinion, you need to have a GraalCodeCacheProvider implementation that does all the GPU specific lowering. To ensure you've got this separation right/complete, your GraalCodeCacheProvider subclass probably shouldn't even subclass HotSpotRuntime. > > > > -Doug > From doug.simon at oracle.com Thu Oct 3 07:25:17 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 3 Oct 2013 16:25:17 +0200 Subject: questions about decoupling GPU target runtimes from host runtime In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73F919C2C@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73F919C2C@SATLEXDAG02.amd.com> Message-ID: <70D3C2F7-2663-48EB-9A4D-F36349A162A7@oracle.com> On Oct 2, 2013, at 10:48 PM, "Venkatachalam, Vasanth" wrote: > Doug- > > We?re scoping out the changes needed to isolate the GPU target runtimes (HSAIL, PTX) from the host runtime, so that the host runtime (e.g., AMD64HotspotRuntime) does not get instantiated when we generate code for HSAIL or PTX. This is in part intended to address the comments you sent in sent about http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-r15changes/webrev/ (forwarded below). We had some questions below. > > 1) All of the platform-specific runtime classes defined so far (PTXHotSpotRuntime, AMD64HotSpotRuntime) are subclassing HotSpotRuntime, which implements the CodeCacheProvider interface. If we understood you correctly, the GPU target runtimes (PtX, HSAIL) should not subclass HotSpotRuntime, because in doing so they would be inheriting code that is HotSpot specfic and not relevant to the GPU target. They should instead be independent classes which extend the DelegatingCodeCacheProvider class and delegate to HotSpotRuntime any functionality that is not target GPU specific. Is this what you had in mind? Yes. > 2) The routine graalRuntime( ) in graalVMToCompiler.cpp is checking to see if the UseGPU flag is enabled and if it is (and if the GPU target is PTX) it is instantiating PTXHotSpotGraalRuntime. It sounds like we need to add some logic to check if the GPU target is HSAIL and if so to instantiate the HSAIL runtime class. Am I on the right track? I'm not so sure that this GPU detection and initialization code is general enough. I can envisage a system with two or more different GPU types available. I've commented on this while reviewing a proposal from Bharadwaj on better support for GPU backends in Graal. I've attached the details of this review (in our internal Crucible instance). > a. Can you send us the command line to use to check that the UseGPU functionality is working? When I run a PTX test case in NetBeans with ?XX:+UseGPU the JVM crashes even before it gets to generate any code. I've never run with UseGPU enabled. Hopefully Bharadwaj, Morris or Christian (Thalinger) can address this question. > 3) PTXHotSpotGraalRuntime is creating a PTXHotSpotBackend which looks similar to PTXBackend. What is the purpose of having both the PTXHotSpotBackend and a PTXBackend? It looks like these two classes are duplicating some functionality. Do we need to have an HSAILHotSpotBackend in addition to HSAILBackend? I have a similar question for PTXHotSpotRegisterConfiguration vs. PTXRegisterConfiguration. How should we deal with these pairs of classes in the refactoring you?re recommending in 1)? It seems to me like these PTXHotspot* classes should go away if we?re truly decoupling the GPU target runtimes from Hotspot. Yes, they should go away. Hopefully the attached review shows a sketch of how we are thinking this could be achieved. > 4) Is there a reason why we need both PTXHotspotGraalRuntime in addition to PtXHotSpotRuntime instead of just having a single class that combines the work of both? We want to have an API where there is exactly one HotSpotGraalRuntime instance that manages multiple backends. -Doug -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CR-1587.txt Url: http://mail.openjdk.java.net/pipermail/graal-dev/attachments/20131003/f822795c/CR-1587.txt -------------- next part -------------- > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Wednesday, September 11, 2013 9:54 AM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev: workaround for threadRegister handling > > Hi Vasanth, > > I think you are tackling this problem at the wrong level. All the logic that uses threadRegister and stackPointerRegister is in snippets. The point of snippets is they are the interface the compiler uses to do runtime-specific lowering. I somehow very much doubt that the snippets using these registers will make any sense in the context of the GPU. Even if you plan on implementing new/newarray/monitorenter/monitorexit etc on the GPU, the code will be quite different than that for HotSpot's "host" runtime. After all, they are very specific to HotSpot data structures such as thread local allocation buffers, G1 barriers, etc. > > In my opinion, you need to have a GraalCodeCacheProvider implementation that does all the GPU specific lowering. To ensure you've got this separation right/complete, your GraalCodeCacheProvider subclass probably shouldn't even subclass HotSpotRuntime. > > -Doug > From bharadwaj.yadavalli at oracle.com Thu Oct 3 08:29:03 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Thu, 03 Oct 2013 11:29:03 -0400 Subject: questions about decoupling GPU target runtimes from host runtime In-Reply-To: <70D3C2F7-2663-48EB-9A4D-F36349A162A7@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73F919C2C@SATLEXDAG02.amd.com> <70D3C2F7-2663-48EB-9A4D-F36349A162A7@oracle.com> Message-ID: <524D8D3F.3050205@oracle.com> On 10/3/2013 10:25 AM, Doug Simon wrote: > On Oct 2, 2013, at 10:48 PM, "Venkatachalam, Vasanth" wrote: <...> > 2) The routine graalRuntime( ) in graalVMToCompiler.cpp is checking to see if the UseGPU flag is enabled and if it is (and if the GPU target is PTX) it is instantiating PTXHotSpotGraalRuntime. It sounds like we need to add some logic to check if the GPU target is HSAIL and if so to instantiate the HSAIL runtime class. Am I on the right track? > I'm not so sure that this GPU detection and initialization code is general enough. I can envisage a system with two or more different GPU types available. I've commented on this while reviewing a proposal from Bharadwaj on better support for GPU backends in Graal. I've attached the details of this review (in our internal Crucible instance). I agree with Doug regarding GPU detection code being not general enough. I am working to improve this. All suggestions/proposals to improve it to be generic enough are welcome. How do you guys do it to detect AMD GPUs? >> a. Can you send us the command line to use to check that the UseGPU functionality is working? When I run a PTX test case in NetBeans with ?XX:+UseGPU the JVM crashes even before it gets to generate any code. > I've never run with UseGPU enabled. Hopefully Bharadwaj, Morris or Christian (Thalinger) can address this question. I introduced UseGPU as a transitional flag till we have the dynamic runtime ability to dispatch compilation and execution of selected methods (such as lambda methods, for example) to GPU and the rest to CPU which in turn, requires the support for multiple backends (either GPU of other CPU cores and a heterogeneous system) in Graal. Regarding the crash, I would expect specifying UseGPU on a machine without CUDA-enabled device to have no effect. Are you sync'd to the tip of graal repo? I'll be happy to help, if you still see the problem. >> 3) PTXHotSpotGraalRuntime is creating a PTXHotSpotBackend which looks similar to PTXBackend. What is the purpose of having both the PTXHotSpotBackend and a PTXBackend? It looks like these two classes are duplicating some functionality. Do we need to have an HSAILHotSpotBackend in addition to HSAILBackend? I have a similar question for PTXHotSpotRegisterConfiguration vs. PTXRegisterConfiguration. How should we deal with these pairs of classes in the refactoring you?re recommending in 1)? It seems to me like these PTXHotspot* classes should go away if we?re truly decoupling the GPU target runtimes from Hotspot. > Yes, they should go away. Hopefully the attached review shows a sketch of how we are thinking this could be achieved. Thanks, Doug for sharing the CR summary. Also, Vasanth and others, please provide any feedback and suggestions that you may have for supporting multiple backends. Although my sketch implies that there is at most one GPU backend, my idea is indeed to support a set of multiple back ends. To that end, I like to think that the set would contain the traditional "host CPU" as well - as opposed to a "host (CPU) backend" and "additional backends". That is what I had in mind when I refer to multiple backends as "first class citizens". Bharadwaj From tbaldridge at gmail.com Thu Oct 3 10:44:08 2013 From: tbaldridge at gmail.com (Timothy Baldridge) Date: Thu, 3 Oct 2013 11:44:08 -0600 Subject: Can't figure out VerifyFrameDoesNotEscape Message-ID: I've been playing around with a simple BF interpreter written in Truffle. Last night I got this error for the first time: [thread:1] scope: [thread:1] scope: Truffle [thread:1] scope: Truffle.createGraph [thread:1] scope: Truffle.createGraph.VerifyFrameDoesNotEscape [thread:1] scope: Truffle.createGraph.VerifyFrameDoesNotEscape.InterceptException Exception occurred in scope: Truffle.createGraph.VerifyFrameDoesNotEscape.InterceptException Context obj com.oracle.graal.nodes.util.GraphUtil$2: Frame escapes at: 67|MethodCallTarget#HotSpotMethod My AST is available here : https://bitbucket.org/cint/trufflebf/src/274c7f80c83936d4bf705197f97c825cd40d0fc0/src/trufflebf/nodes?at=master As you can see, all my children are marked with @Child and are private final. What am I doing wrong? Thanks! Timothy Baldridge From andreas.woess at jku.at Thu Oct 3 10:50:07 2013 From: andreas.woess at jku.at (Andreas Woess) Date: Thu, 03 Oct 2013 19:50:07 +0200 Subject: Can't figure out VerifyFrameDoesNotEscape In-Reply-To: References: Message-ID: <524DAE4F.8010708@jku.at> Thanks for your interest in Truffle. You need to annotate BlockNode.execute with @ExplodeLoop to force loop unrolling. - andreas On 03.10.2013 19:44, Timothy Baldridge wrote: > I've been playing around with a simple BF interpreter written in Truffle. > Last night I got this error for the first time: > > [thread:1] scope: > [thread:1] scope: Truffle > [thread:1] scope: Truffle.createGraph > [thread:1] scope: Truffle.createGraph.VerifyFrameDoesNotEscape > [thread:1] scope: > Truffle.createGraph.VerifyFrameDoesNotEscape.InterceptException > Exception occurred in scope: > Truffle.createGraph.VerifyFrameDoesNotEscape.InterceptException > Context obj com.oracle.graal.nodes.util.GraphUtil$2: Frame escapes > at: 67|MethodCallTarget#HotSpotMethod int)> > > My AST is available here : > https://bitbucket.org/cint/trufflebf/src/274c7f80c83936d4bf705197f97c825cd40d0fc0/src/trufflebf/nodes?at=master > > As you can see, all my children are marked with @Child and are private > final. What am I doing wrong? > > Thanks! > > Timothy Baldridge > From Vasanth.Venkatachalam at amd.com Thu Oct 3 11:39:58 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Thu, 3 Oct 2013 18:39:58 +0000 Subject: questions about decoupling GPU target runtimes from host runtime Message-ID: <5DD1503F815BD14889DC81D28643E3A73F91CC98@SATLEXDAG02.amd.com> Doug- Thanks for your reply. Some follow-up questions. 1) Based on this discussion thread and your attached codereview, it sounds like the details for multiple backend support haven?t been fully worked out yet. Given this, does it still make sense for us to submit a self-contained patch that just refactors PTXHotSpotRuntime, HSAILRuntime to use the delegating interface instead of subclassing HotSpotRuntime? I?m trying to understand if there?s value in such a patch before the rest of the refactoring changes are in place to introduce multiple backends and get rid of the duplicate classes (PTXHotSpotBackend ?), and if so, how you would like this done in a self-contained manner while the architecture is in flux. 2) You mention, ?We want to have an API where there is exactly one HotSpotGraalRuntime instance that manages multiple backends.? Does this mean that PTXHotSpotGraalRuntime and AMD64HotSpotGraalRuntime should also go away? Vasanth From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Thursday, October 03, 2013 9:25 AM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net; Bharadwaj Yadavalli Subject: Re: questions about decoupling GPU target runtimes from host runtime On Oct 2, 2013, at 10:48 PM, "Venkatachalam, Vasanth" > wrote: > Doug- > > We?re scoping out the changes needed to isolate the GPU target runtimes (HSAIL, PTX) from the host runtime, so that the host runtime (e.g., AMD64HotspotRuntime) does not get instantiated when we generate code for HSAIL or PTX. This is in part intended to address the comments you sent in sent about http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-r15changes/webrev/ (forwarded below). We had some questions below. > > 1) All of the platform-specific runtime classes defined so far (PTXHotSpotRuntime, AMD64HotSpotRuntime) are subclassing HotSpotRuntime, which implements the CodeCacheProvider interface. If we understood you correctly, the GPU target runtimes (PtX, HSAIL) should not subclass HotSpotRuntime, because in doing so they would be inheriting code that is HotSpot specfic and not relevant to the GPU target. They should instead be independent classes which extend the DelegatingCodeCacheProvider class and delegate to HotSpotRuntime any functionality that is not target GPU specific. Is this what you had in mind? Yes. > 2) The routine graalRuntime( ) in graalVMToCompiler.cpp is checking to see if the UseGPU flag is enabled and if it is (and if the GPU target is PTX) it is instantiating PTXHotSpotGraalRuntime. It sounds like we need to add some logic to check if the GPU target is HSAIL and if so to instantiate the HSAIL runtime class. Am I on the right track? I'm not so sure that this GPU detection and initialization code is general enough. I can envisage a system with two or more different GPU types available. I've commented on this while reviewing a proposal from Bharadwaj on better support for GPU backends in Graal. I've attached the details of this review (in our internal Crucible instance). > a. Can you send us the command line to use to check that the UseGPU functionality is working? When I run a PTX test case in NetBeans with ?XX:+UseGPU the JVM crashes even before it gets to generate any code. I've never run with UseGPU enabled. Hopefully Bharadwaj, Morris or Christian (Thalinger) can address this question. > 3) PTXHotSpotGraalRuntime is creating a PTXHotSpotBackend which looks similar to PTXBackend. What is the purpose of having both the PTXHotSpotBackend and a PTXBackend? It looks like these two classes are duplicating some functionality. Do we need to have an HSAILHotSpotBackend in addition to HSAILBackend? I have a similar question for PTXHotSpotRegisterConfiguration vs. PTXRegisterConfiguration. How should we deal with these pairs of classes in the refactoring you?re recommending in 1)? It seems to me like these PTXHotspot* classes should go away if we?re truly decoupling the GPU target runtimes from Hotspot. Yes, they should go away. Hopefully the attached review shows a sketch of how we are thinking this could be achieved. > 4) Is there a reason why we need both PTXHotspotGraalRuntime in addition to PtXHotSpotRuntime instead of just having a single class that combines the work of both? We want to have an API where there is exactly one HotSpotGraalRuntime instance that manages multiple backends. -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Wednesday, September 11, 2013 9:54 AM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev: workaround for threadRegister handling > > Hi Vasanth, > > I think you are tackling this problem at the wrong level. All the logic that uses threadRegister and stackPointerRegister is in snippets. The point of snippets is they are the interface the compiler uses to do runtime-specific lowering. I somehow very much doubt that the snippets using these registers will make any sense in the context of the GPU. Even if you plan on implementing new/newarray/monitorenter/monitorexit etc on the GPU, the code will be quite different than that for HotSpot's "host" runtime. After all, they are very specific to HotSpot data structures such as thread local allocation buffers, G1 barriers, etc. > > In my opinion, you need to have a GraalCodeCacheProvider implementation that does all the GPU specific lowering. To ensure you've got this separation right/complete, your GraalCodeCacheProvider subclass probably shouldn't even subclass HotSpotRuntime. > > -Doug > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CR-1587.txt Url: http://mail.openjdk.java.net/pipermail/graal-dev/attachments/20131003/b4b3e879/CR-1587.txt From doug.simon at oracle.com Thu Oct 3 11:55:29 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 3 Oct 2013 20:55:29 +0200 Subject: questions about decoupling GPU target runtimes from host runtime In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73F91CC98@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73F91CC98@SATLEXDAG02.amd.com> Message-ID: Hi Vasanth, I will be visiting the team in Linz early next week and we will spend some time improving the support in Graal for multiple backends. If possible, I recommend deferring any further work on the HSAIL backend until we've come up with something. -Doug On Oct 3, 2013, at 8:39 PM, "Venkatachalam, Vasanth" wrote: > Doug- > > Thanks for your reply. Some follow-up questions. > > 1) Based on this discussion thread and your attached codereview, it sounds like the details for multiple backend support haven?t been fully worked out yet. > Given this, does it still make sense for us to submit a self-contained patch that just refactors PTXHotSpotRuntime, HSAILRuntime to use the delegating interface instead of subclassing HotSpotRuntime? I?m trying to understand if there?s value in such a patch before the rest of the refactoring changes are in place to introduce multiple backends and get rid of the duplicate classes (PTXHotSpotBackend ?), and if so, how you would like this done in a self-contained manner while the architecture is in flux. > > 2) You mention, > ?We want to have an API where there is exactly one HotSpotGraalRuntime instance that manages multiple backends.? > > Does this mean that PTXHotSpotGraalRuntime and AMD64HotSpotGraalRuntime should also go away? > > Vasanth > > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Thursday, October 03, 2013 9:25 AM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net; Bharadwaj Yadavalli > Subject: Re: questions about decoupling GPU target runtimes from host runtime > > > On Oct 2, 2013, at 10:48 PM, "Venkatachalam, Vasanth" wrote: > > > Doug- > > > > We?re scoping out the changes needed to isolate the GPU target runtimes (HSAIL, PTX) from the host runtime, so that the host runtime (e.g., AMD64HotspotRuntime) does not get instantiated when we generate code for HSAIL or PTX. This is in part intended to address the comments you sent in sent about http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-r15changes/webrev/ (forwarded below). We had some questions below. > > > > 1) All of the platform-specific runtime classes defined so far (PTXHotSpotRuntime, AMD64HotSpotRuntime) are subclassing HotSpotRuntime, which implements the CodeCacheProvider interface. If we understood you correctly, the GPU target runtimes (PtX, HSAIL) should not subclass HotSpotRuntime, because in doing so they would be inheriting code that is HotSpot specfic and not relevant to the GPU target. They should instead be independent classes which extend the DelegatingCodeCacheProvider class and delegate to HotSpotRuntime any functionality that is not target GPU specific. Is this what you had in mind? > > Yes. > > > 2) The routine graalRuntime( ) in graalVMToCompiler.cpp is checking to see if the UseGPU flag is enabled and if it is (and if the GPU target is PTX) it is instantiating PTXHotSpotGraalRuntime. It sounds like we need to add some logic to check if the GPU target is HSAIL and if so to instantiate the HSAIL runtime class. Am I on the right track? > > I'm not so sure that this GPU detection and initialization code is general enough. I can envisage a system with two or more different GPU types available. I've commented on this while reviewing a proposal from Bharadwaj on better support for GPU backends in Graal. I've attached the details of this review (in our internal Crucible instance). > > > a. Can you send us the command line to use to check that the UseGPU functionality is working? When I run a PTX test case in NetBeans with ?XX:+UseGPU the JVM crashes even before it gets to generate any code. > > I've never run with UseGPU enabled. Hopefully Bharadwaj, Morris or Christian (Thalinger) can address this question. > > > 3) PTXHotSpotGraalRuntime is creating a PTXHotSpotBackend which looks similar to PTXBackend. What is the purpose of having both the PTXHotSpotBackend and a PTXBackend? It looks like these two classes are duplicating some functionality. Do we need to have an HSAILHotSpotBackend in addition to HSAILBackend? I have a similar question for PTXHotSpotRegisterConfiguration vs. PTXRegisterConfiguration. How should we deal with these pairs of classes in the refactoring you?re recommending in 1)? It seems to me like these PTXHotspot* classes should go away if we?re truly decoupling the GPU target runtimes from Hotspot. > > Yes, they should go away. Hopefully the attached review shows a sketch of how we are thinking this could be achieved. > > > 4) Is there a reason why we need both PTXHotspotGraalRuntime in addition to PtXHotSpotRuntime instead of just having a single class that combines the work of both? > > We want to have an API where there is exactly one HotSpotGraalRuntime instance that manages multiple backends. > > -Doug > > > > > -----Original Message----- > > From: Doug Simon [mailto:doug.simon at oracle.com] > > Sent: Wednesday, September 11, 2013 9:54 AM > > To: Venkatachalam, Vasanth > > Cc: graal-dev at openjdk.java.net > > Subject: Re: webrev: workaround for threadRegister handling > > > > Hi Vasanth, > > > > I think you are tackling this problem at the wrong level. All the logic that uses threadRegister and stackPointerRegister is in snippets. The point of snippets is they are the interface the compiler uses to do runtime-specific lowering. I somehow very much doubt that the snippets using these registers will make any sense in the context of the GPU. Even if you plan on implementing new/newarray/monitorenter/monitorexit etc on the GPU, the code will be quite different than that for HotSpot's "host" runtime. After all, they are very specific to HotSpot data structures such as thread local allocation buffers, G1 barriers, etc. > > > > In my opinion, you need to have a GraalCodeCacheProvider implementation that does all the GPU specific lowering. To ensure you've got this separation right/complete, your GraalCodeCacheProvider subclass probably shouldn't even subclass HotSpotRuntime. > > > > -Doug > > > > From tbaldridge at gmail.com Thu Oct 3 12:00:16 2013 From: tbaldridge at gmail.com (Timothy Baldridge) Date: Thu, 3 Oct 2013 13:00:16 -0600 Subject: Can't figure out VerifyFrameDoesNotEscape In-Reply-To: <524DAE4F.8010708@jku.at> References: <524DAE4F.8010708@jku.at> Message-ID: That fixed it, thanks! Timothy On Thu, Oct 3, 2013 at 11:50 AM, Andreas Woess wrote: > Thanks for your interest in Truffle. You need to annotate > BlockNode.execute with @ExplodeLoop to force loop unrolling. > > - andreas > > On 03.10.2013 19:44, Timothy Baldridge wrote: > > I've been playing around with a simple BF interpreter written in Truffle. > > Last night I got this error for the first time: > > > > [thread:1] scope: > > [thread:1] scope: Truffle > > [thread:1] scope: Truffle.createGraph > > [thread:1] scope: Truffle.createGraph.VerifyFrameDoesNotEscape > > [thread:1] scope: > > Truffle.createGraph.VerifyFrameDoesNotEscape.InterceptException > > Exception occurred in scope: > > Truffle.createGraph.VerifyFrameDoesNotEscape.InterceptException > > Context obj com.oracle.graal.nodes.util.GraphUtil$2: Frame > escapes > > at: 67|MethodCallTarget#HotSpotMethod byte[], > > int)> > > > > My AST is available here : > > > https://bitbucket.org/cint/trufflebf/src/274c7f80c83936d4bf705197f97c825cd40d0fc0/src/trufflebf/nodes?at=master > > > > As you can see, all my children are marked with @Child and are private > > final. What am I doing wrong? > > > > Thanks! > > > > Timothy Baldridge > > > > -- ?One of the main causes of the fall of the Roman Empire was that?lacking zero?they had no way to indicate successful termination of their C programs.? (Robert Firth) From Vasanth.Venkatachalam at amd.com Thu Oct 3 15:10:55 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Thu, 3 Oct 2013 22:10:55 +0000 Subject: questions about decoupling GPU target runtimes from host runtime Message-ID: <5DD1503F815BD14889DC81D28643E3A73F91CD66@SATLEXDAG02.amd.com> Doug- To remind you the context behind our questions, the host runtime (AMD64HotspotRuntime) is being instantiated and treated as the "default" runtime when we are executing an HSAIL test case. As a result, the code ends up in an inconsistent state where the HSAIL register configuration is being used, but the underlying runtime is still AMD64. This problem is affecting more than one place in the code. For example, CFGPrinterObserver line 146 looks up the runtime to be AMD64HotSpotRuntime, and as a result CompilationPrinter.debugInfoToString (line 124) gets an ArrayIndexOutOfBoundsException when it tries to lookup an HSAIL register number in an array of AMD64 registers (which has fewer registers than HSAIL). This is causing test cases that exercise a lot of HSAIL registers to fail when we run them with flags to dump a data file for the C1visualizer. The other example is that test cases involving method calls are causing some exception handling snippets to be invoked. The AMD64 definition of these snippets gets loaded and looks for a threadregister (which we haven't specified in HSAIL) and this leads to an assertion error. Are you recommending that we should postpone tackling the underlying problem until the improved support you mention below is in place? Is there an interim solution that we could submit as a patch? Vasanth -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Thursday, October 03, 2013 1:55 PM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: Re: questions about decoupling GPU target runtimes from host runtime Hi Vasanth, I will be visiting the team in Linz early next week and we will spend some time improving the support in Graal for multiple backends. If possible, I recommend deferring any further work on the HSAIL backend until we've come up with something. -Doug On Oct 3, 2013, at 8:39 PM, "Venkatachalam, Vasanth" wrote: > Doug- > > Thanks for your reply. Some follow-up questions. > > 1) Based on this discussion thread and your attached codereview, it sounds like the details for multiple backend support haven't been fully worked out yet. > Given this, does it still make sense for us to submit a self-contained patch that just refactors PTXHotSpotRuntime, HSAILRuntime to use the delegating interface instead of subclassing HotSpotRuntime? I'm trying to understand if there's value in such a patch before the rest of the refactoring changes are in place to introduce multiple backends and get rid of the duplicate classes (PTXHotSpotBackend ...), and if so, how you would like this done in a self-contained manner while the architecture is in flux. > > 2) You mention, > "We want to have an API where there is exactly one HotSpotGraalRuntime instance that manages multiple backends." > > Does this mean that PTXHotSpotGraalRuntime and AMD64HotSpotGraalRuntime should also go away? > > Vasanth > > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Thursday, October 03, 2013 9:25 AM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net; Bharadwaj Yadavalli > Subject: Re: questions about decoupling GPU target runtimes from host runtime > > > On Oct 2, 2013, at 10:48 PM, "Venkatachalam, Vasanth" wrote: > > > Doug- > > > > We're scoping out the changes needed to isolate the GPU target runtimes (HSAIL, PTX) from the host runtime, so that the host runtime (e.g., AMD64HotspotRuntime) does not get instantiated when we generate code for HSAIL or PTX. This is in part intended to address the comments you sent in sent about http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-r15changes/webrev/ (forwarded below). We had some questions below. > > > > 1) All of the platform-specific runtime classes defined so far (PTXHotSpotRuntime, AMD64HotSpotRuntime) are subclassing HotSpotRuntime, which implements the CodeCacheProvider interface. If we understood you correctly, the GPU target runtimes (PtX, HSAIL) should not subclass HotSpotRuntime, because in doing so they would be inheriting code that is HotSpot specfic and not relevant to the GPU target. They should instead be independent classes which extend the DelegatingCodeCacheProvider class and delegate to HotSpotRuntime any functionality that is not target GPU specific. Is this what you had in mind? > > Yes. > > > 2) The routine graalRuntime( ) in graalVMToCompiler.cpp is checking to see if the UseGPU flag is enabled and if it is (and if the GPU target is PTX) it is instantiating PTXHotSpotGraalRuntime. It sounds like we need to add some logic to check if the GPU target is HSAIL and if so to instantiate the HSAIL runtime class. Am I on the right track? > > I'm not so sure that this GPU detection and initialization code is general enough. I can envisage a system with two or more different GPU types available. I've commented on this while reviewing a proposal from Bharadwaj on better support for GPU backends in Graal. I've attached the details of this review (in our internal Crucible instance). > > > a. Can you send us the command line to use to check that the UseGPU functionality is working? When I run a PTX test case in NetBeans with -XX:+UseGPU the JVM crashes even before it gets to generate any code. > > I've never run with UseGPU enabled. Hopefully Bharadwaj, Morris or Christian (Thalinger) can address this question. > > > 3) PTXHotSpotGraalRuntime is creating a PTXHotSpotBackend which looks similar to PTXBackend. What is the purpose of having both the PTXHotSpotBackend and a PTXBackend? It looks like these two classes are duplicating some functionality. Do we need to have an HSAILHotSpotBackend in addition to HSAILBackend? I have a similar question for PTXHotSpotRegisterConfiguration vs. PTXRegisterConfiguration. How should we deal with these pairs of classes in the refactoring you're recommending in 1)? It seems to me like these PTXHotspot* classes should go away if we're truly decoupling the GPU target runtimes from Hotspot. > > Yes, they should go away. Hopefully the attached review shows a sketch of how we are thinking this could be achieved. > > > 4) Is there a reason why we need both PTXHotspotGraalRuntime in addition to PtXHotSpotRuntime instead of just having a single class that combines the work of both? > > We want to have an API where there is exactly one HotSpotGraalRuntime instance that manages multiple backends. > > -Doug > > > > > -----Original Message----- > > From: Doug Simon [mailto:doug.simon at oracle.com] > > Sent: Wednesday, September 11, 2013 9:54 AM > > To: Venkatachalam, Vasanth > > Cc: graal-dev at openjdk.java.net > > Subject: Re: webrev: workaround for threadRegister handling > > > > Hi Vasanth, > > > > I think you are tackling this problem at the wrong level. All the logic that uses threadRegister and stackPointerRegister is in snippets. The point of snippets is they are the interface the compiler uses to do runtime-specific lowering. I somehow very much doubt that the snippets using these registers will make any sense in the context of the GPU. Even if you plan on implementing new/newarray/monitorenter/monitorexit etc on the GPU, the code will be quite different than that for HotSpot's "host" runtime. After all, they are very specific to HotSpot data structures such as thread local allocation buffers, G1 barriers, etc. > > > > In my opinion, you need to have a GraalCodeCacheProvider implementation that does all the GPU specific lowering. To ensure you've got this separation right/complete, your GraalCodeCacheProvider subclass probably shouldn't even subclass HotSpotRuntime. > > > > -Doug > > > > From Eric.Caspole at amd.com Thu Oct 3 15:27:57 2013 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Thu, 3 Oct 2013 22:27:57 +0000 Subject: Labels using Block numbers for better cfg file output Message-ID: Hi everybody, I have been using the c1visualizer with our Graal HSAIL code for about 2 weeks now and it is really nice. I made a small change to the label numbering in Graal to use the Block id as the Label id, so that in the output cfg file the labels in our HSAIL output match the block numbering that appear in the c1visualizer. That way it is easy to glance back and forth between the HSAIL and the CFG in the visualizer and follow along. It worked for a couple different examples/tests that I tried. http://cr.openjdk.java.net/~ecaspole/label_block_id.00/webrev/ I only made this change for HSAIL but I find it very helpful. Let me know what you think. Regards, Eric From tbaldridge at gmail.com Thu Oct 3 15:38:54 2013 From: tbaldridge at gmail.com (Timothy Baldridge) Date: Thu, 3 Oct 2013 16:38:54 -0600 Subject: Truffle multithreaded language Message-ID: In my continued investigations of Truffle I decided to see what happened when I threw multiple threads at my AST. What I have is a simple BF language with no specialization (we pass around Objects and cast to ints/bytes as needed). For this test, I parse the source code once, and then have 3 threads execute the code over and over again. However when truffle kicks in (after 1000 total invocations of the function), I get the following error: [thread:8] scope: [thread:8] scope: Truffle [thread:8] scope: Truffle.createGraph [thread:8] scope: Truffle.createGraph.InterceptException Exception occurred in scope: Truffle.createGraph.InterceptException Context obj java.lang.IllegalStateException: Inlined graph is in invalid state Context obj StructuredGraph:4{HotSpotMethod} Use -G:+DumpOnError to enable dumping of graphs on this error Context obj DebugDumpScope[Truffle: MainNode at 333bee49] [truffle] opt failed MainNode at 333bee49 java.lang.IllegalStateException: Inlined graph is in invalid state java.lang.IllegalStateException: Inlined graph is in invalid state I create a CallTarget per thread, but I do share the AST between all threads. How is this supposed to work in a large language? Am I expected to duplicate the AST for every thread? And if so, how would I get something like that to work with thread pools. Thanks for the help, Timothy Baldridge From doug.simon at oracle.com Thu Oct 3 15:44:44 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 4 Oct 2013 00:44:44 +0200 Subject: questions about decoupling GPU target runtimes from host runtime In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73F91CD66@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73F91CD66@SATLEXDAG02.amd.com> Message-ID: On Oct 4, 2013, at 12:10 AM, "Venkatachalam, Vasanth" wrote: > Doug- > > To remind you the context behind our questions, the host runtime (AMD64HotspotRuntime) is being instantiated and treated as the "default" runtime when we are executing an HSAIL test case. > As a result, the code ends up in an inconsistent state where the HSAIL register configuration is being used, but the underlying runtime is still AMD64. That's why we need to think about extending the API so you can do something like this: Graal.getRequiredCapability(GraalCodeCacheProvider.class, "HSAIL"); This is just an example; the extra qualifier may be something other than a String in the final design. > This problem is affecting more than one place in the code. > > For example, CFGPrinterObserver line 146 looks up the runtime to be AMD64HotSpotRuntime, and as a result CompilationPrinter.debugInfoToString (line 124) gets an ArrayIndexOutOfBoundsException when it tries to lookup an HSAIL register number in an array of AMD64 registers (which has fewer registers than HSAIL). This is causing test cases that exercise a lot of HSAIL registers to fail when we run them with flags to dump a data file for the C1visualizer. The CFGPrinterObserver simply retrieves the CodeCacheProvider from the Debug context. Once you are calling GraalCompiler.compileGraph() with a HSAIL specific GraalCodeCacheProvider object, this issue will be resolved. > The other example is that test cases involving method calls are causing some exception handling snippets to be invoked. The AMD64 definition of these snippets gets loaded and looks for a threadregister (which we haven't specified in HSAIL) and this leads to an assertion error. Once again, a HSAIL specific GraalCodeCacheProvider with its own HSAIL-specific lowering will resolve this. > Are you recommending that we should postpone tackling the underlying problem until the improved support you mention below is in place? Yes. > Is there an interim solution that we could submit as a patch? Unfortunately, not really. We'll make this a high priority and hope to have something by mid next week. -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Thursday, October 03, 2013 1:55 PM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: questions about decoupling GPU target runtimes from host runtime > > Hi Vasanth, > > I will be visiting the team in Linz early next week and we will spend some time improving the support in Graal for multiple backends. If possible, I recommend deferring any further work on the HSAIL backend until we've come up with something. > > -Doug > > On Oct 3, 2013, at 8:39 PM, "Venkatachalam, Vasanth" wrote: > >> Doug- >> >> Thanks for your reply. Some follow-up questions. >> >> 1) Based on this discussion thread and your attached codereview, it sounds like the details for multiple backend support haven't been fully worked out yet. >> Given this, does it still make sense for us to submit a self-contained patch that just refactors PTXHotSpotRuntime, HSAILRuntime to use the delegating interface instead of subclassing HotSpotRuntime? I'm trying to understand if there's value in such a patch before the rest of the refactoring changes are in place to introduce multiple backends and get rid of the duplicate classes (PTXHotSpotBackend ...), and if so, how you would like this done in a self-contained manner while the architecture is in flux. >> >> 2) You mention, >> "We want to have an API where there is exactly one HotSpotGraalRuntime instance that manages multiple backends." >> >> Does this mean that PTXHotSpotGraalRuntime and AMD64HotSpotGraalRuntime should also go away? >> >> Vasanth >> >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Thursday, October 03, 2013 9:25 AM >> To: Venkatachalam, Vasanth >> Cc: graal-dev at openjdk.java.net; Bharadwaj Yadavalli >> Subject: Re: questions about decoupling GPU target runtimes from host runtime >> >> >> On Oct 2, 2013, at 10:48 PM, "Venkatachalam, Vasanth" wrote: >> >>> Doug- >>> >>> We're scoping out the changes needed to isolate the GPU target runtimes (HSAIL, PTX) from the host runtime, so that the host runtime (e.g., AMD64HotspotRuntime) does not get instantiated when we generate code for HSAIL or PTX. This is in part intended to address the comments you sent in sent about http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-r15changes/webrev/ (forwarded below). We had some questions below. >>> >>> 1) All of the platform-specific runtime classes defined so far (PTXHotSpotRuntime, AMD64HotSpotRuntime) are subclassing HotSpotRuntime, which implements the CodeCacheProvider interface. If we understood you correctly, the GPU target runtimes (PtX, HSAIL) should not subclass HotSpotRuntime, because in doing so they would be inheriting code that is HotSpot specfic and not relevant to the GPU target. They should instead be independent classes which extend the DelegatingCodeCacheProvider class and delegate to HotSpotRuntime any functionality that is not target GPU specific. Is this what you had in mind? >> >> Yes. >> >>> 2) The routine graalRuntime( ) in graalVMToCompiler.cpp is checking to see if the UseGPU flag is enabled and if it is (and if the GPU target is PTX) it is instantiating PTXHotSpotGraalRuntime. It sounds like we need to add some logic to check if the GPU target is HSAIL and if so to instantiate the HSAIL runtime class. Am I on the right track? >> >> I'm not so sure that this GPU detection and initialization code is general enough. I can envisage a system with two or more different GPU types available. I've commented on this while reviewing a proposal from Bharadwaj on better support for GPU backends in Graal. I've attached the details of this review (in our internal Crucible instance). >> >>> a. Can you send us the command line to use to check that the UseGPU functionality is working? When I run a PTX test case in NetBeans with -XX:+UseGPU the JVM crashes even before it gets to generate any code. >> >> I've never run with UseGPU enabled. Hopefully Bharadwaj, Morris or Christian (Thalinger) can address this question. >> >>> 3) PTXHotSpotGraalRuntime is creating a PTXHotSpotBackend which looks similar to PTXBackend. What is the purpose of having both the PTXHotSpotBackend and a PTXBackend? It looks like these two classes are duplicating some functionality. Do we need to have an HSAILHotSpotBackend in addition to HSAILBackend? I have a similar question for PTXHotSpotRegisterConfiguration vs. PTXRegisterConfiguration. How should we deal with these pairs of classes in the refactoring you're recommending in 1)? It seems to me like these PTXHotspot* classes should go away if we're truly decoupling the GPU target runtimes from Hotspot. >> >> Yes, they should go away. Hopefully the attached review shows a sketch of how we are thinking this could be achieved. >> >>> 4) Is there a reason why we need both PTXHotspotGraalRuntime in addition to PtXHotSpotRuntime instead of just having a single class that combines the work of both? >> >> We want to have an API where there is exactly one HotSpotGraalRuntime instance that manages multiple backends. >> >> -Doug >> >> >> >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Wednesday, September 11, 2013 9:54 AM >>> To: Venkatachalam, Vasanth >>> Cc: graal-dev at openjdk.java.net >>> Subject: Re: webrev: workaround for threadRegister handling >>> >>> Hi Vasanth, >>> >>> I think you are tackling this problem at the wrong level. All the logic that uses threadRegister and stackPointerRegister is in snippets. The point of snippets is they are the interface the compiler uses to do runtime-specific lowering. I somehow very much doubt that the snippets using these registers will make any sense in the context of the GPU. Even if you plan on implementing new/newarray/monitorenter/monitorexit etc on the GPU, the code will be quite different than that for HotSpot's "host" runtime. After all, they are very specific to HotSpot data structures such as thread local allocation buffers, G1 barriers, etc. >>> >>> In my opinion, you need to have a GraalCodeCacheProvider implementation that does all the GPU specific lowering. To ensure you've got this separation right/complete, your GraalCodeCacheProvider subclass probably shouldn't even subclass HotSpotRuntime. > >>> >>> -Doug >>> >> >> > > > From tbaldridge at gmail.com Thu Oct 3 16:14:18 2013 From: tbaldridge at gmail.com (Timothy Baldridge) Date: Thu, 3 Oct 2013 17:14:18 -0600 Subject: Truffle multithreaded language In-Reply-To: References: Message-ID: Or perhaps there is a "pre compilation" hook? That way I could lock the AST before the JIT kicks in. I don't mind a global lock like that, I just don't want to have to run under a GIL the entire time. Timothy On Thu, Oct 3, 2013 at 4:38 PM, Timothy Baldridge wrote: > In my continued investigations of Truffle I decided to see what happened > when I threw multiple threads at my AST. > > What I have is a simple BF language with no specialization (we pass around > Objects and cast to ints/bytes as needed). > > For this test, I parse the source code once, and then have 3 threads > execute the code over and over again. However when truffle kicks in (after > 1000 total invocations of the function), I get the following error: > > [thread:8] scope: > [thread:8] scope: Truffle > [thread:8] scope: Truffle.createGraph > [thread:8] scope: Truffle.createGraph.InterceptException > Exception occurred in scope: Truffle.createGraph.InterceptException > Context obj java.lang.IllegalStateException: Inlined graph is in > invalid state > Context obj > StructuredGraph:4{HotSpotMethod Arguments)>} > Use -G:+DumpOnError to enable dumping of graphs on this error > Context obj DebugDumpScope[Truffle: MainNode at 333bee49] > [truffle] opt failed MainNode at 333bee49 > java.lang.IllegalStateException: Inlined graph is in invalid state > java.lang.IllegalStateException: Inlined graph is in invalid state > > I create a CallTarget per thread, but I do share the AST between all > threads. > > How is this supposed to work in a large language? Am I expected to > duplicate the AST for every thread? And if so, how would I get something > like that to work with thread pools. > > Thanks for the help, > > Timothy Baldridge > -- ?One of the main causes of the fall of the Roman Empire was that?lacking zero?they had no way to indicate successful termination of their C programs.? (Robert Firth) From thomas.wuerthinger at oracle.com Fri Oct 4 01:13:15 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Fri, 4 Oct 2013 10:13:15 +0200 Subject: Truffle multithreaded language In-Reply-To: References: Message-ID: Timothy, The problem below comes from multiple compilations running concurrently. We'll fix the issue and push the changes asap. - thomas On Oct 4, 2013, at 1:14 AM, Timothy Baldridge wrote: > Or perhaps there is a "pre compilation" hook? That way I could lock the AST > before the JIT kicks in. I don't mind a global lock like that, I just don't > want to have to run under a GIL the entire time. > > Timothy > > > On Thu, Oct 3, 2013 at 4:38 PM, Timothy Baldridge wrote: > >> In my continued investigations of Truffle I decided to see what happened >> when I threw multiple threads at my AST. >> >> What I have is a simple BF language with no specialization (we pass around >> Objects and cast to ints/bytes as needed). >> >> For this test, I parse the source code once, and then have 3 threads >> execute the code over and over again. However when truffle kicks in (after >> 1000 total invocations of the function), I get the following error: >> >> [thread:8] scope: >> [thread:8] scope: Truffle >> [thread:8] scope: Truffle.createGraph >> [thread:8] scope: Truffle.createGraph.InterceptException >> Exception occurred in scope: Truffle.createGraph.InterceptException >> Context obj java.lang.IllegalStateException: Inlined graph is in >> invalid state >> Context obj >> StructuredGraph:4{HotSpotMethod> Arguments)>} >> Use -G:+DumpOnError to enable dumping of graphs on this error >> Context obj DebugDumpScope[Truffle: MainNode at 333bee49] >> [truffle] opt failed MainNode at 333bee49 >> java.lang.IllegalStateException: Inlined graph is in invalid state >> java.lang.IllegalStateException: Inlined graph is in invalid state >> >> I create a CallTarget per thread, but I do share the AST between all >> threads. >> >> How is this supposed to work in a large language? Am I expected to >> duplicate the AST for every thread? And if so, how would I get something >> like that to work with thread pools. >> >> Thanks for the help, >> >> Timothy Baldridge >> > > > > -- > ?One of the main causes of the fall of the Roman Empire was that?lacking > zero?they had no way to indicate successful termination of their C > programs.? > (Robert Firth) From doug.simon at oracle.com Fri Oct 4 08:07:10 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 4 Oct 2013 17:07:10 +0200 Subject: Labels using Block numbers for better cfg file output In-Reply-To: References: Message-ID: <443F2E90-BE2C-4E4E-947E-9D99BD7F1BA6@oracle.com> Looks ok to me. I'll integrate this change. On Oct 4, 2013, at 12:27 AM, "Caspole, Eric" wrote: > Hi everybody, > I have been using the c1visualizer with our Graal HSAIL code for about 2 weeks now and it is really nice. I made a small change to the label numbering in Graal to use the Block id as the Label id, so that in the output cfg file the labels in our HSAIL output match the block numbering that appear in the c1visualizer. That way it is easy to glance back and forth between the HSAIL and the CFG in the visualizer and follow along. It worked for a couple different examples/tests that I tried. > > http://cr.openjdk.java.net/~ecaspole/label_block_id.00/webrev/ > > I only made this change for HSAIL but I find it very helpful. Let me know what you think. > Regards, > Eric > From tbaldridge at gmail.com Fri Oct 4 08:42:13 2013 From: tbaldridge at gmail.com (Timothy Baldridge) Date: Fri, 4 Oct 2013 09:42:13 -0600 Subject: Truffle multithreaded language In-Reply-To: References: Message-ID: After some more testing yesterday, I was able to fix the problem by wrapping the call to .compile(this) in a global lock. That seemed to fix the problem. Although it seems that we could this issue again if a AST node decides to modify the tree while compilation is happening in a different thread. Timothy, The problem below comes from multiple compilations running concurrently. We'll fix the issue and push the changes asap. - thomas On Oct 4, 2013, at 1:14 AM, Timothy Baldridge wrote: > Or perhaps there is a "pre compilation" hook? That way I could lock the AST > before the JIT kicks in. I don't mind a global lock like that, I just don't > want to have to run under a GIL the entire time. > > Timothy > > > On Thu, Oct 3, 2013 at 4:38 PM, Timothy Baldridge wrote: > >> In my continued investigations of Truffle I decided to see what happened >> when I threw multiple threads at my AST. >> >> What I have is a simple BF language with no specialization (we pass around >> Objects and cast to ints/bytes as needed). >> >> For this test, I parse the source code once, and then have 3 threads >> execute the code over and over again. However when truffle kicks in (after >> 1000 total invocations of the function), I get the following error: >> >> [thread:8] scope: >> [thread:8] scope: Truffle >> [thread:8] scope: Truffle.createGraph >> [thread:8] scope: Truffle.createGraph.InterceptException >> Exception occurred in scope: Truffle.createGraph.InterceptException >> Context obj java.lang.IllegalStateException: Inlined graph is in >> invalid state >> Context obj >> StructuredGraph:4{HotSpotMethod> Arguments)>} >> Use -G:+DumpOnError to enable dumping of graphs on this error >> Context obj DebugDumpScope[Truffle: MainNode at 333bee49] >> [truffle] opt failed MainNode at 333bee49 >> java.lang.IllegalStateException: Inlined graph is in invalid state >> java.lang.IllegalStateException: Inlined graph is in invalid state >> >> I create a CallTarget per thread, but I do share the AST between all >> threads. >> >> How is this supposed to work in a large language? Am I expected to >> duplicate the AST for every thread? And if so, how would I get something >> like that to work with thread pools. >> >> Thanks for the help, >> >> Timothy Baldridge >> > > > > -- > ?One of the main causes of the fall of the Roman Empire was that?lacking > zero?they had no way to indicate successful termination of their C > programs.? > (Robert Firth) From thomas.wuerthinger at oracle.com Fri Oct 4 08:47:19 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Fri, 4 Oct 2013 17:47:19 +0200 Subject: Truffle multithreaded language In-Reply-To: References: Message-ID: <18A30E08-4217-4206-90A8-EFCE8A103B5A@oracle.com> OK, sounds good. Changes to the AST during compilation should in the current design of your Truffle interpreter not cause problems. We plan to add code that is cancelling currently running compilations in case of AST changes. - thomas On Oct 4, 2013, at 5:42 PM, Timothy Baldridge wrote: > After some more testing yesterday, I was able to fix the problem by wrapping the call to .compile(this) in a global lock. That seemed to fix the problem. Although it seems that we could this issue again if a AST node decides to modify the tree while compilation is happening in a different thread. > Timothy, > > The problem below comes from multiple compilations running concurrently. We'll fix the issue and push the changes asap. > > - thomas > > On Oct 4, 2013, at 1:14 AM, Timothy Baldridge wrote: > > > Or perhaps there is a "pre compilation" hook? That way I could lock the AST > > before the JIT kicks in. I don't mind a global lock like that, I just don't > > want to have to run under a GIL the entire time. > > > > Timothy > > > > > > On Thu, Oct 3, 2013 at 4:38 PM, Timothy Baldridge wrote: > > > >> In my continued investigations of Truffle I decided to see what happened > >> when I threw multiple threads at my AST. > >> > >> What I have is a simple BF language with no specialization (we pass around > >> Objects and cast to ints/bytes as needed). > >> > >> For this test, I parse the source code once, and then have 3 threads > >> execute the code over and over again. However when truffle kicks in (after > >> 1000 total invocations of the function), I get the following error: > >> > >> [thread:8] scope: > >> [thread:8] scope: Truffle > >> [thread:8] scope: Truffle.createGraph > >> [thread:8] scope: Truffle.createGraph.InterceptException > >> Exception occurred in scope: Truffle.createGraph.InterceptException > >> Context obj java.lang.IllegalStateException: Inlined graph is in > >> invalid state > >> Context obj > >> StructuredGraph:4{HotSpotMethod >> Arguments)>} > >> Use -G:+DumpOnError to enable dumping of graphs on this error > >> Context obj DebugDumpScope[Truffle: MainNode at 333bee49] > >> [truffle] opt failed MainNode at 333bee49 > >> java.lang.IllegalStateException: Inlined graph is in invalid state > >> java.lang.IllegalStateException: Inlined graph is in invalid state > >> > >> I create a CallTarget per thread, but I do share the AST between all > >> threads. > >> > >> How is this supposed to work in a large language? Am I expected to > >> duplicate the AST for every thread? And if so, how would I get something > >> like that to work with thread pools. > >> > >> Thanks for the help, > >> > >> Timothy Baldridge > >> > > > > > > > > -- > > ?One of the main causes of the fall of the Roman Empire was that?lacking > > zero?they had no way to indicate successful termination of their C > > programs.? > > (Robert Firth) > From Vasanth.Venkatachalam at amd.com Fri Oct 4 14:18:02 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Fri, 4 Oct 2013 21:18:02 +0000 Subject: questions about decoupling GPU target runtimes from host runtime In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73F91CD66@SATLEXDAG02.amd.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A73F91D08D@SATLEXDAG02.amd.com> Doug, Thanks for the response. Can you give us a rough estimate when these prerequisite changes will be checked in? We're not holding you to this; I'm only asking for our internal planning purposes. I'll be extending other parts of the HSAIL code generator in the meantime and wanted to see how large of a task I can take up. I plan to revisit the work to define the HSAIL CodeCacheProvider once your changes have been checked in. Also let me know if you need me to participate in the discussions you'll be having next week. I can dial-in if needed. Vasanth -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Thursday, October 03, 2013 5:45 PM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net; dl.Runtimes Subject: Re: questions about decoupling GPU target runtimes from host runtime On Oct 4, 2013, at 12:10 AM, "Venkatachalam, Vasanth" wrote: > Doug- > > To remind you the context behind our questions, the host runtime (AMD64HotspotRuntime) is being instantiated and treated as the "default" runtime when we are executing an HSAIL test case. > As a result, the code ends up in an inconsistent state where the HSAIL register configuration is being used, but the underlying runtime is still AMD64. That's why we need to think about extending the API so you can do something like this: Graal.getRequiredCapability(GraalCodeCacheProvider.class, "HSAIL"); This is just an example; the extra qualifier may be something other than a String in the final design. > This problem is affecting more than one place in the code. > > For example, CFGPrinterObserver line 146 looks up the runtime to be AMD64HotSpotRuntime, and as a result CompilationPrinter.debugInfoToString (line 124) gets an ArrayIndexOutOfBoundsException when it tries to lookup an HSAIL register number in an array of AMD64 registers (which has fewer registers than HSAIL). This is causing test cases that exercise a lot of HSAIL registers to fail when we run them with flags to dump a data file for the C1visualizer. The CFGPrinterObserver simply retrieves the CodeCacheProvider from the Debug context. Once you are calling GraalCompiler.compileGraph() with a HSAIL specific GraalCodeCacheProvider object, this issue will be resolved. > The other example is that test cases involving method calls are causing some exception handling snippets to be invoked. The AMD64 definition of these snippets gets loaded and looks for a threadregister (which we haven't specified in HSAIL) and this leads to an assertion error. Once again, a HSAIL specific GraalCodeCacheProvider with its own HSAIL-specific lowering will resolve this. > Are you recommending that we should postpone tackling the underlying problem until the improved support you mention below is in place? Yes. > Is there an interim solution that we could submit as a patch? Unfortunately, not really. We'll make this a high priority and hope to have something by mid next week. -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Thursday, October 03, 2013 1:55 PM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: questions about decoupling GPU target runtimes from host runtime > > Hi Vasanth, > > I will be visiting the team in Linz early next week and we will spend some time improving the support in Graal for multiple backends. If possible, I recommend deferring any further work on the HSAIL backend until we've come up with something. > > -Doug > > On Oct 3, 2013, at 8:39 PM, "Venkatachalam, Vasanth" wrote: > >> Doug- >> >> Thanks for your reply. Some follow-up questions. >> >> 1) Based on this discussion thread and your attached codereview, it sounds like the details for multiple backend support haven't been fully worked out yet. >> Given this, does it still make sense for us to submit a self-contained patch that just refactors PTXHotSpotRuntime, HSAILRuntime to use the delegating interface instead of subclassing HotSpotRuntime? I'm trying to understand if there's value in such a patch before the rest of the refactoring changes are in place to introduce multiple backends and get rid of the duplicate classes (PTXHotSpotBackend ...), and if so, how you would like this done in a self-contained manner while the architecture is in flux. >> >> 2) You mention, >> "We want to have an API where there is exactly one HotSpotGraalRuntime instance that manages multiple backends." >> >> Does this mean that PTXHotSpotGraalRuntime and AMD64HotSpotGraalRuntime should also go away? >> >> Vasanth >> >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Thursday, October 03, 2013 9:25 AM >> To: Venkatachalam, Vasanth >> Cc: graal-dev at openjdk.java.net; Bharadwaj Yadavalli >> Subject: Re: questions about decoupling GPU target runtimes from host runtime >> >> >> On Oct 2, 2013, at 10:48 PM, "Venkatachalam, Vasanth" wrote: >> >>> Doug- >>> >>> We're scoping out the changes needed to isolate the GPU target runtimes (HSAIL, PTX) from the host runtime, so that the host runtime (e.g., AMD64HotspotRuntime) does not get instantiated when we generate code for HSAIL or PTX. This is in part intended to address the comments you sent in sent about http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-r15changes/webrev/ (forwarded below). We had some questions below. >>> >>> 1) All of the platform-specific runtime classes defined so far (PTXHotSpotRuntime, AMD64HotSpotRuntime) are subclassing HotSpotRuntime, which implements the CodeCacheProvider interface. If we understood you correctly, the GPU target runtimes (PtX, HSAIL) should not subclass HotSpotRuntime, because in doing so they would be inheriting code that is HotSpot specfic and not relevant to the GPU target. They should instead be independent classes which extend the DelegatingCodeCacheProvider class and delegate to HotSpotRuntime any functionality that is not target GPU specific. Is this what you had in mind? >> >> Yes. >> >>> 2) The routine graalRuntime( ) in graalVMToCompiler.cpp is checking to see if the UseGPU flag is enabled and if it is (and if the GPU target is PTX) it is instantiating PTXHotSpotGraalRuntime. It sounds like we need to add some logic to check if the GPU target is HSAIL and if so to instantiate the HSAIL runtime class. Am I on the right track? >> >> I'm not so sure that this GPU detection and initialization code is general enough. I can envisage a system with two or more different GPU types available. I've commented on this while reviewing a proposal from Bharadwaj on better support for GPU backends in Graal. I've attached the details of this review (in our internal Crucible instance). >> >>> a. Can you send us the command line to use to check that the UseGPU functionality is working? When I run a PTX test case in NetBeans with -XX:+UseGPU the JVM crashes even before it gets to generate any code. >> >> I've never run with UseGPU enabled. Hopefully Bharadwaj, Morris or Christian (Thalinger) can address this question. >> >>> 3) PTXHotSpotGraalRuntime is creating a PTXHotSpotBackend which looks similar to PTXBackend. What is the purpose of having both the PTXHotSpotBackend and a PTXBackend? It looks like these two classes are duplicating some functionality. Do we need to have an HSAILHotSpotBackend in addition to HSAILBackend? I have a similar question for PTXHotSpotRegisterConfiguration vs. PTXRegisterConfiguration. How should we deal with these pairs of classes in the refactoring you're recommending in 1)? It seems to me like these PTXHotspot* classes should go away if we're truly decoupling the GPU target runtimes from Hotspot. >> >> Yes, they should go away. Hopefully the attached review shows a sketch of how we are thinking this could be achieved. >> >>> 4) Is there a reason why we need both PTXHotspotGraalRuntime in addition to PtXHotSpotRuntime instead of just having a single class that combines the work of both? >> >> We want to have an API where there is exactly one HotSpotGraalRuntime instance that manages multiple backends. >> >> -Doug >> >> >> >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Wednesday, September 11, 2013 9:54 AM >>> To: Venkatachalam, Vasanth >>> Cc: graal-dev at openjdk.java.net >>> Subject: Re: webrev: workaround for threadRegister handling >>> >>> Hi Vasanth, >>> >>> I think you are tackling this problem at the wrong level. All the logic that uses threadRegister and stackPointerRegister is in snippets. The point of snippets is they are the interface the compiler uses to do runtime-specific lowering. I somehow very much doubt that the snippets using these registers will make any sense in the context of the GPU. Even if you plan on implementing new/newarray/monitorenter/monitorexit etc on the GPU, the code will be quite different than that for HotSpot's "host" runtime. After all, they are very specific to HotSpot data structures such as thread local allocation buffers, G1 barriers, etc. >>> >>> In my opinion, you need to have a GraalCodeCacheProvider implementation that does all the GPU specific lowering. To ensure you've got this separation right/complete, your GraalCodeCacheProvider subclass probably shouldn't even subclass HotSpotRuntime. > >>> >>> -Doug >>> >> >> > > > From doug.simon at oracle.com Sat Oct 5 18:00:21 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 06 Oct 2013 01:00:21 +0000 Subject: hg: graal/graal: 76 new changesets Message-ID: <20131006010500.3BCFB62DC7@hg.openjdk.java.net> Changeset: d8659ad83fcc Author: Morris Meyer Date: 2013-09-28 21:06 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/d8659ad83fcc PTX single-threaded array store, Warp annotation ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ArrayPTXTest.java ! 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/PTXArithmetic.java + graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/Warp.java ! src/gpu/ptx/vm/gpu_ptx.cpp ! src/gpu/ptx/vm/ptxKernelArguments.cpp ! src/gpu/ptx/vm/ptxKernelArguments.hpp Changeset: 365d8f385fb5 Author: Morris Meyer Date: 2013-09-29 14:47 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/365d8f385fb5 PTX: one-dimensional parallel warp invocation, ParallelOver annotation ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ArrayPTXTest.java ! 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/PTXLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToGPU.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToGPUImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotNmethod.java + graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/ParallelOver.java + graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/ThreadDimension.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/Warp.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/Variable.java ! src/gpu/ptx/vm/gpu_ptx.cpp ! src/gpu/ptx/vm/gpu_ptx.hpp ! src/share/vm/graal/graalCompilerToGPU.cpp ! src/share/vm/runtime/gpu.cpp ! src/share/vm/runtime/gpu.hpp Changeset: 6440f50c1ea8 Author: Doug Simon Date: 2013-09-30 09:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6440f50c1ea8 improved documentation and testing for ResolvedJavaType.resolveMethod() (GRAAL-489) ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaType.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java Changeset: e1a1264cb0a7 Author: Doug Simon Date: 2013-09-30 09:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e1a1264cb0a7 improved javadoc for ResolvedJavaField.readConstantValue and .readValue ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaField.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java Changeset: 463f51256c86 Author: Bernhard Urban Date: 2013-09-30 09:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/463f51256c86 AMD64HotSpot: emit jump to IC miss handler directly instead of emitting it inside verfied_entry for empty methods we emitted something like this if a inline cache is needed: prefix: 00: < IC check > ... 0b: jne 11: nop ... verified_entry: 20: ret ic_miss_call: 21: jmp when a method is deoptimized, HotSpot patches the verified_entry (0x20) with a jump to a stub that handles call-sites that has been made non-entrant. since this jump is 5 bytes long, it will overwrite ic_miss_call and blow up every caller that calls this method via the unverified entry (prefix). the fix is to emit the jump to the runtime function inside the unverfied entry: prefix: 00: < IC check > ... 0b: je 11: jeq 16: nop ... verified_entry: 20: ret ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java Changeset: 2d3d3d36ab3c Author: Bernhard Urban Date: 2013-09-30 11:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2d3d3d36ab3c AMD64HotSpot: use conditional jump for IC_MISS_HANDLER ! 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.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Call.java ! src/cpu/x86/vm/graalCodeInstaller_x86.hpp Changeset: ff1d8605f354 Author: Bernhard Urban Date: 2013-09-30 11:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ff1d8605f354 graal code installer: minor style cleanup ! src/cpu/x86/vm/graalCodeInstaller_x86.hpp ! src/share/vm/graal/graalCodeInstaller.cpp Changeset: 1d64bfb3f481 Author: Lukas Stadler Date: 2013-09-30 14:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1d64bfb3f481 new PrintAfterCompilation option, simplify PrintCompilation output ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: 0ffb6ed18ea4 Author: Doug Simon Date: 2013-09-30 10:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0ffb6ed18ea4 omit canonicalization in IncrementalCanonicalizerPhase if none of the contained phases changed the graph ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/IncrementalCanonicalizerPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/PhaseSuite.java Changeset: 6ce3677f09f5 Author: Doug Simon Date: 2013-09-30 16:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6ce3677f09f5 enhanced test for CipherBlockChaining substitutions to cover path where the substitutions call the original (i.e. substituted) methods on slow paths ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotCryptoSubstitutionTest.java Changeset: 4187b229d2ec Author: Doug Simon Date: 2013-09-30 16:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4187b229d2ec Merge. Changeset: 97d6932a309b Author: Gilles Duboscq Date: 2013-09-26 14:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/97d6932a309b CodeCacheProvider.encodeDeoptActionAndReason now returns a Constant ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CodeCacheProvider.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/DelegatingCodeCacheProvider.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/AMD64HotSpotDeoptimizeCallerOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.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/SPARCHotSpotDeoptimizeCallerOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: b71a1d889db2 Author: Gilles Duboscq Date: 2013-09-26 16:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b71a1d889db2 SpeculationLog gives back the necessary Constant when calling maySpeculate. Remove the deoptimizationReasonfrom the DebugInfo Remove the speculationLog from LIR, it can be passed through a context to the phases that need it. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/DebugInfo.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/SpeculationLog.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/DebugInfoBuilder.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotDebugInfoBuilder.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotLIRFrameState.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIR.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRFrameState.java Changeset: 24ff15442a09 Author: Gilles Duboscq Date: 2013-09-26 16:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/24ff15442a09 Remove DeoptimizingNode.getDeoptimizationReason ! 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.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/DeoptimizingStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1PreWriteBarrier.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizingNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/SafepointNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FixedBinaryNode.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/FloatingAccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/NullCheckNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AbstractNewArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewInstanceNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewMultiArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/RegisterFinalizerNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LIRGeneratorTool.java Changeset: 2d74afd9e5ed Author: Gilles Duboscq Date: 2013-09-26 16:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2d74afd9e5ed Fix copyright date in NodeWithState ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/NodeWithState.java Changeset: d72c314260dc Author: Gilles Duboscq Date: 2013-09-26 17:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d72c314260dc Add a DynamicDeoptimizeNode where the action and reason is a input node. ! 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.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.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/AbstractDeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizeNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DynamicDeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LIRGeneratorTool.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/DeoptimizationGroupingPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java Changeset: bd3441f941f9 Author: Gilles Duboscq Date: 2013-09-26 17:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bd3441f941f9 Use ControlSplitNode and ControlSinkNode in GraphBuilderPhase.isBlockEnd Remove Util.isFixed/isFloating ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/util/Util.java Changeset: 16d0eb40d31c Author: Gilles Duboscq Date: 2013-09-30 18:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/16d0eb40d31c Merge ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 0e2cceed1caf Author: Gilles Duboscq Date: 2013-09-30 16:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0e2cceed1caf Temporarily move encodeDeoptActionAndReason to MetaAccessProvider Add AbstractDeoptimizeNode.getActionAndReason ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CodeCacheProvider.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/DelegatingCodeCacheProvider.java - graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/DeoptimizationAction.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/DelegatingMetaAccessProvider.java + graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/DeoptimizationAction.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaAccessProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/DeoptimizeCallerNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CheckCastDynamicSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/InstanceOfSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/StubUtil.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/CountedLoopInfo.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractDeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DynamicDeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/EliminatePartiallyRedundantGuardsPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/AssumptionNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerExactArithmeticSplitNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameAccessNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/CompilerDirectivesSubstitutions.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/FrameWithoutBoxingSubstitutions.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/UnexpectedResultExceptionSubstitutions.java Changeset: 51d5a22e0ea9 Author: Gilles Duboscq Date: 2013-09-30 16:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/51d5a22e0ea9 Keep the correct Deoptimization reason and action while grouping Deoptimizations ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/DeoptimizationGroupingPhase.java Changeset: 6157a71e0a36 Author: Gilles Duboscq Date: 2013-09-30 17:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6157a71e0a36 Fix wrong local variable name in LoopPolicies.shouldFullUnroll ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopPolicies.java Changeset: 8d8f63069f58 Author: Morris Meyer Date: 2013-09-30 13:03 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/8d8f63069f58 PTX warp limiter to available GPU processors ! 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.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToGPU.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToGPUImpl.java ! src/gpu/ptx/vm/gpu_ptx.cpp ! src/gpu/ptx/vm/gpu_ptx.hpp ! src/share/vm/graal/graalCompilerToGPU.cpp ! src/share/vm/runtime/gpu.cpp ! src/share/vm/runtime/gpu.hpp Changeset: 372bacc13022 Author: Andreas Woess Date: 2013-09-30 21:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/372bacc13022 gtx_ptx.cpp: fix switch default label and operator precedence in ncores(). ! src/gpu/ptx/vm/gpu_ptx.cpp Changeset: 1ce74467ab51 Author: Bernhard Urban Date: 2013-09-30 16:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1ce74467ab51 SnippetTemplate: remove canonicalizer. remove loop for return node. copy Set on user side ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 7b51e43b05cd Author: Bernhard Urban Date: 2013-09-30 16:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7b51e43b05cd NewObjectSnippets: don't use a seperate location for initializing the array length field ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java Changeset: 41a2a20d4949 Author: Bernhard Urban Date: 2013-09-30 16:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/41a2a20d4949 MemoryMap: move to graal.nodes package - graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MemoryMap.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryMap.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryState.java Changeset: f5faf49a86dd Author: Bernhard Urban Date: 2013-09-30 22:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f5faf49a86dd remove MemoryState, make MemoryMap a node, add MemoryMap input to ReturnNode - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryMap.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryMapNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryState.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ReturnNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/InstanceOfSnippetsTemplates.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 099af41815ea Author: Michael Van De Vanter Date: 2013-09-30 20:47 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/099af41815ea Truffle: add NodeUtil.printSourceAttributionTree() for debugging ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: 73a2f5fc8625 Author: Michael Van De Vanter Date: 2013-10-01 07:23 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/73a2f5fc8625 Merge with f5faf49a86dd4bfd8e5ff6b9d6beedd280ea3f69 - graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MemoryMap.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryState.java Changeset: e68922869732 Author: Michael Van De Vanter Date: 2013-10-01 17:26 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e68922869732 Truffle: minor legibility improvement in NodeUtil.printSourceAttributionTree() ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: 04b039d82e86 Author: Roland Schatz Date: 2013-10-02 12:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/04b039d82e86 Simplify constant folding. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ArithmeticOperation.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/AndNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConvertNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatAddNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatMulNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatRemNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatSubNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerAddNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerMulNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerSubNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/LeftShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/NegateNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/NotNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/OrNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/RightShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedRightShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/XorNode.java ! graal/com.oracle.graal.replacements.amd64/src/com/oracle/graal/replacements/amd64/AMD64ConvertNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MathIntrinsicNode.java Changeset: d7964e96b0b0 Author: Lukas Stadler Date: 2013-09-30 18:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d7964e96b0b0 move benchmark counters into separate class and make them correct for multithreaded applications ! 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/VMToCompilerImpl.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/debug/BenchmarkCounters.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/debug/DynamicCounterNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/debug/SurvivingCounterNode.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/GraphEffectList.java ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: e994bf28ed2f Author: Lukas Stadler Date: 2013-09-30 18:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e994bf28ed2f Merge Changeset: 3b6a8b78233c Author: Lukas Stadler Date: 2013-10-02 13:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3b6a8b78233c remove unused EscapeState.ThreadLocal ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/Virtualizable.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ObjectState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java Changeset: 028467823d3f Author: Lukas Stadler Date: 2013-10-02 10:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/028467823d3f small javadoc fix ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectList.java Changeset: 7a5182bd2175 Author: Lukas Stadler Date: 2013-10-02 10:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7a5182bd2175 remove unused method from VirtualizerTool ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/VirtualizerTool.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualizerToolImpl.java Changeset: 3aef4d88fbb9 Author: Lukas Stadler Date: 2013-10-02 13:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3aef4d88fbb9 simplify PEA block states by turning scalarAliases and objectAliases into one global NodeMap ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsBlockState.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/PEReadEliminationBlockState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PEReadEliminationClosure.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeBlockState.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/ReadEliminationBlockState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationClosure.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualizerToolImpl.java Changeset: cdff87c89c5f Author: Lukas Stadler Date: 2013-10-02 13:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cdff87c89c5f Merge - graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/DeoptimizationAction.java - graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MemoryMap.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryState.java Changeset: ee88780346a4 Author: Roland Schatz Date: 2013-10-02 14:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ee88780346a4 Fix bug in constant folding. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatAddNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatMulNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatRemNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatSubNode.java Changeset: 762dc2f23d1c Author: Bernhard Urban Date: 2013-10-02 11:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/762dc2f23d1c InvokeWithException: make next successor a special begin node which has the same locationidentity as the invoke InvokeWithExceptionNode has the unpleasant property that it is a ControlSplit and MemoryCheckPoint at the same time. In terms of scheduling, a node cannot be placed after a ControlSplit node as it denotes the end of a block. Thus, instead of connecting a FloatingReadNode to the InvokeWithException node directly (as lastLocationAccess), we point rather to the BeginNode (non-exceptional case) or ExceptionBeginNode. To preserve consistency regarding memory dependencies, the former node must be also a MemoryCheckPoint. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/KillingBeginNode.java Changeset: fb218ac55362 Author: Bernhard Urban Date: 2013-09-25 19:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fb218ac55362 FloatingReadNode: add verify(), make sure that lastLocationAccess is always a MemoryCheckpoint ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatingReadNode.java Changeset: 4635fdfd8256 Author: Bernhard Urban Date: 2013-10-02 11:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4635fdfd8256 MemoryScheduling: update testcases ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java Changeset: 7763a42d1658 Author: Bernhard Urban Date: 2013-10-02 13:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7763a42d1658 NewMemoryAwareScheduling: handle MemoryPhis properly remove earliest hack and some refactoring ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java Changeset: fbcde297f87a Author: Bernhard Urban Date: 2013-10-02 11:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fbcde297f87a NewMemoryAwareScheudling: process loop a second time in order to compute the loop exists correctly with the new merged state ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java Changeset: 3d97040060d4 Author: Bernhard Urban Date: 2013-10-02 11:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3d97040060d4 SchedulePhase: bail out with SchedulingError if scheduled block is not dominated by earliest ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java Changeset: 2111551cfb34 Author: Bernhard Urban Date: 2013-10-02 15:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2111551cfb34 CommitAllocation: use INIT_LOCATION for initializing objects and arrays ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 952ecf32788a Author: Chris Seaton Date: 2013-10-02 14:19 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/952ecf32788a mx sl command. ! mx/commands.py Changeset: 44257a9160f1 Author: Chris Seaton Date: 2013-10-02 14:46 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/44257a9160f1 Merge. Changeset: 18824519c172 Author: Chris Seaton Date: 2013-10-02 15:37 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/18824519c172 Merge. Changeset: a80d09922fc1 Author: Lukas Stadler Date: 2013-10-02 14:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a80d09922fc1 new parameter on Snippet annotation to remove all frame states ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/ObjectAccessTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/PointerTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/WordTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/Snippet.java Changeset: 69a527047c40 Author: Lukas Stadler Date: 2013-10-02 14:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/69a527047c40 fix, simplify and enable ObjectClone intrinsification ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java Changeset: 5501a34d43bb Author: Lukas Stadler Date: 2013-10-02 15:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5501a34d43bb remove unused option ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: 8a201c64cd18 Author: Lukas Stadler Date: 2013-10-02 15:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8a201c64cd18 in-depth profiling of allocations and monitors ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java Changeset: e0041af765c5 Author: Lukas Stadler Date: 2013-10-02 15:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e0041af765c5 some more javadoc for benchmark counters ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/debug/BenchmarkCounters.java Changeset: 35bdfb9ac12f Author: Lukas Stadler Date: 2013-08-21 15:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/35bdfb9ac12f don't tail duplicate object allocations ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java Changeset: acfff1de2aa7 Author: Lukas Stadler Date: 2013-10-02 17:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/acfff1de2aa7 Merge Changeset: ef895852aeb4 Author: Lukas Stadler Date: 2013-10-02 18:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ef895852aeb4 fix signature of reflective invocation of ReplacementsImpl.makeGraph ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java Changeset: 39e9ec0cf310 Author: Bernhard Urban Date: 2013-10-02 21:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/39e9ec0cf310 Inlining: remove killing begin node in non-exceptional path of InvokeWithException after inlining ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: 7e57add9c0d5 Author: Doug Simon Date: 2013-10-01 20:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7e57add9c0d5 broadened types in SimplifierTool interface so that it can be moved to the com.oracle.graal.graph project (GRAAL-506) ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/SimplifierTool.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/CanonicalizerPhase.java Changeset: 9a747d8e0d0f Author: Doug Simon Date: 2013-10-01 20:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9a747d8e0d0f broadened types in Canonicalizable interface so that it can be moved to the com.oracle.graal.graph project (GRAAL-506) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassCastNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassGetComponentTypeNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassGetModifiersNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassGetSuperclassNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassIsArrayNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassIsInstanceNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassIsInterfaceNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassIsPrimitiveNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CallSiteTargetNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleInvokeBasicNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToInterfaceNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToSpecialNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToStaticNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToVirtualNode.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/ReflectionGetCallerClassNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardedValueNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicNegationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ProxyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ShortCircuitOrNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/AndNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/CompareNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConditionalNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConvertNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatAddNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatLessThanNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatMulNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatRemNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatSubNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerAddNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerBelowThanNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerEqualsNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerLessThanNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerMulNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerRemNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerSubNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerTestNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IsNullNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/LeftShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/NegateNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/NotNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ObjectEqualsNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/OrNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/RightShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedRemNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedRightShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/XorNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AddLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/BoxNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/BranchProbabilityNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatingReadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/IndexedLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadHubNode.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/SnippetLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnboxNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeAccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeCastNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ValueAnchorNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AbstractNewArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ArrayLengthNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastDynamicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.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/InstanceOfDynamicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadFieldNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MethodCallTargetNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewInstanceNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/RegisterFinalizerNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/Canonicalizable.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/BitCountNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/BitScanForwardNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/BitScanReverseNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/LoadSnippetVarargParameterNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MathIntrinsicNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/PureFunctionMacroNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/ReverseBytesNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/BailoutNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/LoadIndexedFinalNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerAddExactNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerMulExactNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerSubExactNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/asserts/CompilationConstantNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/NewFrameNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomTypeCheckMacroNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/TypeCastMacroNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/UnsafeCustomizationMacroNode.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/nodes/WordCastNode.java Changeset: da9db8331658 Author: Doug Simon Date: 2013-10-01 20:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/da9db8331658 moved Canonicalizable and Simplifiable to the com.oracle.graal.graph project (GRAAL-506) = graal/com.oracle.graal.graph/src/com/oracle/graal/graph/spi/Canonicalizable.java < graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/Canonicalizable.java + graal/com.oracle.graal.graph/src/com/oracle/graal/graph/spi/CanonicalizerTool.java + graal/com.oracle.graal.graph/src/com/oracle/graal/graph/spi/Simplifiable.java + graal/com.oracle.graal.graph/src/com/oracle/graal/graph/spi/SimplifierTool.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassCastNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassGetComponentTypeNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassGetModifiersNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassGetSuperclassNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassIsArrayNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassIsInstanceNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassIsInterfaceNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassIsPrimitiveNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AbstractMethodHandleNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CallSiteTargetNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleInvokeBasicNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToInterfaceNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToSpecialNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToStaticNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToVirtualNode.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/ReflectionGetCallerClassNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/EntryMarkerNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardedValueNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicNegationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopExitNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MergeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ProxyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ShortCircuitOrNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/AndNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/CompareNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConditionalNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConvertNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatAddNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatLessThanNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatMulNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatRemNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatSubNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerAddNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerBelowThanNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerEqualsNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerLessThanNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerMulNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerRemNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerSubNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerTestNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IsNullNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/LeftShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/NegateNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/NotNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ObjectEqualsNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/OrNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/RightShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedRemNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedRightShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/XorNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/debug/SurvivingCounterNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AddLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/BoxNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/BranchProbabilityNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatingReadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/IndexedLocationNode.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/LoadHubNode.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/SnippetLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnboxNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeAccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeCastNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ValueAnchorNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AbstractNewArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ArrayLengthNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastDynamicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.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/ExceptionObjectNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfDynamicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadFieldNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MethodCallTargetNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewInstanceNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/RegisterFinalizerNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/TypeSwitchNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/CanonicalizerTool.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/Simplifiable.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/SimplifierTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/CommitAllocationNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/IterativeConditionalEliminationPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/BitCountNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/BitScanForwardNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/BitScanReverseNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/LoadSnippetVarargParameterNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MathIntrinsicNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/PureFunctionMacroNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/ReverseBytesNode.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 ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/AssumptionNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/BailoutNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/LoadIndexedFinalNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerAddExactNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerMulExactNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerSubExactNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/asserts/CompilationConstantNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameAccessNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/NewFrameNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomTypeCheckMacroNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/TypeCastMacroNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/UnsafeCustomizationMacroNode.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsPhase.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/nodes/WordCastNode.java ! mx/projects Changeset: 51059863da73 Author: Doug Simon Date: 2013-10-02 20:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/51059863da73 replace instanceof type tests for Canonicalizable and Simplifiable with extra boolean properties in NodeClass (GRAAL-506) ! 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.hotspot/src/com/oracle/graal/hotspot/nodes/ClassCastNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassGetComponentTypeNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassGetModifiersNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassGetSuperclassNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassIsArrayNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassIsInstanceNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassIsInterfaceNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassIsPrimitiveNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectGetClassNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardedValueNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicNegationNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/PureFunctionMacroNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/AssumptionNode.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/nodes/WordCastNode.java Changeset: 673f93db4adc Author: Doug Simon Date: 2013-10-02 21:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/673f93db4adc Merge. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/AndNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConvertNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatAddNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatMulNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatRemNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatSubNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerAddNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerMulNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerSubNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/LeftShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/NegateNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/NotNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/OrNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/RightShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedRightShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/XorNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/debug/SurvivingCounterNode.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/CanonicalizerPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MathIntrinsicNode.java Changeset: 008500ebc6c6 Author: Doug Simon Date: 2013-10-02 21:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/008500ebc6c6 modified CustomCanonicalizer to deal with Nodes (instead of ValueNodes) to avoid extra type testing during canonicalization (GRAAL-506) ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluatorCanonicalizer.java Changeset: e602861c3f7d Author: Doug Simon Date: 2013-10-02 22:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e602861c3f7d Merge. Changeset: f759edd9e809 Author: Doug Simon Date: 2013-10-02 22:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f759edd9e809 canonicalized projects ! mx/projects Changeset: 535403a95e65 Author: Gilles Duboscq Date: 2013-10-03 10:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/535403a95e65 Fix problem with FloatStamp/IntegerStamp.alwaysDistinct throwing NPE ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/FloatStamp.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/IllegalStamp.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/IntegerStamp.java Changeset: e0eb7619433f Author: Roland Schatz Date: 2013-10-03 11:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e0eb7619433f Implement FloatStamp.asConstant. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/FloatStamp.java Changeset: b168635707b5 Author: Doug Simon Date: 2013-10-03 17:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b168635707b5 fix line wrapping issue when printing help for options ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java Changeset: 038b834a66f1 Author: Roland Schatz Date: 2013-10-03 18:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/038b834a66f1 Fix wrong typecast. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/FloatStamp.java Changeset: 7b50d3841398 Author: Doug Simon Date: 2013-10-03 21:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7b50d3841398 removed dead or unused code ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValueNode.java Changeset: 4ac39f060a9d Author: Doug Simon Date: 2013-10-04 00:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4ac39f060a9d added block ids to Labels Contributed-by: Eric Caspole ! graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/AbstractHSAILAssembler.java ! graal/com.oracle.graal.asm/src/com/oracle/graal/asm/Label.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java Changeset: ec267141f753 Author: Lukas Stadler Date: 2013-10-04 11:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ec267141f753 more javadoc and output tweaks for dynamic counters ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/debug/BenchmarkCounters.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/debug/SurvivingCounterNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/debug/WeakCounterNode.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/GraphEffectList.java ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: c7abc8411011 Author: Morris Meyer Date: 2013-10-05 10:31 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/c7abc8411011 Fixed BasicPTXTest and IntegerPTXTest ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/BasicPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/FloatPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/IntegerPTXTest.java ! src/gpu/ptx/vm/gpu_ptx.cpp ! src/gpu/ptx/vm/gpu_ptx.hpp ! src/gpu/ptx/vm/ptxKernelArguments.cpp ! src/gpu/ptx/vm/ptxKernelArguments.hpp Changeset: 8e15a8b570e1 Author: Morris Meyer Date: 2013-10-05 10:37 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/8e15a8b570e1 Disable broken BitCountNode integer / long substition test ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/StandardMethodSubstitutionsTest.java Changeset: 280f97f13d54 Author: Morris Meyer Date: 2013-10-05 16:51 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/280f97f13d54 Fixes to PTX control flow logic ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ArrayPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ControlPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/FloatPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/IntegerPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/LogicPTXTest.java ! 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/PTXLIRGenerator.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXControlFlow.java From Vasanth.Venkatachalam at amd.com Tue Oct 8 09:11:49 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Tue, 8 Oct 2013 16:11:49 +0000 Subject: handling of Math intrinsics for multiple GPU targets Message-ID: <5DD1503F815BD14889DC81D28643E3A73F91F63A@SATLEXDAG02.amd.com> Hi, I noticed that Graal is building a superset of math intrinsics for the host runtime (x86) and then filtering out some of these methods from being intrinsified based on the value of a config parameter (e.g., config.usePopCountIinstruction, config.useAESIntrinsics, etc.). In more detail when the VM first starts up in VMToCompilerImpl.start() it gets the host runtime (which is x86) and builds a superset of intrinsics for that runtime by calling GraalMethodSubstitutions.registerReplacements( ). This in turn processes a class file MathSubstitutionsx86.class to get a list of math routines to be intrinsified, filters out some of these routines (via a call to HotSpotReplacementsImpl.registerMethodSubstitution()) and adds the remaining ones to a HashMap called registeredMethodSubstitutions. For the case of supporting multiple GPU targets, it sounds like this logic is the reverse of what we need. Instead of building a superset of intrinsics for x86 and filtering them for the target runtime, we need a way for each target runtime (e.g., HSAIL) to specify its own list of supported intrinsics. Has anyone thought about how this should be handled? Vasanth From doug.simon at oracle.com Tue Oct 8 11:08:25 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 8 Oct 2013 20:08:25 +0200 Subject: handling of Math intrinsics for multiple GPU targets In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73F91F63A@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73F91F63A@SATLEXDAG02.amd.com> Message-ID: This is obviously something else that needs to be vectored to each backend, allowing each to make their own decision as you say. It will be factored into the redesign currently going on. Please let us know of other abstractions like this that need to be broadened or exposed to each backend. On Oct 8, 2013, at 6:11 PM, "Venkatachalam, Vasanth" wrote: > Hi, > > I noticed that Graal is building a superset of math intrinsics for the host runtime (x86) and then filtering out some of these methods from being intrinsified based on the value of a config parameter (e.g., config.usePopCountIinstruction, config.useAESIntrinsics, etc.). > > In more detail when the VM first starts up in VMToCompilerImpl.start() it gets the host runtime (which is x86) and builds a superset of intrinsics for that runtime by calling GraalMethodSubstitutions.registerReplacements( ). This in turn processes a class file MathSubstitutionsx86.class to get a list of math routines to be intrinsified, filters out some of these routines (via a call to HotSpotReplacementsImpl.registerMethodSubstitution()) and adds the remaining ones to a HashMap called registeredMethodSubstitutions. > > For the case of supporting multiple GPU targets, it sounds like this logic is the reverse of what we need. Instead of building a superset of intrinsics for x86 and filtering them for the target runtime, we need a way for each target runtime (e.g., HSAIL) to specify its own list of supported intrinsics. Has anyone thought about how this should be handled? > > Vasanth > > From wei.zhang at uci.edu Wed Oct 9 23:31:44 2013 From: wei.zhang at uci.edu (Wei Zhang) Date: Wed, 9 Oct 2013 23:31:44 -0700 Subject: Truffle deoptimization Message-ID: Hi all, I had a problem when I try to figure out why one of my benchmark is getting deoptimized after being compiled by Truffle. I tried using -XX:+TraceDeoptimization, but it doesn't give me enough info so I can track down what the problem was... This is the small python program that I was testing: https://bitbucket.org/ssllab/zippy/src/580d8e06b4045a10af0e8ea87618aa997d4d12e4/graal/edu.uci.python.benchmark/src/micro/arith_binop.py?at=default I ran it with this command: ./mx.sh --vm server python graal/edu.uci.python.benchmark/src/micro/arith_binop.py @-XX:+TraceDeoptimization @-esa @-ea The related printout from graal: --------------------------------------------- [truffle] optimized |Nodes 39 |Time 4746(1299+3447)ms |Nodes 312/ 1073 |CodeSize 6023 Uncommon trap bci=2 pc=40238440, relative_pc=488, method=contains Uncommon trap occurred in com.oracle.graal.truffle.OptimizedCallTarget::executeHelper (@0x000000010265fd68) thread=6403 reason=null_check action=reinterpret unloaded_class_index=-1 Uncommon trap bci=57 pc=39641592, relative_pc=5848, method=callHelper Uncommon trap occurred in edu.uci.python.nodes.PNode::executeDouble (@0x00000001025ce1f8) thread=6403 reason=unloaded action=reinterpret unloaded_class_index=-1 [truffle] invalidated |Alive 6ms |Inv# 1 |Replace# 33 --------------------------------------------- It says PNode.executeDouble, but there's no node rewrite after the invalidation. Btw, what does "unloaded" mean as a reason? I suspect it is caused by the function call in the loop body of my testing program. But there's no CompilerDirectives.transferToInterpreter() or Assumption invalidation in my CallFunctionNode. The source of the Node is: https://bitbucket.org/ssllab/zippy/src/580d8e06b4045a10af0e8ea87618aa997d4d12e4/graal/edu.uci.python.nodes/src/edu/uci/python/nodes/calls/CallFunctionNode.java?at=default After head scratching and trying random stuff for half a day, I though I should ask about this here. Any help is welcome, thanks! /Wei Zhang, Wei UCI-EECS-CSS From D.Sturm42 at gmail.com Fri Oct 11 07:51:05 2013 From: D.Sturm42 at gmail.com (D.Sturm) Date: Fri, 11 Oct 2013 16:51:05 +0200 Subject: Integer specialisation of BitScanForwardNode Message-ID: BitScanForwardNode only has a single @NodeIntrinsic method that takes a long. As a consequence when computing it for an int we first sign-extend it to a long, e.g.: cmp edx,0x0 je 0x11 movsxd rax,edx bsf rax,rax Could we introduce a new method taking an int to avoid this? From tom.deneau at amd.com Fri Oct 11 07:55:48 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 11 Oct 2013 14:55:48 +0000 Subject: questions on Word operations In-Reply-To: <5234F15D.3050808@oracle.com> References: <52334909.70403@oracle.com> <5234F15D.3050808@oracle.com> Message-ID: I am working on adding a new AtomicGetAndAddNode as Christian described below. One obstacle I am hitting... I would like to have a @NodeIntrinsic in this AtomicGetAndAddNode class that takes Word parameters. But com.oracle.graal.nodes does not have com.oracle.graal.word as a dependency, and when I add it as a dependency I get a loop. What is the best way around this? -- Tom -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Christian Wimmer Sent: Saturday, September 14, 2013 6:30 PM Cc: graal-dev at openjdk.java.net Subject: Re: questions on Word operations Tom, So you want to use a atomicGetAndAdd instruction from a snippet, similarly to the CompareAndSwap that is already in Graal (because it is accessible via sun.misc.Unsafe). I would say the easiest way is to create a new AtomicGetAndAddNode, and provide the proper lowering to a new LIR Operation. You can access the new node from a snippet via a node intrinsic - a method annotated with @NodeIntrinsic in the node class. The parameter list of the node intrinsic corresponds with the constructor parameters of the node class, and the pre-processing that Graal is doing for the snippet replaces the call to the node intrinsic method with an actual node instance. -Christian On 9/13/2013 11:30 AM, Deneau, Tom wrote: > Christian -- > > Yes, I should have stated the final goal and maybe there is a better way to do what we want to do... > > We want to support object allocation from an HSA GPU. (or at least to get an idea whether it is worth supporting it). > > At a high level, there would be a bunch of TLABS available for the gpu to use. > For the initial prototype these could be the TLABs from actual java "donor threads" whose only purpose is to supply their TLAB > (the java donor threads wouldn't allocate into their own TLAB). > > Since the HSA GPU has the same view of memory as the cpu, we thought perhaps we could > just use the non-atomic pointer bump snippet that is used with HotspotRuntime. > We confirmed this works for small numbers of workitems but the high parallelism of > the gpu means an unreasonably high number of donor threads would be needed for the general case. > > So we are now experimenting with multiple GPU workitems sharing a TLAB and allocatin using an atomic pointer bump. > We know the HSAIL code we want to end up with, but I just don't have any experience with > Graal Snippets and such to make graal emit this HSAIL code (as you can tell from my questions). > > But maybe there is an easier way to get graal to emit this allocation code? > > -- Tom > > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Christian Wimmer > Sent: Friday, September 13, 2013 12:19 PM > To: graal-dev at openjdk.java.net > Subject: Re: questions on Word operations > > All functions on word types (everything implementing the interface > WordBase) are compiler intrinsics. If you use Word in a snippet, and call one of the methods on it, the body of these methods is actually irrelevant. The only thing that matters is how the WordTypeRewriterPhase replaces the method call with low-level compiler nodes. The @Operation annotation is used by the WordTypeRewriterPhase to distinguish what to do. > > Word only provides the very basic arithmetic and memory operations (+, -, * , /, read, write). Adding methods for atomic operations like you want is possible, but I don't think it is the easiest way to achieve what you want to do. > > Can you explain what your final goal is? > > -Christian > > > On 09/13/2013 09:47 AM, Deneau, Tom wrote: >> I would like to add a new Word method that can be used from an allocation Snippet I am trying to write. >> >> The new method would look like: >> >> public Word atomicGetAndAddWord(int offset, int delta) { >> >> } >> >> So given a Word (address), this would do an atomic get and add of delta on the word located at the address this.rawValue + offset. Like j.u.c.atomic.getAndAdd, it would return the original word value at that address. >> >> A couple of questions: >> >> * Is the following a legal body for such a method? I see that it >> compiles but is it legal to call toObject() on a Word value? As used >> in the snippet the Word value would be the pointer returned by >> thread(). I noticed there is no unsafe.getAndAddLong(long address, >> long delta), only unsafe.getAndAddLong(Object o, long offset, long >> delta) >> >> return box(unsafe.getAndAddLong(toObject(), offset, >> delta)); >> >> * I notice all the Word methods have @Operation annotations but I don't really understand the semantics of this annotation. What should be the annotation for this method? >> >> >> * What is the purpose of the locationIdentity parameter on some >> of the word operations such as >> >> @Operation(opcode = Opcode.READ) >> public Word readWord(WordBase offset, LocationIdentity locationIdentity) { >> return box(unsafe.getAddress(add((Word) offset).unbox())); >> } >> >> -- Tom >> > > From christian.wimmer at oracle.com Fri Oct 11 09:04:53 2013 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Fri, 11 Oct 2013 09:04:53 -0700 Subject: questions on Word operations In-Reply-To: References: <52334909.70403@oracle.com> <5234F15D.3050808@oracle.com> Message-ID: <525821A5.3000204@oracle.com> You can define the @NodeIntrinsic in another class, e.g., the class where you want to call it (and there you have per definition the Word class available). @NodeIntrinsic has a parameter that specifies the Node class that it is creating, so you can write @NodeIntrinsics(AtomicGetAndAddNode.class) public static native void atomicGetAndAdd(Word param, ...) I'm not sure if the return type of your method is Word, but if it is, you also have to be careful with the stamp that the node gets: it needs to be the correct wordKind (Kind.Int or Kind.Long). Use the property setStampFromReturnType then, i.e, @NodeIntrinsics(value = AtomicGetAndAddNode.class, setStampFromReturnType = true) public static native Word atomicGetAndAdd(Word param, ...) -Christian On 10/11/2013 07:55 AM, Deneau, Tom wrote: > I am working on adding a new AtomicGetAndAddNode as Christian described below. > > One obstacle I am hitting... > I would like to have a @NodeIntrinsic in this AtomicGetAndAddNode class that takes Word parameters. But com.oracle.graal.nodes does not have com.oracle.graal.word as a dependency, and when I add it as a dependency I get a loop. > > What is the best way around this? > > -- Tom > > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Christian Wimmer > Sent: Saturday, September 14, 2013 6:30 PM > Cc: graal-dev at openjdk.java.net > Subject: Re: questions on Word operations > > Tom, > > So you want to use a atomicGetAndAdd instruction from a snippet, > similarly to the CompareAndSwap that is already in Graal (because it is > accessible via sun.misc.Unsafe). > > I would say the easiest way is to create a new AtomicGetAndAddNode, and > provide the proper lowering to a new LIR Operation. > > You can access the new node from a snippet via a node intrinsic - a > method annotated with @NodeIntrinsic in the node class. The parameter > list of the node intrinsic corresponds with the constructor parameters > of the node class, and the pre-processing that Graal is doing for the > snippet replaces the call to the node intrinsic method with an actual > node instance. > > -Christian > > > On 9/13/2013 11:30 AM, Deneau, Tom wrote: >> Christian -- >> >> Yes, I should have stated the final goal and maybe there is a better way to do what we want to do... >> >> We want to support object allocation from an HSA GPU. (or at least to get an idea whether it is worth supporting it). >> >> At a high level, there would be a bunch of TLABS available for the gpu to use. >> For the initial prototype these could be the TLABs from actual java "donor threads" whose only purpose is to supply their TLAB >> (the java donor threads wouldn't allocate into their own TLAB). >> >> Since the HSA GPU has the same view of memory as the cpu, we thought perhaps we could >> just use the non-atomic pointer bump snippet that is used with HotspotRuntime. >> We confirmed this works for small numbers of workitems but the high parallelism of >> the gpu means an unreasonably high number of donor threads would be needed for the general case. >> >> So we are now experimenting with multiple GPU workitems sharing a TLAB and allocatin using an atomic pointer bump. >> We know the HSAIL code we want to end up with, but I just don't have any experience with >> Graal Snippets and such to make graal emit this HSAIL code (as you can tell from my questions). >> >> But maybe there is an easier way to get graal to emit this allocation code? >> >> -- Tom >> >> >> -----Original Message----- >> From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Christian Wimmer >> Sent: Friday, September 13, 2013 12:19 PM >> To: graal-dev at openjdk.java.net >> Subject: Re: questions on Word operations >> >> All functions on word types (everything implementing the interface >> WordBase) are compiler intrinsics. If you use Word in a snippet, and call one of the methods on it, the body of these methods is actually irrelevant. The only thing that matters is how the WordTypeRewriterPhase replaces the method call with low-level compiler nodes. The @Operation annotation is used by the WordTypeRewriterPhase to distinguish what to do. >> >> Word only provides the very basic arithmetic and memory operations (+, -, * , /, read, write). Adding methods for atomic operations like you want is possible, but I don't think it is the easiest way to achieve what you want to do. >> >> Can you explain what your final goal is? >> >> -Christian >> >> >> On 09/13/2013 09:47 AM, Deneau, Tom wrote: >>> I would like to add a new Word method that can be used from an allocation Snippet I am trying to write. >>> >>> The new method would look like: >>> >>> public Word atomicGetAndAddWord(int offset, int delta) { >>> >>> } >>> >>> So given a Word (address), this would do an atomic get and add of delta on the word located at the address this.rawValue + offset. Like j.u.c.atomic.getAndAdd, it would return the original word value at that address. >>> >>> A couple of questions: >>> >>> * Is the following a legal body for such a method? I see that it >>> compiles but is it legal to call toObject() on a Word value? As used >>> in the snippet the Word value would be the pointer returned by >>> thread(). I noticed there is no unsafe.getAndAddLong(long address, >>> long delta), only unsafe.getAndAddLong(Object o, long offset, long >>> delta) >>> >>> return box(unsafe.getAndAddLong(toObject(), offset, >>> delta)); >>> >>> * I notice all the Word methods have @Operation annotations but I don't really understand the semantics of this annotation. What should be the annotation for this method? >>> >>> >>> * What is the purpose of the locationIdentity parameter on some >>> of the word operations such as >>> >>> @Operation(opcode = Opcode.READ) >>> public Word readWord(WordBase offset, LocationIdentity locationIdentity) { >>> return box(unsafe.getAddress(add((Word) offset).unbox())); >>> } >>> >>> -- Tom >>> >> >> > > > From tom.deneau at amd.com Fri Oct 11 09:19:25 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 11 Oct 2013 16:19:25 +0000 Subject: questions on Word operations In-Reply-To: <525821A5.3000204@oracle.com> References: <52334909.70403@oracle.com> <5234F15D.3050808@oracle.com> <525821A5.3000204@oracle.com> Message-ID: Christian -- OK, I can try this suggestion... On a similar topic, I believe the AtomicGetAndAddNode should implement MemoryCheckPoint.Single (like CompareAndSwapNode does) and perhaps like CompareAndSwapNode getLocationIdentity() should return LocationIdentity.ANY_LOCATION?? But for the LoweredAtomicGetAndAddNode, should it still extend AccessNode? AccessNode requires an object and location and in my case a Word base + offset as the address instead of an object + offset. Is there a means for handling this? -- Tom -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Christian Wimmer Sent: Friday, October 11, 2013 11:05 AM To: graal-dev at openjdk.java.net Subject: Re: questions on Word operations You can define the @NodeIntrinsic in another class, e.g., the class where you want to call it (and there you have per definition the Word class available). @NodeIntrinsic has a parameter that specifies the Node class that it is creating, so you can write @NodeIntrinsics(AtomicGetAndAddNode.class) public static native void atomicGetAndAdd(Word param, ...) I'm not sure if the return type of your method is Word, but if it is, you also have to be careful with the stamp that the node gets: it needs to be the correct wordKind (Kind.Int or Kind.Long). Use the property setStampFromReturnType then, i.e, @NodeIntrinsics(value = AtomicGetAndAddNode.class, setStampFromReturnType = true) public static native Word atomicGetAndAdd(Word param, ...) -Christian On 10/11/2013 07:55 AM, Deneau, Tom wrote: > I am working on adding a new AtomicGetAndAddNode as Christian described below. > > One obstacle I am hitting... > I would like to have a @NodeIntrinsic in this AtomicGetAndAddNode class that takes Word parameters. But com.oracle.graal.nodes does not have com.oracle.graal.word as a dependency, and when I add it as a dependency I get a loop. > > What is the best way around this? > > -- Tom > > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net > [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Christian > Wimmer > Sent: Saturday, September 14, 2013 6:30 PM > Cc: graal-dev at openjdk.java.net > Subject: Re: questions on Word operations > > Tom, > > So you want to use a atomicGetAndAdd instruction from a snippet, > similarly to the CompareAndSwap that is already in Graal (because it > is accessible via sun.misc.Unsafe). > > I would say the easiest way is to create a new AtomicGetAndAddNode, > and provide the proper lowering to a new LIR Operation. > > You can access the new node from a snippet via a node intrinsic - a > method annotated with @NodeIntrinsic in the node class. The parameter > list of the node intrinsic corresponds with the constructor parameters > of the node class, and the pre-processing that Graal is doing for the > snippet replaces the call to the node intrinsic method with an actual > node instance. > > -Christian > > > On 9/13/2013 11:30 AM, Deneau, Tom wrote: >> Christian -- >> >> Yes, I should have stated the final goal and maybe there is a better way to do what we want to do... >> >> We want to support object allocation from an HSA GPU. (or at least to get an idea whether it is worth supporting it). >> >> At a high level, there would be a bunch of TLABS available for the gpu to use. >> For the initial prototype these could be the TLABs from actual java >> "donor threads" whose only purpose is to supply their TLAB (the java donor threads wouldn't allocate into their own TLAB). >> >> Since the HSA GPU has the same view of memory as the cpu, we thought >> perhaps we could just use the non-atomic pointer bump snippet that is used with HotspotRuntime. >> We confirmed this works for small numbers of workitems but the high >> parallelism of the gpu means an unreasonably high number of donor threads would be needed for the general case. >> >> So we are now experimenting with multiple GPU workitems sharing a TLAB and allocatin using an atomic pointer bump. >> We know the HSAIL code we want to end up with, but I just don't have >> any experience with Graal Snippets and such to make graal emit this HSAIL code (as you can tell from my questions). >> >> But maybe there is an easier way to get graal to emit this allocation code? >> >> -- Tom >> >> >> -----Original Message----- >> From: graal-dev-bounces at openjdk.java.net >> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Christian >> Wimmer >> Sent: Friday, September 13, 2013 12:19 PM >> To: graal-dev at openjdk.java.net >> Subject: Re: questions on Word operations >> >> All functions on word types (everything implementing the interface >> WordBase) are compiler intrinsics. If you use Word in a snippet, and call one of the methods on it, the body of these methods is actually irrelevant. The only thing that matters is how the WordTypeRewriterPhase replaces the method call with low-level compiler nodes. The @Operation annotation is used by the WordTypeRewriterPhase to distinguish what to do. >> >> Word only provides the very basic arithmetic and memory operations (+, -, * , /, read, write). Adding methods for atomic operations like you want is possible, but I don't think it is the easiest way to achieve what you want to do. >> >> Can you explain what your final goal is? >> >> -Christian >> >> >> On 09/13/2013 09:47 AM, Deneau, Tom wrote: >>> I would like to add a new Word method that can be used from an allocation Snippet I am trying to write. >>> >>> The new method would look like: >>> >>> public Word atomicGetAndAddWord(int offset, int delta) { >>> >>> } >>> >>> So given a Word (address), this would do an atomic get and add of delta on the word located at the address this.rawValue + offset. Like j.u.c.atomic.getAndAdd, it would return the original word value at that address. >>> >>> A couple of questions: >>> >>> * Is the following a legal body for such a method? I see >>> that it compiles but is it legal to call toObject() on a Word value? >>> As used in the snippet the Word value would be the pointer returned >>> by thread(). I noticed there is no unsafe.getAndAddLong(long >>> address, long delta), only unsafe.getAndAddLong(Object o, long >>> offset, long >>> delta) >>> >>> return box(unsafe.getAndAddLong(toObject(), offset, >>> delta)); >>> >>> * I notice all the Word methods have @Operation annotations but I don't really understand the semantics of this annotation. What should be the annotation for this method? >>> >>> >>> * What is the purpose of the locationIdentity parameter on >>> some of the word operations such as >>> >>> @Operation(opcode = Opcode.READ) >>> public Word readWord(WordBase offset, LocationIdentity locationIdentity) { >>> return box(unsafe.getAddress(add((Word) offset).unbox())); >>> } >>> >>> -- Tom >>> >> >> > > > From christian.wimmer at oracle.com Fri Oct 11 09:26:42 2013 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Fri, 11 Oct 2013 09:26:42 -0700 Subject: questions on Word operations In-Reply-To: References: <52334909.70403@oracle.com> <5234F15D.3050808@oracle.com> <525821A5.3000204@oracle.com> Message-ID: <525826C2.7090802@oracle.com> I am not overly familiar with the memory checkpointing code, so I leave that question for someone more qualified. -Christian On 10/11/2013 09:19 AM, Deneau, Tom wrote: > Christian -- > > OK, I can try this suggestion... > > On a similar topic, I believe the AtomicGetAndAddNode should implement MemoryCheckPoint.Single (like CompareAndSwapNode does) > > and perhaps like CompareAndSwapNode getLocationIdentity() should return LocationIdentity.ANY_LOCATION?? > > But for the LoweredAtomicGetAndAddNode, should it still extend AccessNode? > > AccessNode requires an object and location and in my case a Word base + offset as the address instead of an object + offset. Is there a means for handling this? > > -- Tom > > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Christian Wimmer > Sent: Friday, October 11, 2013 11:05 AM > To: graal-dev at openjdk.java.net > Subject: Re: questions on Word operations > > You can define the @NodeIntrinsic in another class, e.g., the class where you want to call it (and there you have per definition the Word class available). > > @NodeIntrinsic has a parameter that specifies the Node class that it is creating, so you can write > > @NodeIntrinsics(AtomicGetAndAddNode.class) > public static native void atomicGetAndAdd(Word param, ...) > > I'm not sure if the return type of your method is Word, but if it is, you also have to be careful with the stamp that the node gets: it needs to be the correct wordKind (Kind.Int or Kind.Long). Use the property setStampFromReturnType then, i.e, > > @NodeIntrinsics(value = AtomicGetAndAddNode.class, setStampFromReturnType = true) public static native Word atomicGetAndAdd(Word param, ...) > > -Christian > > > > On 10/11/2013 07:55 AM, Deneau, Tom wrote: >> I am working on adding a new AtomicGetAndAddNode as Christian described below. >> >> One obstacle I am hitting... >> I would like to have a @NodeIntrinsic in this AtomicGetAndAddNode class that takes Word parameters. But com.oracle.graal.nodes does not have com.oracle.graal.word as a dependency, and when I add it as a dependency I get a loop. >> >> What is the best way around this? >> >> -- Tom >> >> >> -----Original Message----- >> From: graal-dev-bounces at openjdk.java.net >> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Christian >> Wimmer >> Sent: Saturday, September 14, 2013 6:30 PM >> Cc: graal-dev at openjdk.java.net >> Subject: Re: questions on Word operations >> >> Tom, >> >> So you want to use a atomicGetAndAdd instruction from a snippet, >> similarly to the CompareAndSwap that is already in Graal (because it >> is accessible via sun.misc.Unsafe). >> >> I would say the easiest way is to create a new AtomicGetAndAddNode, >> and provide the proper lowering to a new LIR Operation. >> >> You can access the new node from a snippet via a node intrinsic - a >> method annotated with @NodeIntrinsic in the node class. The parameter >> list of the node intrinsic corresponds with the constructor parameters >> of the node class, and the pre-processing that Graal is doing for the >> snippet replaces the call to the node intrinsic method with an actual >> node instance. >> >> -Christian >> >> >> On 9/13/2013 11:30 AM, Deneau, Tom wrote: >>> Christian -- >>> >>> Yes, I should have stated the final goal and maybe there is a better way to do what we want to do... >>> >>> We want to support object allocation from an HSA GPU. (or at least to get an idea whether it is worth supporting it). >>> >>> At a high level, there would be a bunch of TLABS available for the gpu to use. >>> For the initial prototype these could be the TLABs from actual java >>> "donor threads" whose only purpose is to supply their TLAB (the java donor threads wouldn't allocate into their own TLAB). >>> >>> Since the HSA GPU has the same view of memory as the cpu, we thought >>> perhaps we could just use the non-atomic pointer bump snippet that is used with HotspotRuntime. >>> We confirmed this works for small numbers of workitems but the high >>> parallelism of the gpu means an unreasonably high number of donor threads would be needed for the general case. >>> >>> So we are now experimenting with multiple GPU workitems sharing a TLAB and allocatin using an atomic pointer bump. >>> We know the HSAIL code we want to end up with, but I just don't have >>> any experience with Graal Snippets and such to make graal emit this HSAIL code (as you can tell from my questions). >>> >>> But maybe there is an easier way to get graal to emit this allocation code? >>> >>> -- Tom >>> >>> >>> -----Original Message----- >>> From: graal-dev-bounces at openjdk.java.net >>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Christian >>> Wimmer >>> Sent: Friday, September 13, 2013 12:19 PM >>> To: graal-dev at openjdk.java.net >>> Subject: Re: questions on Word operations >>> >>> All functions on word types (everything implementing the interface >>> WordBase) are compiler intrinsics. If you use Word in a snippet, and call one of the methods on it, the body of these methods is actually irrelevant. The only thing that matters is how the WordTypeRewriterPhase replaces the method call with low-level compiler nodes. The @Operation annotation is used by the WordTypeRewriterPhase to distinguish what to do. >>> >>> Word only provides the very basic arithmetic and memory operations (+, -, * , /, read, write). Adding methods for atomic operations like you want is possible, but I don't think it is the easiest way to achieve what you want to do. >>> >>> Can you explain what your final goal is? >>> >>> -Christian >>> >>> >>> On 09/13/2013 09:47 AM, Deneau, Tom wrote: >>>> I would like to add a new Word method that can be used from an allocation Snippet I am trying to write. >>>> >>>> The new method would look like: >>>> >>>> public Word atomicGetAndAddWord(int offset, int delta) { >>>> >>>> } >>>> >>>> So given a Word (address), this would do an atomic get and add of delta on the word located at the address this.rawValue + offset. Like j.u.c.atomic.getAndAdd, it would return the original word value at that address. >>>> >>>> A couple of questions: >>>> >>>> * Is the following a legal body for such a method? I see >>>> that it compiles but is it legal to call toObject() on a Word value? >>>> As used in the snippet the Word value would be the pointer returned >>>> by thread(). I noticed there is no unsafe.getAndAddLong(long >>>> address, long delta), only unsafe.getAndAddLong(Object o, long >>>> offset, long >>>> delta) >>>> >>>> return box(unsafe.getAndAddLong(toObject(), offset, >>>> delta)); >>>> >>>> * I notice all the Word methods have @Operation annotations but I don't really understand the semantics of this annotation. What should be the annotation for this method? >>>> >>>> >>>> * What is the purpose of the locationIdentity parameter on >>>> some of the word operations such as >>>> >>>> @Operation(opcode = Opcode.READ) >>>> public Word readWord(WordBase offset, LocationIdentity locationIdentity) { >>>> return box(unsafe.getAddress(add((Word) offset).unbox())); >>>> } >>>> >>>> -- Tom >>>> >>> >>> >> >> >> > > From Stefan.Marr at vub.ac.be Fri Oct 11 09:31:55 2013 From: Stefan.Marr at vub.ac.be (Stefan Marr) Date: Fri, 11 Oct 2013 18:31:55 +0200 Subject: Issue with a "Deoptimize not in a block", and method invalidation/re-optimization Message-ID: <5EA31EAC-E8E7-42D0-9F08-79FE9BA3ED8E@vub.ac.be> Hi: I spent some time on 'trufflizing' TruffleSOM, i.e., I tried to use the Truffle-DSL to a larger extend and I tried to avoid manually evaluating nodes were the DSL should be able to do the work. However, I am now running into issues with Graal, which I haven't been able to track down. The first issue is the following exception: "SchedulingError: 25893|Deoptimize should already have been placed in a block". Looking at the graph of nodes and the stack in the debugger does unfortunately not help me with figuring out where that Deoptimize is coming from. The reason of the Deopt was set to something like "Null Check Exception", if I remember correctly. How could I go about to figure out where that's coming from? Another issues is with a specific benchmark [2]. Here I have methods that get constantly invalidated and optimized again. Any tips on how to trace these issues down would be greatly appreciate. Thanks a lot Stefan The code is available via: git clone --recursive https://github.com/smarr/TruffleSOM.git cd TruffleSOM ant tests [1] ./mx.sh --vm server vm -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/All.som [2] ./mx.sh --vm server vm -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/List.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 thomas.wuerthinger at oracle.com Fri Oct 11 20:16:53 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Sat, 12 Oct 2013 05:16:53 +0200 Subject: Issue with a "Deoptimize not in a block", and method invalidation/re-optimization In-Reply-To: <5EA31EAC-E8E7-42D0-9F08-79FE9BA3ED8E@vub.ac.be> References: <5EA31EAC-E8E7-42D0-9F08-79FE9BA3ED8E@vub.ac.be> Message-ID: Thanks for providing the test cases. We will look into the two issues. Independent of the issues: The node number "25893" seems to indicate that you should consider reducing the graph size by putting the @SlowPath annotation on methods that should not to be on the fast path. - thomas On Oct 11, 2013, at 6:31 PM, Stefan Marr wrote: > Hi: > > I spent some time on 'trufflizing' TruffleSOM, i.e., I tried to use the Truffle-DSL to a larger extend and I tried to avoid manually evaluating nodes were the DSL should be able to do the work. > > However, I am now running into issues with Graal, which I haven't been able to track down. > > The first issue is the following exception: "SchedulingError: 25893|Deoptimize should already have been placed in a block". > Looking at the graph of nodes and the stack in the debugger does unfortunately not help me with figuring out where that Deoptimize is coming from. The reason of the Deopt was set to something like "Null Check Exception", if I remember correctly. > > How could I go about to figure out where that's coming from? > > Another issues is with a specific benchmark [2]. Here I have methods that get constantly invalidated and optimized again. > Any tips on how to trace these issues down would be greatly appreciate. > > Thanks a lot > Stefan > > > > The code is available via: > git clone --recursive https://github.com/smarr/TruffleSOM.git > cd TruffleSOM > ant tests > > > [1] ./mx.sh --vm server vm -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/All.som > > [2] ./mx.sh --vm server vm -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/List.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 thomas.wuerthinger at oracle.com Fri Oct 11 20:22:40 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Sat, 12 Oct 2013 05:22:40 +0200 Subject: Integer specialisation of BitScanForwardNode In-Reply-To: References: Message-ID: <1763118C-040C-4947-A093-6986773D0162@oracle.com> Yes, absolutely. Could you create a patch for this? Thanks, thomas On Oct 11, 2013, at 4:51 PM, D.Sturm wrote: > BitScanForwardNode only has a single @NodeIntrinsic method that takes a > long. As a consequence when computing it for an int we first sign-extend it > to a long, e.g.: > > cmp edx,0x0 > je 0x11 > movsxd rax,edx > bsf rax,rax > > > Could we introduce a new method taking an int to avoid this? From D.Sturm42 at gmail.com Sat Oct 12 04:41:33 2013 From: D.Sturm42 at gmail.com (D.Sturm) Date: Sat, 12 Oct 2013 13:41:33 +0200 Subject: Integer specialisation of BitScanForwardNode In-Reply-To: <1763118C-040C-4947-A093-6986773D0162@oracle.com> References: <1763118C-040C-4947-A093-6986773D0162@oracle.com> Message-ID: Sure. Before patch for a Integer.numberOfTrailingZeros() invocation: cmp edx,0x0 je 0x11 movsxd rax,edx bsf rax,rax after: cmp edx,0x0 je 0xe bsf rax,rdx Note that it doesn't matter that we still use the 64bit instruction since at least one bit in the first 32bit will be nonzero, due to the check for 0 before. -Daniel On 12 October 2013 05:22, Thomas Wuerthinger wrote: > Yes, absolutely. Could you create a patch for this? > > Thanks, thomas > > On Oct 11, 2013, at 4:51 PM, D.Sturm wrote: > > > BitScanForwardNode only has a single @NodeIntrinsic method that takes a > > long. As a consequence when computing it for an int we first sign-extend > it > > to a long, e.g.: > > > > cmp edx,0x0 > > je 0x11 > > movsxd rax,edx > > bsf rax,rax > > > > > > Could we introduce a new method taking an int to avoid this? > > From doug.simon at oracle.com Sat Oct 12 18:00:49 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 13 Oct 2013 01:00:49 +0000 Subject: hg: graal/graal: 483 new changesets Message-ID: <20131013012011.54E4862FDF@hg.openjdk.java.net> Changeset: 992508ee13b6 Author: Thomas Wuerthinger Date: 2013-10-05 15:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/992508ee13b6 Adjustment to unsafe customization macro node. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/UnsafeCustomizationMacroNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/CompilerDirectivesSubstitutions.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerDirectives.java Changeset: f753092f608d Author: Thomas Wuerthinger Date: 2013-10-06 15:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f753092f608d Adjustments to unsafe access and unsafe cast compiler directives in Truffle API. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/FrameWithoutBoxing.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomTypeCheckMacroNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomTypeCheckNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomizedUnsafeLoadNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomizedUnsafeStoreNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/TypeCastMacroNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/TypeCastNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/UnsafeCustomizationMacroNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/UnsafeCustomizationNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/UnsafeTypeCastMacroNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/UnsafeTypeCastNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/CompilerDirectivesSubstitutions.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerDirectives.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/Frame.java Changeset: 1ec42a9f6149 Author: Thomas Wuerthinger Date: 2013-10-06 15:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1ec42a9f6149 Merge. Changeset: 1f82cda83ced Author: Morris Meyer Date: 2013-10-06 13:55 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/1f82cda83ced PTX conditional move, switch, if-else ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ControlPTXTest.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXBackend.java ! 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/PTXControlFlow.java Changeset: 61767ccd4600 Author: Morris Meyer Date: 2013-10-06 18:15 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/61767ccd4600 PTX boolean return value, emitIntegerTestMove, warnings ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ControlPTXTest.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXBackend.java ! 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/PTXControlFlow.java + graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXTestOp.java ! src/gpu/ptx/vm/gpu_ptx.cpp ! src/gpu/ptx/vm/ptxKernelArguments.cpp ! src/gpu/ptx/vm/ptxKernelArguments.hpp Changeset: 67a1e27a8dbb Author: Morris Meyer Date: 2013-10-06 22:07 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/67a1e27a8dbb PTX initial float and double ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/FloatPTXTest.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXBackend.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXTargetMethodAssembler.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotRegisterConfig.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXMemOp.java ! src/gpu/ptx/vm/gpu_ptx.cpp ! src/gpu/ptx/vm/ptxKernelArguments.cpp ! src/gpu/ptx/vm/ptxKernelArguments.hpp ! src/share/vm/graal/graalCompilerToGPU.cpp Changeset: df1d665ca846 Author: Michael Van De Vanter Date: 2013-10-06 19:53 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/df1d665ca846 Truffle; remove uses of Node() constructor in test code ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/nodes/AbstractTestNode.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/nodes/RootTestNode.java ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/TypeSystemTest.java ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/ArgumentsTest.java ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/CallTest.java ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/ChildNodeTest.java ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/ChildrenNodesTest.java ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/FinalFieldTest.java ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/FrameSlotTypeSpecializationTest.java ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/FrameTest.java ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/ReplaceTest.java ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/ReturnTypeSpecializationTest.java ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/RootNodeTest.java Changeset: ee8df8ae68c1 Author: Michael Van De Vanter Date: 2013-10-06 19:54 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ee8df8ae68c1 SL: update node constructors to use the Node(SourceSection) constructor ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLNode.java Changeset: b563d9cb084f Author: Michael Van De Vanter Date: 2013-10-06 19:57 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b563d9cb084f Truffle: clean out one more use of the RootNode() constructor in test code ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/TypeSystemTest.java Changeset: 82ec5f898e6c Author: Michael Van De Vanter Date: 2013-10-06 19:58 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/82ec5f898e6c SL: remove use of RootNode() constructor ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/FunctionDefinitionNode.java Changeset: 873da100d113 Author: Michael Van De Vanter Date: 2013-10-06 21:17 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/873da100d113 Truffle: another minor tweak to NodeUtil.printSourceAttributionTree ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: cf4dd10ced32 Author: Michael Van De Vanter Date: 2013-10-06 21:19 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/cf4dd10ced32 Merge with 67a1e27a8dbb0945dc974b3ee3d8ac8af04743d3 Changeset: fd94583ddee5 Author: Doug Simon Date: 2013-10-06 23:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fd94583ddee5 removed the IterableNodeType marker interface from LoadFieldNode (GRAAL-471) ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/IterativeInliningTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadFieldNode.java Changeset: c90f80ac6c15 Author: Doug Simon Date: 2013-10-06 23:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c90f80ac6c15 removed unused class - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/phases/ReplaceLoadFinalPhase.java Changeset: 802661ff07d2 Author: Doug Simon Date: 2013-10-06 23:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/802661ff07d2 removed the IterableNodeType marker interface from LoadIndexedNode (GRAAL-471) ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadIndexedNode.java Changeset: 5945c652dc43 Author: Doug Simon Date: 2013-10-06 23:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5945c652dc43 removed the IterableNodeType marker interface from LogicNegationNode (GRAAL-471) ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicNegationNode.java Changeset: 0a2bda4e3fa3 Author: Doug Simon Date: 2013-10-06 23:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0a2bda4e3fa3 removed the IterableNodeType marker interface from MaterializedObjectState (GRAAL-471) ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/nodes/MaterializedObjectState.java Changeset: eef7ded2b633 Author: Doug Simon Date: 2013-10-06 23:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/eef7ded2b633 removed the IterableNodeType marker interface from WriteBarrier (GRAAL-471); typed iteration is only used in tests ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrier.java Changeset: 56a11c0d689b Author: Doug Simon Date: 2013-10-06 23:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/56a11c0d689b removed the IterableNodeType marker interface from ValueAnchorNode (GRAAL-471) ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ValueAnchorNode.java Changeset: 3c1a187c0a41 Author: Doug Simon Date: 2013-10-06 23:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3c1a187c0a41 removed the IterableNodeType marker interface from EscapeObjectState (GRAAL-471) ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/EscapeObjectState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/nodes/VirtualObjectState.java Changeset: 679d485c370b Author: Doug Simon Date: 2013-10-06 23:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/679d485c370b removed unused PhiStampPhase - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/PhiStampPhase.java Changeset: 234aea2460bb Author: Doug Simon Date: 2013-10-06 23:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/234aea2460bb removed the IterableNodeType marker interface from PhiNode (GRAAL-471) ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/PhiCreationTests.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PhiNode.java Changeset: 43bf803203c0 Author: Doug Simon Date: 2013-10-07 11:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/43bf803203c0 Merge. Changeset: b7ce25d81ef3 Author: Doug Simon Date: 2013-10-07 14:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b7ce25d81ef3 fixed WriteBarrier tests ! 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 Changeset: 9c33290e40e6 Author: Thomas Wuerthinger Date: 2013-10-06 16:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9c33290e40e6 Add missing node intrinsic annotation. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomizedUnsafeLoadNode.java Changeset: 09382856ab93 Author: Thomas Wuerthinger Date: 2013-10-06 16:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/09382856ab93 Remove unused import. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomizedUnsafeLoadNode.java Changeset: 88fb9cba8751 Author: Thomas Wuerthinger Date: 2013-10-07 01:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/88fb9cba8751 Simplify handling of unsafe store and unsafe load. ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/BasicPTXTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AESCryptSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CipherBlockChainingSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopySnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeLoadSnippets.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeAccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeLoadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeStoreNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeClassSubstitutions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/UnsafeSubstitutions.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameGetNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomizedUnsafeLoadNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomizedUnsafeStoreNode.java Changeset: ba829878000c Author: Thomas Wuerthinger Date: 2013-10-07 01:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ba829878000c Merge. Changeset: fe71a5ed24c2 Author: Thomas Wuerthinger Date: 2013-10-07 01:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fe71a5ed24c2 Add object location identity class. + graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ObjectLocationIdentity.java Changeset: e04a86167368 Author: Thomas Wuerthinger Date: 2013-10-07 02:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e04a86167368 Add support for unsafe access in early read elimination. ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ObjectLocationIdentity.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaField.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomizedUnsafeLoadMacroNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomizedUnsafeLoadNode.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomizedUnsafeStoreMacroNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomizedUnsafeStoreNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/CompilerDirectivesSubstitutions.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationBlockState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationClosure.java Changeset: 776e348d6c2e Author: Thomas Wuerthinger Date: 2013-10-07 03:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/776e348d6c2e Propagate state after when creating unsafe store node. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomizedUnsafeStoreMacroNode.java Changeset: 10755fbf8df8 Author: Thomas Wuerthinger Date: 2013-10-07 03:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/10755fbf8df8 Fix warnings in PTX code. ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ControlPTXTest.java ! 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/PTXControlFlow.java Changeset: b18d4089535d Author: Thomas Wuerthinger Date: 2013-10-07 03:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b18d4089535d Merge. ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ControlPTXTest.java ! 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/PTXControlFlow.java Changeset: 47a5e23bb418 Author: Thomas Wuerthinger Date: 2013-10-07 03:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/47a5e23bb418 Fix more PTX warnings. ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXTestOp.java Changeset: 9fe53a7b42b8 Author: Thomas Wuerthinger Date: 2013-10-07 09:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9fe53a7b42b8 Merge. ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java Changeset: 66909d055314 Author: Thomas Wuerthinger Date: 2013-10-07 23:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/66909d055314 Fix unsafe load snippet. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeLoadSnippets.java Changeset: 60bf1372d1a0 Author: Thomas Wuerthinger Date: 2013-10-07 23:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/60bf1372d1a0 Merge. ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/PhiStampPhase.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/phases/ReplaceLoadFinalPhase.java Changeset: dca16d6f9d65 Author: Chris Seaton Date: 2013-10-08 00:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/dca16d6f9d65 TruffleRuntime.createVirtualFrame. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TruffleRuntime.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultTruffleRuntime.java Changeset: 12e9d529fd1d Author: Doug Simon Date: 2013-10-08 13:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/12e9d529fd1d suggest corrections for mistyped Graal options (GRAAL-521) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java Changeset: 4cdf7623fbe6 Author: Doug Simon Date: 2013-10-08 15:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4cdf7623fbe6 ensure graal.options in the JDK is deployed/updated/deleted each time the VM is run ! mx/commands.py Changeset: 12e119095ac8 Author: Thomas Wuerthinger Date: 2013-10-08 00:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/12e119095ac8 Fix warnings in PTX code. ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/FloatPTXTest.java Changeset: bdfdd110bd9a Author: Thomas Wuerthinger Date: 2013-10-08 00:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bdfdd110bd9a Introduce ConditionAnchorNode. + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConditionAnchorNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/UnsafeTypeCastMacroNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/UnsafeTypeCastNode.java Changeset: dfaac94659aa Author: Thomas Wuerthinger Date: 2013-10-08 21:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dfaac94659aa Merge. Changeset: 87402d9a67ca Author: Doug Simon Date: 2013-10-09 16:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/87402d9a67ca spelling fix ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java Changeset: df9d338b0764 Author: Bernhard Urban Date: 2013-10-09 16:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/df9d338b0764 StandardMethodSubstitutionsTest: reenable tests again ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/StandardMethodSubstitutionsTest.java Changeset: e8a70ba77439 Author: Thomas Wuerthinger Date: 2013-10-08 23:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e8a70ba77439 Only allow virtualization of PiNode if type matches. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java Changeset: 0fa39f034839 Author: Thomas Wuerthinger Date: 2013-10-08 23:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0fa39f034839 Allow floating unsafe loads. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConditionAnchorNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeLoadNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomizedUnsafeLoadMacroNode.java Changeset: 506d4520435d Author: Thomas Wuerthinger Date: 2013-10-09 17:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/506d4520435d Do not emit code for constants in virtual state. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConstantNode.java Changeset: 1fee8d3e99f6 Author: Thomas Wuerthinger Date: 2013-10-09 17:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1fee8d3e99f6 Merge. Changeset: ca8bf227323c Author: Thomas Wuerthinger Date: 2013-10-09 17:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ca8bf227323c Merge. Changeset: 47cd2df21903 Author: Andreas Woess Date: 2013-10-09 17:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/47cd2df21903 Fix DeoptimizeNode @NodeInfo. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractDeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizeNode.java Changeset: c52e4ba95306 Author: Andreas Woess Date: 2013-10-09 19:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c52e4ba95306 fix typo ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PEReadEliminationClosure.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java Changeset: f2fbdf89a1a5 Author: Andreas Woess Date: 2013-10-09 20:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f2fbdf89a1a5 Remove obsolete TruffleCompilerOptions. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java Changeset: be0a33a631fa Author: Andreas Woess Date: 2013-10-09 22:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/be0a33a631fa Truffle: fix node rewrite issue that can occur when a currently executing node is replaced in a recursive call. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: c0c616fe3588 Author: Andreas Woess Date: 2013-10-10 03:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c0c616fe3588 Back out changeset be0a33a631fa. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java Changeset: c0807f5fdca5 Author: Doug Simon Date: 2013-10-10 11:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c0807f5fdca5 added ResolvedJavaType.getClassInititalizer() ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaType.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 Changeset: f9f18098479e Author: Doug Simon Date: 2013-10-10 11:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f9f18098479e added tests for ResolvedJavaType.getClassInitializer() and ResolvedJavaType.getDeclaredMethods() ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaType.java Changeset: 905c26108117 Author: Doug Simon Date: 2013-10-10 12:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/905c26108117 removed warning ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConstantNode.java Changeset: 8bc017616cb7 Author: Doug Simon Date: 2013-10-10 12:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8bc017616cb7 made verification of Option declaring classes runtime independent ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/VerifyHotSpotOptionsPhase.java + graal/com.oracle.graal.java/src/com/oracle/graal/java/VerifyOptionsPhase.java Changeset: 8a6d0cd7971b Author: Bernhard Urban Date: 2013-10-10 13:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8a6d0cd7971b Label: allocate ArrayList lazily ! graal/com.oracle.graal.asm/src/com/oracle/graal/asm/Label.java Changeset: ee3b959c81b8 Author: Gilles Duboscq Date: 2013-10-10 12:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ee3b959c81b8 Ignore agent build files ! .hgignore Changeset: a0f5be106e67 Author: Gilles Duboscq Date: 2013-10-10 13:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a0f5be106e67 Simplify ConstantNode.onlyUsedInVirtualState ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConstantNode.java Changeset: 23ccaa863eda Author: Doug Simon Date: 2013-10-10 16:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/23ccaa863eda made CodeCacheProvider independent of MetaAccessProvider (GRAAL-511) ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CodeCacheProvider.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/DelegatingCodeCacheProvider.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/TestJavaMethod.java ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestJavaType.java ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestMetaAccessProvider.java ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaMethod.java ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaType.java ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TypeUniverse.java ! graal/com.oracle.graal.asm.test/src/com/oracle/graal/asm/test/AssemblerTest.java ! 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/HSAILBackend.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILCompilationResult.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! 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/PTXBackend.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXTargetMethodAssembler.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/BoxingEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/CompareCanonicalizerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionalEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/DegeneratedLoopsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/EliminateNestedCheckCastsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FinalizableSubclassTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FloatingReadTest.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/IfCanonicalizerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InfopointReasonTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InvokeExceptionTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InvokeHintsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/LockEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/LoopUnswitchTest.java ! 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/MonitorGraphTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ProfilingInfoTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/PushNodesThroughPiTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ReadAfterCheckCastTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ReassociateAndCanonicalTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ScalarTypeSystemTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/StampCanonicalizerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/StraighteningTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/TypeSystemTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/backend/AllocatorTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/deopt/CompiledMethodTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/deopt/SynchronizedMethodDeoptimizationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EarlyReadEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EscapeAnalysisTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/IterativeInliningTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PartialEscapeAnalysisTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/inlining/InliningTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/Backend.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/spi/CanonicalizerTool.java ! graal/com.oracle.graal.hotspot.amd64.test/src/com/oracle/graal/hotspot/amd64/test/AMD64HotSpotFrameOmissionTest.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/AMD64HotSpotDeoptimizeCallerOp.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/AMD64HotSpotMove.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotUnwindOp.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/SPARCHotSpotDeoptimizeCallerOp.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/SPARCHotSpotUnwindOp.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/ArrayCopyIntrinsificationTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotCryptoSubstitutionTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotNmethodTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/InstalledCodeExecuteHelperTest.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/HotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReplacementsImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassGetComponentTypeNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassGetSuperclassNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorExitStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewInstanceStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewMultiArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/StubForeignCallNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VMErrorNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/LoadJavaMirrorWithKlassPhase.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CallSiteSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CallSiteTargetNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CheckCastDynamicSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/InstanceOfSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/LoadExceptionObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneNode.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/ReflectionGetCallerClassNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/TypeCheckSnippetUtils.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopySnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeLoadSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/SnippetStub.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/Test.java ! graal/com.oracle.graal.java.decompiler.test/src/com/oracle/graal/java/decompiler/test/TestUtil.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/VerifyOptionsPhase.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/JTTTest.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/AMD64FrameMap.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILFrameMap.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/PTXFrameMap.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXMove.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/SPARCFrameMap.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/FrameMap.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/TargetMethodAssembler.java ! graal/com.oracle.graal.nodes.test/src/com/oracle/graal/nodes/test/ObjectStampJoinTest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractDeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConstantNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DynamicDeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/CompareNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/Condition.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConvertNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerRemNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedRemNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/debug/DynamicCounterNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/BoxNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadHubNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadMethodNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/OSRStartNode.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/StoreHubNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnboxNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeLoadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeStoreNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AbstractNewArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AccessFieldNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AccessIndexedNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ArrayLengthNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastDynamicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CompareAndSwapNode.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/ExceptionObjectNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfDynamicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadExceptionObjectNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadFieldNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MonitorEnterNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MonitorExitNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewInstanceNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewMultiArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/RegisterFinalizerNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/TypeSwitchNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LIRGeneratorTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LoweringTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/ReplacementsProvider.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampFactory.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/CommitAllocationNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/DeoptimizationGroupingPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.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/IterativeConditionalEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/HighTierContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/LowTierContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/MidTierContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/PhaseContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyUsageWithEquals.java ! graal/com.oracle.graal.replacements.amd64/src/com/oracle/graal/replacements/amd64/AMD64ConvertSnippets.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/MethodSubstitutionTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/NewMultiArrayTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/ObjectAccessTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/PointerTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/TypeCheckTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/WordTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/BoxingSnippets.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/GraalMethodSubstitutions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/InstanceOfSnippetsTemplates.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.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 ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/PureFunctionMacroNode.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.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 ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleReplacements.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/LoadIndexedFinalNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameGetNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameSetNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/UnsafeTypeCastMacroNode.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapePhase.java Changeset: 7c9885d23744 Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7c9885d23744 Added tag jdk8-b101 for changeset f6921c876db1 ! .hgtags Changeset: e84845884c85 Author: amurillo Date: 2013-07-26 04:01 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e84845884c85 8021566: new hotspot build - hs25-b44 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d90d1b96b65b Author: kvn Date: 2013-07-26 12:37 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d90d1b96b65b 8008938: TieredCompilation should be default Summary: switch on TieredCompilation by default Reviewed-by: twisti ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp Changeset: 1b6395189726 Author: minqi Date: 2013-07-19 14:43 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1b6395189726 8012263: ciReplay: gracefully exit & report meaningful error when replay data parsing fails Summary: find_method could return NULL so need explicitly check if there is error after parse_method, exit on error to avoid crash. Reviewed-by: kvn, twisti Contributed-by: yumin.qi at oracle.com ! src/share/vm/ci/ciReplay.cpp Changeset: 5ad7f8179bf7 Author: minqi Date: 2013-07-24 08:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5ad7f8179bf7 Merge Changeset: b6baf306e698 Author: fparain Date: 2013-07-26 05:54 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b6baf306e698 Merge Changeset: 83ca9dc4564d Author: fparain Date: 2013-07-26 15:24 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/83ca9dc4564d 8019845: Memory leak during class redefinition Reviewed-by: acorn, jmasa, coleenp, dcubed, mgerdin ! src/share/vm/memory/metaspace.cpp Changeset: f9ee986a9fea Author: ccheung Date: 2013-07-30 14:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f9ee986a9fea 8021296: [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases Summary: Added checking for gcc and simplified the sig_handler() in the test case Reviewed-by: dcubed, coleenp, minqi, dlong ! test/runtime/6929067/Test6929067.sh ! test/runtime/7107135/Test7107135.sh ! test/runtime/jsig/Test8017498.sh ! test/runtime/jsig/TestJNI.c Changeset: 0f98cc013b21 Author: fparain Date: 2013-07-31 08:28 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0f98cc013b21 Merge Changeset: c65045599519 Author: dholmes Date: 2013-07-25 21:05 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/c65045599519 8021314: minimal1.make needs to force off components not supported by the minimal VM Reviewed-by: coleenp, bpittore ! make/bsd/makefiles/minimal1.make ! make/linux/makefiles/minimal1.make Changeset: 078e5eb2e52e Author: clucasius Date: 2013-07-27 17:23 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/078e5eb2e52e Merge Changeset: da839a3c5735 Author: dholmes Date: 2013-07-31 19:05 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/da839a3c5735 Merge Changeset: e3c8767c5cf8 Author: tschatzl Date: 2013-07-24 10:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e3c8767c5cf8 8020123: Test gc/g1/TestPrintRegionRememberedSetInfo.java fails with "test result: Error. No action after @build" Summary: Remove the @build tag and replace it by a @run tag so that the test gets executed Reviewed-by: brutisso, mgerdin ! test/gc/g1/TestPrintRegionRememberedSetInfo.java Changeset: 7b06ae405d7b Author: jmasa Date: 2013-07-23 09:49 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7b06ae405d7b 6990419: CMS Remaining work for 6572569: consistently skewed work distribution in (long) re-mark pauses Reviewed-by: rasbold, tschatzl, jmasa Contributed-by: yamauchi at google.com ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/runtime/globals.hpp Changeset: fb7010c7c011 Author: jmasa Date: 2013-07-25 07:02 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/fb7010c7c011 Merge Changeset: ca9dedeebdec Author: jmasa Date: 2013-07-25 11:07 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ca9dedeebdec 6412968: CMS Long initial mark pauses Reviewed-by: rasbold, tschatzl, jmasa Contributed-by: yamauchi at google.com ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/runtime/globals.hpp Changeset: 8796fd3ac898 Author: tamao Date: 2013-07-26 13:34 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8796fd3ac898 Merge ! src/share/vm/runtime/globals.hpp Changeset: 313227279a05 Author: brutisso Date: 2013-08-01 07:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/313227279a05 8021967: Deprecate -XX:DefaultMaxRAMFraction Reviewed-by: tschatzl, jmasa, kvn, tamao ! src/share/vm/runtime/arguments.cpp + test/gc/startup_warnings/TestDefaultMaxRAMFraction.java Changeset: dae8324fc7d1 Author: brutisso Date: 2013-08-01 09:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dae8324fc7d1 8021879: G1: G1HeapRegionSize flag value not updated correctly Reviewed-by: tschatzl, jmasa ! src/share/vm/gc_implementation/g1/heapRegion.cpp + test/gc/arguments/TestG1HeapRegionSize.java Changeset: 8d4ff57af591 Author: brutisso Date: 2013-08-01 17:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8d4ff57af591 8022051: G1: Remove some unused G1 flags Reviewed-by: tschatzl, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 69d0dbb53c78 Author: tamao Date: 2013-08-01 17:17 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/69d0dbb53c78 Merge Changeset: 530fe88b3b2c Author: amurillo Date: 2013-08-02 02:54 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/530fe88b3b2c Merge Changeset: c4697c1c4484 Author: amurillo Date: 2013-08-02 02:54 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c4697c1c4484 Added tag hs25-b44 for changeset 530fe88b3b2c ! .hgtags Changeset: b9a927798f12 Author: cl Date: 2013-08-08 10:10 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b9a927798f12 Added tag jdk8-b102 for changeset c4697c1c4484 ! .hgtags Changeset: 79ce055063e9 Author: amurillo Date: 2013-08-02 03:06 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/79ce055063e9 8022124: new hotspot build - hs25-b45 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 9bd314787fad Author: mseledtsov Date: 2013-08-01 22:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9bd314787fad 8020614: OutputAnalyzer.shouldHaveExitValue() should print stdout/stderr output Summary: OutputAnalyzer.shouldHaveExitValue() should print stdout/stderr output Reviewed-by: kvn, ctornqvi, dholmes + test/testlibrary/OutputAnalyzerReportingTest.java ! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java ! test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java Changeset: c01913206da5 Author: ctornqvi Date: 2013-08-01 22:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c01913206da5 8014294: Assert in ThreadTimesClosure::do_thread() due to use of naked oop instead of handle Summary: Assert in ThreadTimesClosure::do_thread() due to use of naked oop instead of handle Reviewed-by: coleenp, sspitsyn ! src/share/vm/services/management.cpp Changeset: 81e0f17ade64 Author: ctornqvi Date: 2013-08-01 22:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/81e0f17ade64 8009407: runtime/8000968/Test8000968.sh has incorrect check for proper config Summary: runtime/8000968/Test8000968.sh has incorrect check for proper config Reviewed-by: coleenp, mseledtsov, sspitsyn, hseigel - test/runtime/8000968/Test8000968.sh + test/runtime/CompressedOops/CompressedKlassPointerAndOops.java Changeset: 32e3bada0978 Author: kevinw Date: 2013-08-02 12:26 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/32e3bada0978 8020943: Memory leak when GCNotifier uses create_from_platform_dependent_str() Reviewed-by: mgerdin, fparain, dcubed ! src/share/vm/services/gcNotifier.cpp Changeset: dee4c330acd4 Author: dcubed Date: 2013-08-02 08:32 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/dee4c330acd4 Merge - test/runtime/8000968/Test8000968.sh Changeset: fa57c8104b76 Author: ctornqvi Date: 2013-08-02 18:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fa57c8104b76 8009585: test/runtime/7196045 times out Summary: test/runtime/7196045 times out Reviewed-by: dholmes, mseledtsov - test/runtime/7196045/Test7196045.java + test/runtime/InternalApi/ThreadCpuTimesDeadlock.java Changeset: 0f209afdfcf8 Author: ctornqvi Date: 2013-08-02 18:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0f209afdfcf8 Merge Changeset: d02de8cac823 Author: ctornqvi Date: 2013-08-02 22:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d02de8cac823 Merge - test/runtime/7196045/Test7196045.java Changeset: e0379d5ba5d2 Author: kevinw Date: 2013-08-05 10:27 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e0379d5ba5d2 8021444: SA: ClassDump.run() should not ignore existing ClassFilter. Reviewed-by: minqi, poonam ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java Changeset: b67604b59546 Author: hseigel Date: 2013-08-04 16:30 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/b67604b59546 7073961: [TESTBUG] closed/runtime/4845371/DBB.java failed on solaris 10 X65 Summary: Added a x86 64-bit Solaris shared library and rewrote test in Java Reviewed-by: dholmes, ctornqvi ! test/testlibrary/com/oracle/java/testlibrary/Platform.java Changeset: 9064e3a19525 Author: hseigel Date: 2013-08-05 08:55 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9064e3a19525 Merge - test/runtime/7196045/Test7196045.java - test/runtime/8000968/Test8000968.sh Changeset: 22a5aff0df0b Author: dsamersoff Date: 2013-08-06 14:28 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/22a5aff0df0b 8019396: SA-JDI OSThread class initialization throws an exception Summary: Method sun.jvm.hotspot.runtime.OSThread.initialize throws a sun.jvm.hotspot.types.WrongTypeException Reviewed-by: dholmes, mgerdin ! agent/src/share/classes/sun/jvm/hotspot/jdi/JVMTIThreadState.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/OSThread.java Changeset: cd25d3be91c5 Author: vladidan Date: 2013-08-06 20:01 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/cd25d3be91c5 8012144: multiple SIGSEGVs fails on staxf Summary: Forward port of 7u change to add additional fence() on RMO platforms, with a load_acquire on all platforms Reviewed-by: dholmes, kvn ! src/share/vm/utilities/taskqueue.hpp Changeset: f5bed20f2492 Author: dholmes Date: 2013-08-08 08:29 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/f5bed20f2492 Merge Changeset: 79a5283f4595 Author: iignatyev Date: 2013-07-29 11:54 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/79a5283f4595 8021120: TieredCompilation can be enabled even if TIERED is undefined Reviewed-by: kvn, dholmes ! src/share/vm/runtime/arguments.cpp Changeset: 8d77d02828d9 Author: twisti Date: 2013-07-29 16:32 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8d77d02828d9 8016474: Crash in sun.reflect.UnsafeObjectFieldAccessorImpl.get Summary: C1's GetUnsafeObject G1 pre-barrier uses the wrong type to read the klass pointer. Reviewed-by: iveresov, kvn ! src/share/vm/c1/c1_LIRGenerator.cpp + test/compiler/unsafe/GetUnsafeObjectG1PreBarrier.java Changeset: 446cb5d25d03 Author: anoll Date: 2013-08-01 16:01 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/446cb5d25d03 8020531: Test compiler/codecache/CheckUpperLimit.java fails when memory limited Summary: Removed part of the test that required the VM to start up with -XX:ReservedCodeCacheSize=2048m Reviewed-by: kvn, rbackman ! test/compiler/codecache/CheckUpperLimit.java Changeset: 6e04c193845f Author: anoll Date: 2013-08-02 10:20 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6e04c193845f 8021301: better event messages Summary: made event messages better readable Reviewed-by: kvn, rbackman ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/utilities/exceptions.cpp Changeset: 5e0b3d7df485 Author: rbackman Date: 2013-08-05 17:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5e0b3d7df485 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 71526a36ebb4 Author: twisti Date: 2013-08-05 15:03 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/71526a36ebb4 8022029: GetUnsafeObjectG1PreBarrier fails on 32-bit with: Unrecognized VM option 'ObjectAlignmentInBytes=32' Reviewed-by: kvn ! test/compiler/unsafe/GetUnsafeObjectG1PreBarrier.java Changeset: dadf62510ae4 Author: rbackman Date: 2013-08-08 23:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dadf62510ae4 Merge Changeset: 7f55137d6aa8 Author: amurillo Date: 2013-08-09 01:32 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7f55137d6aa8 Merge - test/runtime/7196045/Test7196045.java - test/runtime/8000968/Test8000968.sh Changeset: 6f9be7f87b96 Author: amurillo Date: 2013-08-09 01:32 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6f9be7f87b96 Added tag hs25-b45 for changeset 7f55137d6aa8 ! .hgtags Changeset: 0bbd1c775bef Author: cl Date: 2013-08-15 09:25 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0bbd1c775bef Added tag jdk8-b103 for changeset 6f9be7f87b96 ! .hgtags Changeset: 39127bb12d32 Author: amurillo Date: 2013-08-09 01:39 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/39127bb12d32 8022688: new hotspot build - hs25-b46 Reviewed-by: jcoomes ! make/hotspot_version Changeset: ca0165daa6ec Author: sspitsyn Date: 2013-08-06 16:33 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ca0165daa6ec 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments Summary: Restore the appendix argument after PopFrame() call Reviewed-by: twisti, coleenp Contributed-by: serguei.spitsyn at oracle.com ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp Changeset: c54a3122f9c8 Author: omajid Date: 2013-08-06 12:28 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/c54a3122f9c8 8022188: Make zero compile after 8016131 and 8016697 Reviewed-by: dholmes, twisti ! src/cpu/zero/vm/entryFrame_zero.hpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp Changeset: 196aa14f9f29 Author: dholmes Date: 2013-08-06 21:06 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/196aa14f9f29 Merge Changeset: 195ff07bc7f6 Author: dsamersoff Date: 2013-08-07 19:02 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/195ff07bc7f6 8021771: warning stat64 is deprecated - when building on OSX 10.7.5 Summary: stat64 have to be replaced with stat Reviewed-by: dholmes, kmo Contributed-by: rednaxelafx at gmail.com ! src/os/bsd/vm/attachListener_bsd.cpp Changeset: 31f3b1e1c5e5 Author: dcubed Date: 2013-08-08 09:21 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/31f3b1e1c5e5 8016601: Unable to build hsx24 on Windows using project creator and Visual Studio Summary: ProjectCreator tool is modified to support two new options: '-relativeAltSrcInclude' and '-altRelativeInclude' which prevents IDE linker errors. Also fixed some cmd line build linker warnings. Misc cleanups. Reviewed-by: rdurbin, coleenp ! make/windows/create.bat ! make/windows/create_obj_files.sh ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/trace.make ! make/windows/makefiles/vm.make ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/tools/ProjectCreator/FileTreeCreatorVC10.java ! src/share/tools/ProjectCreator/ProjectCreator.java ! src/share/tools/ProjectCreator/WinGammaPlatform.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java Changeset: c661fa2e5189 Author: iklam Date: 2013-08-08 14:45 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c661fa2e5189 8022093: syntax error near "umpiconninfo_t" -- when building on Solaris 10 Summary: Added extra help message in make/solaris/makefiles/dtrace.make Reviewed-by: dholmes, sspitsyn ! make/solaris/makefiles/dtrace.make Changeset: 57ac7245594c Author: minqi Date: 2013-08-08 15:19 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/57ac7245594c 8019583: [TESTBUG] runtime/7107135 always passes Summary: If java test return none zero, the value will be override by 'if' statement, the exit value will always '0' and pass. Fix by recording the result in a variable. Reviewed-by: coleenp, dholmes, iklam Contributed-by: yumin.qi at oracle.com ! test/runtime/7107135/Test7107135.sh Changeset: 6222a021d582 Author: minqi Date: 2013-08-08 20:13 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6222a021d582 Merge Changeset: 98aa538fd97e Author: mikael Date: 2013-08-09 09:51 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/98aa538fd97e 8022452: Hotspot needs to know about Windows 8.1 and Windows Server 2012 R2 Summary: Add support for recognizing Windows 8.1 and Server 2012 R2 and minor cleanup Reviewed-by: coleenp, dsamersoff ! src/os/windows/vm/os_windows.cpp Changeset: ed7c17e7d45b Author: dcubed Date: 2013-08-09 13:19 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ed7c17e7d45b Merge Changeset: 7b03590c334b Author: dcubed Date: 2013-08-09 15:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7b03590c334b Merge Changeset: bd0e82136b03 Author: iklam Date: 2013-08-10 10:56 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/bd0e82136b03 8022740: Visual 2008 IDE build is broken Summary: Fixed project generation code, and added warning to upgrade to VS 2008 SP1. Reviewed-by: dcubed, ccheung ! make/windows/projectfiles/common/Makefile ! src/share/tools/ProjectCreator/FileTreeCreator.java ! src/share/tools/ProjectCreator/FileTreeCreatorVC10.java ! src/share/tools/ProjectCreator/FileTreeCreatorVC7.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java Changeset: 85147f28faba Author: coleenp Date: 2013-08-12 17:24 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/85147f28faba 8009728: nsk/jvmti/AttachOnDemand/attach030 crashes on Win32 Summary: ActiveMethodOopsCache was used to keep track of old versions of some methods that are cached in Universe but is buggy with permgen removal and not needed anymore Reviewed-by: sspitsyn, dcubed, mseledtsov ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! test/runtime/RedefineObject/Agent.java ! test/runtime/RedefineObject/TestRedefineObject.java + test/runtime/RedefineObject/WalkThroughInvoke.java Changeset: d1034bd8cefc Author: adlertz Date: 2013-08-07 17:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d1034bd8cefc 8022284: Hide internal data structure in PhaseCFG Summary: Hide private node to block mapping using public interface Reviewed-by: kvn, roland ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ce8969c36762 Author: adlertz Date: 2013-08-07 18:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ce8969c36762 8022475: Remove unneeded ad-files Summary: Remove .ad files that are not used Reviewed-by: kvn ! make/bsd/makefiles/adlc.make ! make/linux/makefiles/adlc.make ! make/solaris/makefiles/adlc.make ! make/windows/makefiles/adlc.make - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 5394ec69f112 Author: rbackman Date: 2013-08-09 18:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5394ec69f112 Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 11237ee74aae Author: iignatyev Date: 2013-08-10 10:01 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/11237ee74aae 8019915: whitebox testClearMethodStateTest fails with tiered on sparc Summary: 'compileonly' directive has beens added to each 'compiler/whitebox' test Reviewed-by: kvn ! test/compiler/whitebox/ClearMethodStateTest.java ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java ! test/compiler/whitebox/SetDontInlineMethodTest.java ! test/compiler/whitebox/SetForceInlineMethodTest.java Changeset: bcc4f6f54d83 Author: kvn Date: 2013-08-14 10:21 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/bcc4f6f54d83 8022993: Convert MAX_UNROLL constant to LoopMaxUnroll C2 flag Summary: Replace MAX_UNROLL constant with new C2 LoopMaxUnroll flag. Reviewed-by: roland ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/loopTransform.cpp Changeset: 56b94e55267a Author: rbackman Date: 2013-08-15 15:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/56b94e55267a Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 9766f73e770d Author: stefank Date: 2013-05-31 14:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9766f73e770d 8022880: False sharing between PSPromotionManager instances Summary: Pad the PSPromotionManager instances in the manager array. Reviewed-by: brutisso, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parNew/parOopClosures.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp + src/share/vm/memory/padded.hpp + src/share/vm/memory/padded.inline.hpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 330dfb0476f4 Author: brutisso Date: 2013-08-14 09:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/330dfb0476f4 8022800: Use specific generations rather than generation iteration Reviewed-by: jmasa, ehelin ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genRemSet.hpp Changeset: 3f22cbf5275d Author: brutisso Date: 2013-08-14 10:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3f22cbf5275d Merge Changeset: 5d9995d16b26 Author: ehelin Date: 2013-08-14 13:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5d9995d16b26 8022899: SunStudio compiler can not handle EXCEPTION_MARK and inlining Reviewed-by: coleenp, mgerdin ! src/share/vm/utilities/exceptions.hpp Changeset: bd902affe102 Author: brutisso Date: 2013-08-15 10:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bd902affe102 8023021: Unnecessary clearing of the card table introduced by the fix for JDK-8023013 Reviewed-by: stefank, ehelin ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genRemSet.hpp Changeset: 274ce305e5b9 Author: ehelin Date: 2013-08-13 18:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/274ce305e5b9 8020598: ObjectCountEventSender::send needs INCLUDE_TRACE guards when building OpenJDK with INCLUDE_TRACE=0 Reviewed-by: stefank, brutisso, sjohanss ! src/share/vm/gc_implementation/shared/objectCountEventSender.cpp Changeset: 33d39b75663f Author: ehelin Date: 2013-08-15 06:20 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/33d39b75663f Merge Changeset: 5a62937e55b3 Author: brutisso Date: 2013-08-16 09:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5a62937e55b3 Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 580430d131cc Author: amurillo Date: 2013-08-16 04:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/580430d131cc Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 104743074675 Author: amurillo Date: 2013-08-16 04:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/104743074675 Added tag hs25-b46 for changeset 580430d131cc ! .hgtags Changeset: 3cce976666d9 Author: Gilles Duboscq Date: 2013-10-10 14:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3cce976666d9 Merge hs25-b46 ! .hgtags ! make/hotspot_version ! make/linux/makefiles/adlc.make ! make/windows/create.bat ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/os/windows/vm/os_windows.cpp - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/tools/ProjectCreator/FileTreeCreatorVC10.java ! src/share/tools/ProjectCreator/ProjectCreator.java ! src/share/tools/ProjectCreator/WinGammaPlatform.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/globalDefinitions.hpp - test/runtime/7196045/Test7196045.java - test/runtime/8000968/Test8000968.sh Changeset: a8819fceb5b5 Author: Gilles Duboscq Date: 2013-10-10 17:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a8819fceb5b5 Disable TieredCompilation if Graal is enabled ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp Changeset: 7e5cf369559f Author: Gilles Duboscq Date: 2013-10-10 17:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7e5cf369559f Merge Changeset: fbe1ee508936 Author: Doug Simon Date: 2013-10-10 18:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fbe1ee508936 added ability to suppress duplicate lines on an output stream and used it to filter the GC verification log messages in the gate ! mx/commands.py ! mxtool/mx.py Changeset: e6fd83e09082 Author: Doug Simon Date: 2013-10-10 18:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e6fd83e09082 removed API for storing a Graph with an InstalledCode ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/PTXTestBase.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotCryptoSubstitutionTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotNmethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/DelegatingGraalCodeCacheProvider.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/GraalCodeCacheProvider.java Changeset: 6aef5b6bbdd8 Author: Doug Simon Date: 2013-10-10 18:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6aef5b6bbdd8 Merge. - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad - test/runtime/7196045/Test7196045.java - test/runtime/8000968/Test8000968.sh Changeset: 0fc653a9e019 Author: Doug Simon Date: 2013-10-10 20:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0fc653a9e019 made GraalCodeCacheProvider independent of CodeCacheProvider and renamed the former to LoweringProvider (GRAAL-511) ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CodeCacheProvider.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaAccessProvider.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/ForEachToGraal.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILBackend.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILCompilationResult.java ! 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/PTXBackend.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/BoxingEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/CompareCanonicalizerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionalEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/DegeneratedLoopsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/EliminateNestedCheckCastsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FinalizableSubclassTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FloatingReadTest.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/IfCanonicalizerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InfopointReasonTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InvokeExceptionTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InvokeHintsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/LockEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/LoopUnswitchTest.java ! 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/MonitorGraphTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/PushNodesThroughPiTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ReadAfterCheckCastTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ReassociateAndCanonicalTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ScalarTypeSystemTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/StampCanonicalizerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/StraighteningTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/TypeSystemTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/backend/AllocatorTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/deopt/CompiledMethodTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EarlyReadEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EscapeAnalysisTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/IterativeInliningTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PartialEscapeAnalysisTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/inlining/InliningTest.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.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.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.test/src/com/oracle/graal/hotspot/test/HotSpotCryptoSubstitutionTest.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/HotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReplacementsImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/StubForeignCallNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CheckCastDynamicSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/InstanceOfSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/LoadExceptionObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopySnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeLoadSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/SnippetStub.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.java/src/com/oracle/graal/java/VerifyOptionsPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConvertNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerRemNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedDivNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedRemNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/debug/DynamicCounterNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/BoxNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadHubNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadMethodNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/OSRStartNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/StoreHubNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnboxNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeLoadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeStoreNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AbstractNewArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AccessFieldNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AccessIndexedNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ArrayLengthNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastDynamicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CompareAndSwapNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfDynamicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/InstanceOfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadExceptionObjectNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MonitorEnterNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MonitorExitNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewInstanceNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewMultiArrayNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/DelegatingGraalCodeCacheProvider.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/DelegatingLoweringProvider.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/GraalCodeCacheProvider.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LoweringProvider.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LoweringTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/CommitAllocationNode.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/LoweringPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/HighTierContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/LowTierContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/MidTierContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/PhaseContext.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinterObserver.java ! graal/com.oracle.graal.replacements.amd64/src/com/oracle/graal/replacements/amd64/AMD64ConvertSnippets.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/MethodSubstitutionTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/ObjectAccessTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/PointerTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/WordTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/BoxingSnippets.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/InstanceOfSnippetsTemplates.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 ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.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 ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleReplacements.java Changeset: c3a1d5bfc3ee Author: Bernhard Urban Date: 2013-10-10 22:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c3a1d5bfc3ee NodeClassIterator: specialize instance for each type of iterator (inputs/successors) in order to share directCount/offsets directly with NodeClass ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: dcd412a084a2 Author: Bernhard Urban Date: 2013-10-11 00:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dcd412a084a2 NodeClassIterator: seperate implementation for modCount check ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 4c70eafaa609 Author: Doug Simon Date: 2013-10-10 22:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4c70eafaa609 removed unnecessary delegating classes - graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/DelegatingCodeCacheProvider.java - graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/DelegatingMetaAccessProvider.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/DelegatingLoweringProvider.java Changeset: 3cd7b1a27645 Author: Doug Simon Date: 2013-10-10 22:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3cd7b1a27645 rename: metaAccessProvider -> metaAccess ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/CompressedOopTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/InstalledCodeExecuteHelperTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CallSiteTargetNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluatorCanonicalizer.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/LoadIndexedFinalNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameAccessNode.java Changeset: 9584d08f56db Author: Doug Simon Date: 2013-10-10 23:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9584d08f56db rename: lookupRegisterConfig -> getRegisterConfig ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CodeCacheProvider.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CodeUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotForeignCallLinkage.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 9c2111d10e40 Author: Doug Simon Date: 2013-10-10 23:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9c2111d10e40 rename: lookupRegisterConfig -> getRegisterConfig (part 2) ! graal/com.oracle.graal.asm.test/src/com/oracle/graal/asm/test/AssemblerTest.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXBackend.java ! graal/com.oracle.graal.hotspot.amd64.test/src/com/oracle/graal/hotspot/amd64/test/AMD64HotSpotFrameOmissionTest.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/AMD64HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotReturnOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java Changeset: 0afe7370260c Author: Doug Simon Date: 2013-10-11 12:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0afe7370260c refactored constantEquals(), lookupArrayLength() and readUnsafeConstant() out of MetaAccessProvider into ConstantReflectionProvider (GRAAL-511) ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestMetaAccessProvider.java ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TypeUniverse.java + graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ConstantReflectionProvider.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaAccessProvider.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILCompilationResult.java ! 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/BoxingEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/CompareCanonicalizerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionalEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/DegeneratedLoopsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/EliminateNestedCheckCastsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FinalizableSubclassTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FloatingReadTest.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/IfCanonicalizerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InfopointReasonTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InvokeExceptionTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InvokeHintsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/LockEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/LoopUnswitchTest.java ! 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/MonitorGraphTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/PushNodesThroughPiTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ReadAfterCheckCastTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ReassociateAndCanonicalTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ScalarTypeSystemTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/StampCanonicalizerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/StraighteningTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/TypeSystemTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/backend/AllocatorTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/deopt/CompiledMethodTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EarlyReadEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EscapeAnalysisTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/IterativeInliningTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PartialEscapeAnalysisTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/inlining/InliningTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/spi/CanonicalizerTool.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.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/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReplacementsImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CheckCastDynamicSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/InstanceOfSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/LoadExceptionObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopySnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeLoadSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/SnippetStub.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.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/CompareNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/Condition.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ArrayLengthNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/TypeSwitchNode.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/CanonicalizerPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.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/LoweringPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/HighTierContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/LowTierContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/MidTierContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/PhaseContext.java ! graal/com.oracle.graal.replacements.amd64/src/com/oracle/graal/replacements/amd64/AMD64ConvertSnippets.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/MethodSubstitutionTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/ObjectAccessTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/PointerTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/WordTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/BoxingSnippets.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/InstanceOfSnippetsTemplates.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 ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluatorCanonicalizer.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleReplacements.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/LoadIndexedFinalNode.java Changeset: 30ca2c3ad590 Author: Doug Simon Date: 2013-10-11 12:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/30ca2c3ad590 Merge. Changeset: bba234a1670e Author: Doug Simon Date: 2013-10-11 16:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bba234a1670e grouped provider values/parameters into a Providers object (GRAAL-511) ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILCompilationResult.java ! 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/BoxingEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/CompareCanonicalizerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionalEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/DegeneratedLoopsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/EliminateNestedCheckCastsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FinalizableSubclassTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/FloatingReadTest.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/IfCanonicalizerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InfopointReasonTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InvokeExceptionTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InvokeHintsTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/LockEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/LoopUnswitchTest.java ! 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/MonitorGraphTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/PushNodesThroughPiTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ReadAfterCheckCastTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ReassociateAndCanonicalTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ScalarTypeSystemTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/StampCanonicalizerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/StraighteningTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/TypeSystemTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/backend/AllocatorTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/deopt/CompiledMethodTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EarlyReadEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EscapeAnalysisTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/IterativeInliningTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PEAReadEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PartialEscapeAnalysisTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/inlining/InliningTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotCryptoSubstitutionTest.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/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CheckCastDynamicSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/InstanceOfSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/LoadExceptionObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopySnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeLoadSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/SnippetStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/UnwindExceptionToCallerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VerifyOopStub.java ! graal/com.oracle.graal.java.decompiler.test/src/com/oracle/graal/java/decompiler/test/TestUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.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/tiers/HighTierContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/LowTierContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/MidTierContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/PhaseContext.java + graal/com.oracle.graal.phases/src/com/oracle/graal/phases/util/Providers.java ! graal/com.oracle.graal.replacements.amd64/src/com/oracle/graal/replacements/amd64/AMD64ConvertSnippets.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/MethodSubstitutionTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/PointerTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/BoxingSnippets.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/InstanceOfSnippetsTemplates.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 ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.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 ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: d96f52012aaa Author: rdurbin Date: 2013-08-14 15:12 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d96f52012aaa 8005073: [TESTBUG] remove crufty '_g' support from HS tests Summary: remove crufty '_g' support from HS tests Reviewed-by: dcubed, sla ! test/Makefile Changeset: 740e263c80c6 Author: hseigel Date: 2013-08-15 20:04 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/740e263c80c6 8003424: Enable Class Data Sharing for CompressedOops 8016729: ObjectAlignmentInBytes=16 now forces the use of heap based compressed oops 8005933: The -Xshare:auto option is ignored for -server Summary: Move klass metaspace above the heap and support CDS with compressed klass ptrs. Reviewed-by: coleenp, kvn, mgerdin, tschatzl, stefank ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klass.inline.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/utilities/globalDefinitions.hpp + test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrs.java + test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java + test/runtime/CDSCompressedKPtrs/XShareAuto.java ! test/runtime/SharedArchiveFile/CdsSameObjectAlignment.java Changeset: 58fc8e2b7b6d Author: Gilles Duboscq Date: 2013-10-10 17:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/58fc8e2b7b6d Merge ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: ccb4f2af2319 Author: Gilles Duboscq Date: 2013-10-10 18:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ccb4f2af2319 Adapt compressed pointers implementation for last HotSpot changes ! 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/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotMove.java Changeset: c93e0a210e1b Author: cl Date: 2013-08-22 09:10 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c93e0a210e1b Added tag jdk8-b104 for changeset 104743074675 ! .hgtags Changeset: 37165c3618a3 Author: amurillo Date: 2013-08-16 04:24 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/37165c3618a3 8023152: new hotspot build - hs25-b47 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e5003079dfa5 Author: dcubed Date: 2013-08-16 10:06 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e5003079dfa5 Merge ! src/share/vm/utilities/globalDefinitions.hpp Changeset: b1fd869e7df0 Author: minqi Date: 2013-08-19 09:16 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b1fd869e7df0 8023188: Unsafe volatile double store on bsd is broken Reviewed-by: dcubed, dholmes Contributed-by: yumin.qi at oracle.com ! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp Changeset: 1a8fb39bdbc4 Author: ehelin Date: 2013-08-07 16:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1a8fb39bdbc4 8014659: NPG: performance counters for compressed klass space Reviewed-by: mgerdin, coleenp, hseigel, jmasa, ctornqvi ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/memory/universe.cpp + test/gc/metaspace/TestMetaspacePerfCounters.java + test/testlibrary/AssertsTest.java + test/testlibrary/com/oracle/java/testlibrary/Asserts.java + test/testlibrary/com/oracle/java/testlibrary/ByteCodeLoader.java + test/testlibrary/com/oracle/java/testlibrary/InMemoryJavaCompiler.java + test/testlibrary/com/oracle/java/testlibrary/InputArguments.java + test/testlibrary/com/oracle/java/testlibrary/PerfCounter.java + test/testlibrary/com/oracle/java/testlibrary/PerfCounters.java Changeset: 878bb0b7e799 Author: ehelin Date: 2013-08-19 17:29 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/878bb0b7e799 Merge Changeset: 10c59b8021ec Author: kevinw Date: 2013-08-19 14:28 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/10c59b8021ec 8022655: ClassDump ignored jarStream setting Reviewed-by: minqi, sla ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java ! test/compiler/ciReplay/common.sh Changeset: 9011aa6843ce Author: kevinw Date: 2013-08-19 22:28 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9011aa6843ce Merge Changeset: e22ee8e7ae62 Author: jiangli Date: 2013-08-19 14:59 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/e22ee8e7ae62 8021948: Change InstanceKlass::_source_file_name and _generic_signature from Symbol* to constant pool indexes. Summary: Change InstanceKlass::_source_file_name and _generic_signature to u2 fields. Reviewed-by: coleenp, iklam ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: aeebffb56606 Author: jiangli Date: 2013-08-20 00:48 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/aeebffb56606 Merge Changeset: 9d6c9b0a8f15 Author: dcubed Date: 2013-08-20 13:47 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9d6c9b0a8f15 8023287: HOTSPOT_BUILD_COMPILER needs to support "Sun Studio 12u3" Summary: Recognize 0x5120 as "Sun Studio 12u3". Reviewed-by: dholmes, coleenp ! src/share/vm/runtime/vm_version.cpp Changeset: afbe18ae0905 Author: bharadwaj Date: 2013-08-15 11:59 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/afbe18ae0905 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases Summary: Corrected details Reviewed-by: kvn, twisti, rbackman Contributed-by: david.r.chase at oracle.com ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp Changeset: adb9a7d94cb5 Author: adlertz Date: 2013-08-16 10:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/adb9a7d94cb5 8023003: Cleanup the public interface to PhaseCFG Summary: public methods that don't need to be public should be private. Reviewed-by: kvn, twisti ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 6c72125a2f40 Author: iignatyev Date: 2013-08-16 17:34 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/6c72125a2f40 8016456: ciReplay test assumes TIERED compilation is available Reviewed-by: vlivanov, kvn, dholmes ! test/compiler/ciReplay/common.sh Changeset: f99558245e5c Author: iignatyev Date: 2013-08-14 23:50 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/f99558245e5c 8022832: Add WB APIs for OSR compilation Reviewed-by: kvn ! src/share/vm/oops/method.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! test/compiler/whitebox/ClearMethodStateTest.java ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java ! test/compiler/whitebox/SetDontInlineMethodTest.java ! test/compiler/whitebox/SetForceInlineMethodTest.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: d18b10b1fd09 Author: iignatyev Date: 2013-08-16 13:39 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/d18b10b1fd09 Merge Changeset: 4b2838704fd5 Author: kvn Date: 2013-08-16 14:11 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4b2838704fd5 8021898: Broken JIT compiler optimization for loop unswitching Summary: fix method clone_projs() to clone all related MachProj nodes. Reviewed-by: roland, adlertz ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 6725044c5725 Author: rbackman Date: 2013-08-19 09:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6725044c5725 Merge ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/oops/method.cpp Changeset: e16282db4946 Author: twisti Date: 2013-08-20 10:57 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e16282db4946 8022956: Clang: enable return type warnings on BSD Reviewed-by: coleenp, sla ! make/bsd/makefiles/gcc.make ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/icBuffer_zero.cpp ! src/cpu/zero/vm/interp_masm_zero.hpp ! src/cpu/zero/vm/interpreter_zero.cpp ! src/cpu/zero/vm/nativeInst_zero.hpp ! src/cpu/zero/vm/register_zero.cpp ! src/cpu/zero/vm/relocInfo_zero.cpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/cpu/zero/vm/vtableStubs_zero.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp Changeset: acedd49a1bce Author: rbackman Date: 2013-08-08 03:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/acedd49a1bce 8022675: Redundant class init check Reviewed-by: kvn, twisti ! src/share/vm/opto/library_call.cpp Changeset: 4dece0730c50 Author: rbackman Date: 2013-08-22 18:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4dece0730c50 Merge ! src/share/vm/runtime/vmStructs.cpp ! test/compiler/ciReplay/common.sh Changeset: 5888334c9c24 Author: johnc Date: 2013-08-15 10:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5888334c9c24 7145569: G1: optimize nmethods scanning Summary: Add a list of nmethods to the RSet for a region that contain references into the region. Skip scanning the code cache during root scanning and scan the nmethod lists during RSet scanning instead. Reviewed-by: tschatzl, brutisso, mgerdin, twisti, kvn ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/utilities/growableArray.hpp Changeset: 8088d93a63e6 Author: brutisso Date: 2013-08-15 13:02 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8088d93a63e6 Merge Changeset: 9720d338b1d5 Author: brutisso Date: 2013-08-16 11:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9720d338b1d5 8023145: G1: G1CollectedHeap::mark_strong_code_roots() needs to handle ParallelGCThreads=0 Reviewed-by: stefank, mgerdin ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: d0afbee540e0 Author: stefank Date: 2013-08-19 13:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d0afbee540e0 8023227: Enhance layout_helper_log2_element_size assert Reviewed-by: mgerdin, jmasa ! src/share/vm/oops/klass.hpp Changeset: 422920730903 Author: ehelin Date: 2013-08-19 18:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/422920730903 8023219: NPG: MetaspaceMemoryPool should report statistics for all of metaspace Reviewed-by: stefank, sjohanss ! src/share/vm/services/memoryPool.cpp Changeset: 57600c4aeabe Author: jmasa Date: 2013-08-19 08:58 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/57600c4aeabe Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 31f220c1f789 Author: jmasa Date: 2013-08-20 10:02 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/31f220c1f789 Merge Changeset: 61521bd65100 Author: tschatzl Date: 2013-08-21 10:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/61521bd65100 8022784: TaskQueue misses minimal documentation and references for analysis Summary: Add appropriate documentation and references to publication to allow easier analysis of the TaskQueue implementation. Reviewed-by: dholmes, ehelin ! src/share/vm/utilities/taskqueue.hpp Changeset: cb9da55b1990 Author: jmasa Date: 2013-08-14 19:52 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/cb9da55b1990 8021809: Partitioning based on eden sampling during allocation not reset correctly Reviewed-by: ysr, hiroshi ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: b51aee2dd8bb Author: jmasa Date: 2013-08-22 11:13 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b51aee2dd8bb Merge ! src/share/vm/oops/klass.hpp Changeset: 8009adb44523 Author: jmasa Date: 2013-08-22 14:03 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8009adb44523 Merge Changeset: c1604d5885a6 Author: amurillo Date: 2013-08-23 03:01 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c1604d5885a6 Merge Changeset: acac3bde66b2 Author: amurillo Date: 2013-08-23 03:01 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/acac3bde66b2 Added tag hs25-b47 for changeset c1604d5885a6 ! .hgtags Changeset: b649cfa58604 Author: cl Date: 2013-08-29 09:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b649cfa58604 Added tag jdk8-b105 for changeset acac3bde66b2 ! .hgtags Changeset: 73921c720b94 Author: amurillo Date: 2013-08-23 03:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/73921c720b94 8023635: new hotspot build - hs25-b48 Reviewed-by: jcoomes ! make/hotspot_version Changeset: c6ec0a97b30a Author: sla Date: 2013-08-21 13:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c6ec0a97b30a 8022808: Kitchensink hangs on macos Summary: Use pthread_mach_thread_np() instead of mach_thread_self() to avoid leaking resources Reviewed-by: dholmes, rbackman ! src/os/bsd/vm/os_bsd.cpp Changeset: 3a57fa7a4cd0 Author: hseigel Date: 2013-08-22 11:52 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/3a57fa7a4cd0 7121403: [TESTBUG] runtime/7051189/Xchecksig.sh fails on 64bit solaris 8023393: Need to suppress info message if -Xcheck:jni used with libjsig.dylab on Mac OSX Summary: Rewrite 7051189 test in Java, port Linux fix for 7051189 to Mac OSX. Reviewed-by: coleenp, dholmes, mseledtsov, ccheung ! src/os/bsd/vm/os_bsd.cpp - test/runtime/7051189/Xchecksig.sh + test/runtime/XCheckJniJsig/XCheckJSig.java Changeset: e37ab280bbce Author: allwin Date: 2013-07-23 14:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e37ab280bbce 8011888: sa.js: TypeError: [object JSAdapter] has no such function "__has__" Reviewed-by: sla, sundar, kmo Contributed-by: yunda.mly at taobao.com ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js Changeset: 669d9a235486 Author: sla Date: 2013-08-22 14:56 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/669d9a235486 Merge Changeset: c062a6e1fa33 Author: iklam Date: 2013-08-22 10:20 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c062a6e1fa33 8023406: make/windows/build_vm_def.sh takes too long even when BUILD_WIN_SA != 1 Summary: Avoid dumping C++ vtable when BUILD_WIN_SA != 1 Reviewed-by: dcubed, sla, tbell ! make/windows/build_vm_def.sh ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make Changeset: 811aea34d5e7 Author: iklam Date: 2013-08-22 13:53 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/811aea34d5e7 Merge Changeset: ff2520b97b00 Author: jiangli Date: 2013-08-22 19:27 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/ff2520b97b00 8023547: com/sun/jdi/RedefineMulti.sh fails with IllegalArgumentException after JDK-8021948 . Summary: Need to check if the constant pool mapping returns 0. Reviewed-by: coleenp, sspitsyn ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 887db75613f8 Author: jiangli Date: 2013-08-22 17:21 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/887db75613f8 Merge Changeset: a70566600baf Author: poonam Date: 2013-08-21 22:12 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a70566600baf 8020530: Non heap memory size calculated incorrectly Reviewed-by: coleenp, sla Contributed-by: vladimir.kempik at oracle.com ! src/share/vm/services/management.cpp Changeset: 730210728146 Author: poonam Date: 2013-08-22 18:09 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/730210728146 Merge - test/runtime/7051189/Xchecksig.sh Changeset: 817e46dd5864 Author: poonam Date: 2013-08-22 21:23 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/817e46dd5864 Merge Changeset: 739c309fd729 Author: mgronlun Date: 2013-08-23 10:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/739c309fd729 8023457: Event based tracing framework needs a mutex for thread groups Reviewed-by: acorn, sla ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: cacc421f39d7 Author: dcubed Date: 2013-08-23 10:39 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/cacc421f39d7 Merge - test/runtime/7051189/Xchecksig.sh Changeset: badf4244ceae Author: hseigel Date: 2013-08-25 21:21 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/badf4244ceae 8022183: GCC 4.6 change sdefault setting for omit-frame-pointer which breaks hotspot stack walking Summary: Explicitly specify -fno-omit-frame-pointer. Reviewed-by: coleenp, dholmes, dcubed ! make/linux/makefiles/amd64.make ! make/linux/makefiles/gcc.make Changeset: faf2631b9334 Author: dsimms Date: 2013-08-26 09:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/faf2631b9334 8022683: JNI GetStringUTFChars should return NULL on allocation failure not abort the VM Summary: Return NULL on OOM from GetStringChars, GetStringUTFChars and GetArrayElements family of functions. Reviewed-by: dholmes, coleenp ! src/share/vm/memory/allocation.hpp ! src/share/vm/prims/jni.cpp Changeset: 4c84d351cca9 Author: stefank Date: 2013-08-16 13:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4c84d351cca9 8007074: SIGSEGV at ParMarkBitMap::verify_clear() Summary: Replace the broken large pages implementation on Linux. New flag: -XX:+UseTransparentHugePages - Linux specific flag to turn on transparent huge page hinting with madvise(..., MAP_HUGETLB). Changed behavior: -XX:+UseLargePages - tries to use -XX:+UseTransparentHugePages before trying other large pages implementations (on Linux). Changed behavior: -XX:+UseHugeTLBFS - Use upfront allocation of Large Pages instead of using the broken implementation to dynamically committing large pages. Changed behavior: -XX:LargePageSizeInBytes - Turned off the ability to use this flag on Linux and provides warning to user if set to a value different than the OS chosen large page size. Changed behavior: Setting no large page size - Now defaults to use -XX:UseTransparentHugePages if the OS supports it. Previously, -XX:+UseHugeTLBFS was chosen if the OS was configured to use large pages. Reviewed-by: tschatzl, dcubed, brutisso ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 21ffbaa691b5 Author: stefank Date: 2013-08-26 07:01 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/21ffbaa691b5 Merge ! src/share/vm/prims/jni.cpp Changeset: 1bb10d3170fa Author: jmasa Date: 2013-08-16 06:12 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1bb10d3170fa 8022817: CMS should not shrink if compaction was not done Reviewed-by: ysr, mgerdin ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: f7d3b4387a16 Author: brutisso Date: 2013-08-21 22:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f7d3b4387a16 8022872: G1: Use correct GC cause for young GC triggered by humongous allocations Reviewed-by: tonyp, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp Changeset: c31eb8c86a50 Author: brutisso Date: 2013-08-22 04:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c31eb8c86a50 Merge Changeset: ec145d04eda8 Author: jmasa Date: 2013-08-23 15:59 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ec145d04eda8 Merge Changeset: 1624a68007bd Author: jmasa Date: 2013-08-27 18:55 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1624a68007bd Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: f92b82d454fa Author: bpittore Date: 2013-08-23 20:33 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/f92b82d454fa 8014135: The JVMTI specification does not conform to recent changes in JNI specification Summary: Added support for statically linked agents Reviewed-by: sspitsyn, bobv, coleenp ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp Changeset: 5fd8e2fbafd4 Author: cjplummer Date: 2013-08-23 12:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5fd8e2fbafd4 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is not supported Summary: Make tests query a new WhiteBox API to see if NMT detail is supported, and behave properly if it is not supported. Reviewed-by: dholmes, coleenp ! src/share/vm/prims/whitebox.cpp ! test/runtime/NMT/ThreadedVirtualAllocTestType.java ! test/runtime/NMT/VirtualAllocTestType.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 7aa0c1fb6fdb Author: dholmes Date: 2013-08-27 22:05 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/7aa0c1fb6fdb 8006164: [TESTBUG] compact profile hotspot test issues Summary: Define profile-based test groups. Reviewed-by: dcubed, mchung ! test/TEST.ROOT + test/TEST.groups Changeset: 1fedf3c7f923 Author: bpittore Date: 2013-08-28 14:44 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/1fedf3c7f923 8023580: Add jtreg test for 8004051 and 8005722 Summary: Tests checks an assertion dealing with the number of args passed in registers Reviewed-by: mseledtsov, kvn + test/compiler/8004051/Test8004051.java Changeset: b1fb293d92c4 Author: jiangli Date: 2013-08-28 12:01 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b1fb293d92c4 Merge Changeset: 2b113b65a051 Author: dholmes Date: 2013-08-28 19:25 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/2b113b65a051 8023900: [TESTBUG] Initial compact profile test groups need adjusting Reviewed-by: dcubed, mchung, hseigel ! test/TEST.groups Changeset: 54dfd798deaf Author: dholmes Date: 2013-08-28 21:42 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/54dfd798deaf Merge Changeset: 62f527c674d2 Author: dholmes Date: 2013-08-29 00:22 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/62f527c674d2 Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp Changeset: 18b4798adbc4 Author: amurillo Date: 2013-08-30 00:19 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/18b4798adbc4 Merge - test/runtime/7051189/Xchecksig.sh Changeset: aed585cafc0d Author: amurillo Date: 2013-08-30 00:19 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/aed585cafc0d Added tag hs25-b48 for changeset 18b4798adbc4 ! .hgtags Changeset: 3f4392035ec7 Author: cl Date: 2013-09-05 02:45 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3f4392035ec7 Added tag jdk8-b106 for changeset aed585cafc0d ! .hgtags Changeset: c169f7038414 Author: amurillo Date: 2013-08-30 00:29 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c169f7038414 8024022: new hotspot build - hs25-b49 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 4a1efab850f4 Author: shade Date: 2013-08-26 17:42 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/4a1efab850f4 8023638: Add the regression test for 8006997 Summary: Add the relevant test and proofread the VM messages as well Reviewed-by: coleenp, mseledtsov, dcubed ! src/share/vm/runtime/arguments.cpp + test/runtime/contended/Options.java Changeset: a7d8baf4cca7 Author: dcubed Date: 2013-08-26 18:34 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a7d8baf4cca7 Merge Changeset: 91b93f523ec6 Author: acorn Date: 2013-08-26 11:35 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/91b93f523ec6 8012294: remove generic handling for default methods Reviewed-by: kamg, coleenp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp - src/share/vm/classfile/genericSignatures.cpp - src/share/vm/classfile/genericSignatures.hpp ! src/share/vm/runtime/globals.hpp Changeset: d80493ee6430 Author: acorn Date: 2013-08-27 01:21 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d80493ee6430 Merge - src/share/vm/classfile/genericSignatures.cpp - src/share/vm/classfile/genericSignatures.hpp ! src/share/vm/runtime/globals.hpp Changeset: 6b3ac96bada6 Author: jiangli Date: 2013-08-26 13:32 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/6b3ac96bada6 8023477: Invalid CP index when reading ConstantPool. Summary: Need to check for 0 case for InstanceKlass::_generic_signature_index. Reviewed-by: sspitsyn, sla ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java Changeset: b3596321fbf4 Author: jiangli Date: 2013-08-27 04:58 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b3596321fbf4 Merge Changeset: 7e7dd25666da Author: ccheung Date: 2013-08-26 14:11 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7e7dd25666da 8020675: invalid jar file in the bootclasspath could lead to jvm fatal error Summary: removed offending EXCEPTION_MARK calls and code cleanup Reviewed-by: dholmes, iklam, coleenp, mseledtsov ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp + test/runtime/LoadClass/LoadClassNegative.java + test/runtime/LoadClass/TestForName.java + test/runtime/LoadClass/dummy.jar Changeset: 5351fe805c12 Author: minqi Date: 2013-08-27 07:54 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5351fe805c12 Merge Changeset: f462e61bce87 Author: iklam Date: 2013-08-26 21:59 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f462e61bce87 8020622: create.bat on Windows failed to create project file for Visual Studio 2012 Summary: Treat VS2012 the same as VS2010. Reviewed-by: dcubed, kamg, minqi ! make/windows/create.bat ! make/windows/makefiles/rules.make Changeset: 35471dcba316 Author: iklam Date: 2013-08-27 03:35 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/35471dcba316 Merge Changeset: c26d57fa08aa Author: iklam Date: 2013-08-27 16:02 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/c26d57fa08aa Merge Changeset: 915cc4f3fb15 Author: acorn Date: 2013-08-28 08:15 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/915cc4f3fb15 8020489: VM crash when non-existent interface called by invokespecial Reviewed-by: kamg, coleenp ! src/share/vm/classfile/defaultMethods.cpp Changeset: cc56f122f3f7 Author: sla Date: 2013-08-29 11:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cc56f122f3f7 8023720: (hotspot) setjmp/longjmp changes the process signal mask on OS X Reviewed-by: dholmes, rbackman ! src/os/posix/vm/os_posix.cpp Changeset: 76482cbba706 Author: hseigel Date: 2013-08-29 10:33 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/76482cbba706 8016764: JVM does not prohibit invokespecial in c.f.v 51.0 that invokes default interface method in c.f.v 52.0 Summary: Check cfv before allowing invokespecial call to default method. Reviewed-by: kamg, acorn, dholmes ! src/share/vm/classfile/verifier.cpp Changeset: dfc126b2f659 Author: hseigel Date: 2013-08-29 13:44 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/dfc126b2f659 8022407: sun/misc/CopyMemory.java fails with SIGSEGV in Unsafe_SetByte+0x35 Summary: lower optimization level for unsafe.cpp due to MacOS Xcode 4.6.2 compiler optimization issue. Reviewed-by: coleenp, twisti, dholmes Contributed-by: lois.foltan at oracle.com ! make/bsd/makefiles/gcc.make Changeset: d8e99408faad Author: dsamersoff Date: 2013-08-29 21:48 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/d8e99408faad 8009062: poor performance of JNI AttachCurrentThread after fix for 7017193 Summary: don't re-evaluate stack bounds for main thread before install guard page Reviewed-by: coleenp, dholmes, dlong ! src/os/linux/vm/os_linux.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp + test/runtime/InitialThreadOverflow/DoOverflow.java + test/runtime/InitialThreadOverflow/invoke.cxx + test/runtime/InitialThreadOverflow/testme.sh Changeset: cef1e56a4d88 Author: dsamersoff Date: 2013-08-29 21:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cef1e56a4d88 Merge Changeset: 9758d9f36299 Author: coleenp Date: 2013-08-29 18:56 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/9758d9f36299 8021954: VM SIGSEGV during classloading on MacOS; hs_err_pid file produced Summary: declare all user-defined operator new()s within Hotspot code with the empty throw() exception specification Reviewed-by: coleenp, twisti, dholmes, hseigel, dcubed, kvn, ccheung Contributed-by: lois.foltan at oracle.com ! src/share/vm/adlc/arena.cpp ! src/share/vm/adlc/arena.hpp ! src/share/vm/adlc/main.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/gc_implementation/shared/gcUtil.hpp ! src/share/vm/libadt/port.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/memRegion.cpp ! src/share/vm/memory/memRegion.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/park.cpp ! src/share/vm/runtime/park.hpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/utilities/array.hpp Changeset: c636758ea616 Author: dcubed Date: 2013-08-30 07:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c636758ea616 Merge ! src/os/posix/vm/os_posix.cpp - src/share/vm/classfile/genericSignatures.cpp - src/share/vm/classfile/genericSignatures.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp Changeset: 522d69638aa8 Author: zgu Date: 2013-08-30 11:54 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/522d69638aa8 6991327: using -Xprof trigger native memory leak Summary: Fixed a memory leak in FlatProfiler::record_thread_tick() method Reviewed-by: dholmes, ccheung ! src/share/vm/runtime/fprofiler.cpp Changeset: 491de79915eb Author: zgu Date: 2013-08-30 12:22 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/491de79915eb Merge ! src/share/vm/runtime/fprofiler.cpp Changeset: ac2764460da7 Author: zgu Date: 2013-08-30 13:38 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/ac2764460da7 Merge Changeset: ca0501b58953 Author: hseigel Date: 2013-08-30 15:07 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/ca0501b58953 8024050: Incorrect optimization level and comment specified for unsafe.cpp Summary: Fix comments and optimization level. Reviewed-by: rdurbin, coleenp, hseigel Contributed-by: lois.foltan at oracle.com ! make/bsd/makefiles/gcc.make Changeset: d8ff06fb87ae Author: hseigel Date: 2013-08-30 15:15 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/d8ff06fb87ae Merge Changeset: abff50660360 Author: hseigel Date: 2013-08-30 15:57 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/abff50660360 Merge Changeset: 3a1df0dce3e5 Author: acorn Date: 2013-08-30 15:15 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/3a1df0dce3e5 8023872: Verification error in generated lambda classes Summary: skip verification for generated lambda classes Reviewed-by: kamg, dholmes ! src/share/vm/classfile/verifier.cpp ! src/share/vm/runtime/globals.hpp Changeset: 735f94656acc Author: acorn Date: 2013-08-30 12:56 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/735f94656acc Merge Changeset: 2918c7e21a3a Author: acorn Date: 2013-08-30 15:42 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2918c7e21a3a Merge Changeset: 35b99e7e0af2 Author: hseigel Date: 2013-09-01 10:37 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/35b99e7e0af2 8023381: VM fails to initialize in runtime/CDSCompressedKPtrs/XShareAuto.java runtime/SharedArchiveFile/CdsSameObjectAlignment.java Summary: Improve handling when CDS archive cannot be mapped Reviewed-by: kvn, dholmes, mseledtsov ! src/share/vm/memory/filemap.cpp ! test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrs.java ! test/runtime/CDSCompressedKPtrs/XShareAuto.java ! test/runtime/SharedArchiveFile/CdsSameObjectAlignment.java Changeset: 766fac3395d6 Author: kvn Date: 2013-08-23 11:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/766fac3395d6 8012972: Incremental Inlining should support scalar replaced object in debug info Summary: store in _first_index not absolute index but an index relative to the last (youngest) jvms->_scloff value Reviewed-by: roland, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp Changeset: b17d8f6d9ed7 Author: kvn Date: 2013-08-23 18:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b17d8f6d9ed7 8023472: C2 optimization breaks with G1 Summary: set control edge for previous value load in G1 pre-barrier Reviewed-by: twisti ! src/share/vm/opto/graphKit.cpp + test/compiler/gcbarriers/G1CrashTest.java Changeset: f98f5d48f511 Author: roland Date: 2013-08-21 13:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f98f5d48f511 7199175: JSR 292: C1 needs patching when invokedynamic/invokehandle call site is not linked Summary: Do patching rather bailing out for unlinked call with appendix Reviewed-by: twisti, kvn ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/c1/c1_globals.cpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: e1fbb86b47e4 Author: roland Date: 2013-08-26 16:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e1fbb86b47e4 8016277: Crash in nmethod::is_compiled_by_c1() on x86 Summary: Method pointer for zombie methods may be invalid Reviewed-by: kvn, coleenp ! src/share/vm/code/nmethod.cpp Changeset: e47de6dfec5d Author: vlivanov Date: 2013-08-26 17:37 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/e47de6dfec5d 8022456: LogCompilation tool does not work with C1 output again Reviewed-by: kvn ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/vm/c1/c1_Compilation.cpp Changeset: 74608df95ba3 Author: vlivanov Date: 2013-08-26 17:41 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/74608df95ba3 8022595: JSR292: deadlock during class loading of MethodHandles, MethodHandleImpl & MethodHandleNatives Reviewed-by: kvn, coleenp, dholmes ! src/share/vm/runtime/thread.cpp + test/compiler/jsr292/ConcurrentClassLoadingTest.java Changeset: 022415fe638e Author: vlivanov Date: 2013-08-26 21:48 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/022415fe638e Merge Changeset: 59982ff9e0ec Author: rbackman Date: 2013-08-20 09:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/59982ff9e0ec 8022283: Assertion failed: assert(is_loaded() && field->holder()->is_loaded() && klass()->is_subclass_of (field->holder())) failed: invalid access Reviewed-by: roland, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciInstance.cpp Changeset: 58e010ab2d06 Author: rbackman Date: 2013-08-27 19:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/58e010ab2d06 Merge Changeset: 650868c062a9 Author: adlertz Date: 2013-08-26 12:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/650868c062a9 8023691: Create interface for nodes in class Block Summary: Create public methods for accessing the nodes in a block Reviewed-by: kvn, roland ! src/share/vm/adlc/output_c.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp Changeset: 7181dd13a6c4 Author: adlertz Date: 2013-08-27 21:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7181dd13a6c4 Merge Changeset: 29aa8936f03c Author: kvn Date: 2013-08-28 11:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/29aa8936f03c 8023597: Optimize G1 barriers code for unsafe load_store Summary: Avoid loading old values in G1 pre-barriers for inlined unsafe load_store nodes. Reviewed-by: kvn, tonyp Contributed-by: Martin Doerr ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp Changeset: 8947af8a9cec Author: vlivanov Date: 2013-08-29 22:44 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/8947af8a9cec 8023976: assert(!CompilationPolicy::can_be_compiled(this, comp_level)) failed: sanity check Reviewed-by: kvn, twisti ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp Changeset: 4b078f877b56 Author: adlertz Date: 2013-09-01 19:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4b078f877b56 8023988: Move local scheduling of nodes to the CFG creation and code motion phase (PhaseCFG) Summary: Moved local scheduling code from class Block to class PhaseCFG Reviewed-by: kvn, roland ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/lcm.cpp Changeset: 40ed2dc92a79 Author: adlertz Date: 2013-09-01 19:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/40ed2dc92a79 Merge Changeset: 27ffd1c4537b Author: rbackman Date: 2013-09-02 13:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/27ffd1c4537b Merge ! src/share/vm/runtime/thread.cpp Changeset: a9a968364704 Author: adlertz Date: 2013-09-02 22:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a9a968364704 8024095: Missing brackets in local scheduling code. Summary: Added brackets for if-statement Reviewed-by: kvn, roland ! src/share/vm/opto/lcm.cpp Changeset: 3bfb204913de Author: adlertz Date: 2013-09-05 10:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3bfb204913de Merge ! src/share/vm/code/nmethod.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/node.hpp Changeset: 88c255656030 Author: mgerdin Date: 2013-08-22 10:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/88c255656030 8016155: SIGBUS when running Kitchensink with ParallelScavenge and ParallelOld Summary: When using NUMA and large pages we need to ease the requirement on which node the memory should be allocated on. To avoid the SIGBUS we now use the memory policy MPOL_PREFERRED, which prefers a certain node, instead of MPOL_BIND, which requires a certain node. Reviewed-by: jmasa, pliden Contributed-by: stefan.johansson at oracle.com ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: 0d59407e7e09 Author: jmasa Date: 2013-08-29 06:53 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0d59407e7e09 Merge ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: 84683e78e713 Author: brutisso Date: 2013-08-30 07:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/84683e78e713 8019902: G1: Use the average heap size rather than the minimum heap size to calculate the region size Reviewed-by: tonyp, tschatzl, sjohanss ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: f175e3678be2 Author: ehelin Date: 2013-08-22 11:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f175e3678be2 8020692: TestGCEventMixed.java failed because of timestamp in event after end event Reviewed-by: mgerdin, stefank ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/shared/gcTraceSend.cpp Changeset: a701c16e8bbf Author: jmasa Date: 2013-09-04 11:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a701c16e8bbf 8013938: Native OOME on fastdebug VM on Solaris Reviewed-by: azeemj, brutisso, kvn, tschatzl ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 428025878417 Author: jmasa Date: 2013-09-04 12:56 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/428025878417 Merge Changeset: bb57d48691f5 Author: tschatzl Date: 2013-09-05 14:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bb57d48691f5 Merge ! src/os/linux/vm/os_linux.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 50794d8ac11c Author: amurillo Date: 2013-09-06 11:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/50794d8ac11c Merge - src/share/vm/classfile/genericSignatures.cpp - src/share/vm/classfile/genericSignatures.hpp Changeset: 5b7f90aab3ad Author: amurillo Date: 2013-09-06 11:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5b7f90aab3ad Added tag hs25-b49 for changeset 50794d8ac11c ! .hgtags Changeset: 9cd0183fe325 Author: cl Date: 2013-09-12 11:08 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9cd0183fe325 Added tag jdk8-b107 for changeset 5b7f90aab3ad ! .hgtags Changeset: 313b724f8911 Author: amurillo Date: 2013-09-06 11:11 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/313b724f8911 8024258: new hotspot build - hs25-b50 Reviewed-by: jcoomes ! make/hotspot_version Changeset: ceda33ff54a3 Author: iignatyev Date: 2013-09-05 16:38 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/ceda33ff54a3 8012447: Java CTW implementation Reviewed-by: vlivanov, kvn, twisti ! test/gc/TestVerifyDuringStartup.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolFinder.java + test/testlibrary/ctw/Makefile + test/testlibrary/ctw/README + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathDirEntry.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathJarEntry.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathJarInDirEntry.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassesListInFile.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/CompileTheWorld.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Compiler.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/PathHandler.java + test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Utils.java + test/testlibrary/ctw/test/Bar.java + test/testlibrary/ctw/test/ClassesDirTest.java + test/testlibrary/ctw/test/ClassesListTest.java + test/testlibrary/ctw/test/CtwTest.java + test/testlibrary/ctw/test/Foo.java + test/testlibrary/ctw/test/JarDirTest.java + test/testlibrary/ctw/test/JarsTest.java + test/testlibrary/ctw/test/classes.lst + test/testlibrary/whitebox/Makefile Changeset: cd16d587b0fa Author: adlertz Date: 2013-09-09 19:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cd16d587b0fa Merge Changeset: 72a567cce06f Author: anoll Date: 2013-09-10 07:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/72a567cce06f 8024473: Remove unused macro: IRT_ENTRY_FOR_NMETHOD Summary: Removed unused macro Reviewed-by: kvn, adlertz ! src/share/vm/runtime/interfaceSupport.hpp Changeset: edb5ab0f3fe5 Author: vlivanov Date: 2013-09-10 14:51 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/edb5ab0f3fe5 8001107: @Stable annotation for constant folding of lazily evaluated variables Reviewed-by: rbackman, twisti, kvn Contributed-by: john.r.rose at oracle.com, vladimir.x.ivanov at oracle.com ! src/share/vm/ci/ciArray.cpp ! src/share/vm/ci/ciArray.hpp ! src/share/vm/ci/ciConstant.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/ci/ciFlags.hpp ! src/share/vm/ci/ciInstance.cpp ! src/share/vm/ci/ciTypeArray.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/accessFlags.hpp Changeset: e0d33d2ce5aa Author: vlivanov Date: 2013-09-10 15:28 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e0d33d2ce5aa Merge Changeset: 34bd5e86aadb Author: adlertz Date: 2013-09-11 09:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/34bd5e86aadb 8010941: MinJumpTableSize is set to 18, investigate if that's still optimal Summary: Lowered the MinJumpTableSize for each platform Reviewed-by: kvn ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/share/vm/opto/c2_globals.hpp Changeset: 0821b5d72ca8 Author: adlertz Date: 2013-09-12 09:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0821b5d72ca8 Merge Changeset: a09fe9d1e016 Author: amurillo Date: 2013-09-13 00:25 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a09fe9d1e016 Merge Changeset: 85072013aad4 Author: amurillo Date: 2013-09-13 00:25 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/85072013aad4 Added tag hs25-b50 for changeset a09fe9d1e016 ! .hgtags Changeset: 34aa07e92d22 Author: cl Date: 2013-09-19 09:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/34aa07e92d22 Added tag jdk8-b108 for changeset 85072013aad4 ! .hgtags Changeset: e42e456fbe6e Author: amurillo Date: 2013-09-13 00:43 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e42e456fbe6e 8024764: new hotspot build - hs25-b51 Reviewed-by: jcoomes ! make/hotspot_version Changeset: baa7927dfbd2 Author: zgu Date: 2013-09-04 08:55 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/baa7927dfbd2 8022798: "assert(seq > 0) failed: counter overflow" in Kitchensink Summary: Removed incorrect assertion, sequence number can overflow Reviewed-by: dholmes, kamg ! src/share/vm/services/memPtr.cpp Changeset: 38f750491293 Author: iklam Date: 2013-09-06 08:42 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/38f750491293 8022335: Native stack walk while generating hs_err does not work on Windows x64 Summary: Use WinDbg API StackWalk64() Reviewed-by: zgu, dholmes ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp Changeset: 592520c14121 Author: kevinw Date: 2013-09-09 10:01 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/592520c14121 8023478: Test fails with HS crash in GCNotifier. Reviewed-by: sla ! src/share/vm/services/gcNotifier.cpp Changeset: b6767a18b379 Author: hseigel Date: 2013-09-09 14:44 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/b6767a18b379 8023167: JVM allows duplicate Runtime[In]VisibleTypeAnnotations attributes in ClassFile/field_info/method_info structures Summary: Add checks for duplicates and issue errors when detected. Reviewed-by: coleenp, zgu ! src/share/vm/classfile/classFileParser.cpp Changeset: 0f648fbe4404 Author: dsamersoff Date: 2013-09-11 14:30 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/0f648fbe4404 8024056: runtime/InitialThreadOverflow/testme.sh fails Summary: on some macines gcc not able to link cxx program Reviewed-by: dholmes ! test/runtime/InitialThreadOverflow/testme.sh Changeset: 1c6b721a3fbf Author: dsamersoff Date: 2013-09-12 15:53 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/1c6b721a3fbf 8022617: Openjdk hotspot build is broken on BSD platforms using gcc Summary: Enforce of preprocessing of all assembly sources by assembler-with-cpp Reviewed-by: dholmes, erikj ! make/bsd/makefiles/gcc.make Changeset: 225cedaf9a4b Author: zgu Date: 2013-09-13 10:34 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/225cedaf9a4b Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 623d923529df Author: mgronlun Date: 2013-09-13 17:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/623d923529df 8021353: Event based tracing is missing thread exit Reviewed-by: allwin, acorn, dcubed, dholmes, egahlin ! src/share/vm/runtime/thread.cpp ! src/share/vm/trace/traceMacros.hpp Changeset: b89a1a870965 Author: mgronlun Date: 2013-09-13 19:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b89a1a870965 Merge ! src/share/vm/runtime/thread.cpp Changeset: ff8a09595db3 Author: sspitsyn Date: 2013-09-13 12:46 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ff8a09595db3 8017230: Internal Error (jvmtiRedefineClasses.cpp:1662): guarantee(false) failed: insert_space_at() failed Summary: Handle pending exceptions instead of firing a guarantee() Reviewed-by: coleenp, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: ce5ee9de50ce Author: sspitsyn Date: 2013-09-13 12:47 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ce5ee9de50ce 8024345: 'assert(_value != NULL) failed: resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool Summary: The OOME's in the JVMTI merge_cp_and_rewrite and set_new_constant_pool must be handled correctly Reviewed-by: coleenp, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 0d3ff4d36a31 Author: sspitsyn Date: 2013-09-13 12:48 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0d3ff4d36a31 8024346: ~CautiouslyPreserveExceptionMark - assert(!_thread->has_pending_exception()) failed: unexpected exception generated Summary: Pending exceptions must be handled properly after a call to the JVMTI merge_cp_and_rewrite Reviewed-by: coleenp, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: b135b600a66c Author: sspitsyn Date: 2013-09-13 16:56 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b135b600a66c Merge Changeset: 2e6938dd68f2 Author: dholmes Date: 2013-09-16 07:38 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/2e6938dd68f2 6900441: PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock Summary: Associate CLOCK_MONOTONIC with the pthread_cond_t objects used for relative timed waits Reviewed-by: dcubed, shade ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: 4472884d8b37 Author: dcubed Date: 2013-09-16 12:43 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4472884d8b37 6986195: correctly identify Ubuntu as the operating system in crash report instead of "Debian" Summary: Cleanup and document how various Linux release info files are used by print_distro_info(). Reviewed-by: dcubed, dsamersoff, coleenp, iklam, omajid Contributed-by: gerald.thornbrugh at oracle.com ! src/os/linux/vm/os_linux.cpp Changeset: 42863137168c Author: acorn Date: 2013-09-16 17:57 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/42863137168c 8024647: Default method resolution with private superclass method Reviewed-by: kamg, minqi ! src/share/vm/classfile/defaultMethods.cpp Changeset: 921967020b3b Author: acorn Date: 2013-09-16 15:24 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/921967020b3b Merge Changeset: 621eda7235d2 Author: minqi Date: 2013-09-16 15:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/621eda7235d2 7164841: Improvements to the GC log file rotation Summary: made changes to easily identify current log file in rotation. Parameterize the input with %t for time replacement in file name. Reviewed-by: ccheung, tschatzl, tamao, zgu Contributed-by: yumin.qi at oracle.com ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp Changeset: 535973ddf22c Author: minqi Date: 2013-09-16 18:39 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/535973ddf22c Merge Changeset: 88d6b9a1c27c Author: mseledtsov Date: 2013-09-17 20:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/88d6b9a1c27c 8016029: test runtime/6878713/Test6878713.sh failed Summary: Rewrote test in Java; updated the test condition to reflect latest changes in the source Reviewed-by: dholmes, ctornqvi - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar + test/runtime/ClassFile/OomWhileParsingRepeatedJsr.java + test/runtime/ClassFile/testcase.jar Changeset: 6f45933aef35 Author: mseledtsov Date: 2013-09-17 20:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6f45933aef35 7149464: [TESTBUG] Test runtime/7020373/Test7020373.sh failed to clean up files after test Summary: Re-wrote in Java, this also eliminated temporary result file; set upper limit on malloc'd memory Reviewed-by: dcubed, dholmes, ccheung - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar + test/runtime/ClassFile/JsrRewriting.java + test/runtime/ClassFile/JsrRewritingTestCase.jar Changeset: 41e6ae9f6dd7 Author: zgu Date: 2013-09-18 12:52 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/41e6ae9f6dd7 Merge - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar Changeset: 8e94527f601e Author: bpittore Date: 2013-09-11 20:03 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/8e94527f601e 8024007: Misc. cleanup of static agent code Summary: Minor cleanup of static agent code from 8014135 Reviewed-by: dcubed, sspitsyn ! src/os/windows/vm/os_windows.cpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp Changeset: de88570fabfc Author: dholmes Date: 2013-09-11 00:38 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/de88570fabfc 8024256: Minimal VM build is broken with PCH disabled Reviewed-by: coleenp, twisti ! make/excludeSrc.make ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 4c9d415db1c5 Author: dholmes Date: 2013-09-11 23:49 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/4c9d415db1c5 Merge Changeset: b1491b0303ee Author: bdelsart Date: 2013-09-13 07:47 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b1491b0303ee Merge Changeset: 10efeefa6485 Author: dholmes Date: 2013-09-13 21:36 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/10efeefa6485 8024505: [TESTBUG] update test groups for additional tests that can't run on the minimal VM Reviewed-by: coleenp, hseigel ! test/TEST.groups Changeset: cc5b40a76049 Author: bdelsart Date: 2013-09-18 21:47 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/cc5b40a76049 Merge ! src/share/vm/runtime/thread.cpp Changeset: 7944aba7ba41 Author: ehelin Date: 2013-08-12 17:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7944aba7ba41 8015107: NPG: Use consistent naming for metaspace concepts Reviewed-by: coleenp, mgerdin, hseigel ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/oops/instanceOop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryService.cpp + test/gc/arguments/TestCompressedClassFlags.java - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java + test/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java ! test/gc/metaspace/TestMetaspaceMemoryPool.java ! test/gc/metaspace/TestMetaspacePerfCounters.java ! test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrs.java ! test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java ! test/runtime/CompressedOops/CompressedKlassPointerAndOops.java Changeset: 440edcf30231 Author: mgerdin Date: 2013-09-11 08:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/440edcf30231 8024176: [macosx] gc/metaspace/ClassMetaspaceSizeInJmapHeap.java failed since jdk8b105, hs25b47 Summary: The code for reading compressed klass pointers in the sa-agent on Mac used readCompOopAddress instead of readCompKlassAddress, this is wrong but has been hidden because compressed oops and compressed klasses has used the same base address in the past. Reviewed-by: sla, jmasa Contributed-by: stefan.johansson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java Changeset: f7bc2ab5f659 Author: tschatzl Date: 2013-09-11 10:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f7bc2ab5f659 8016825: Large pages for the heap broken on Windows for compressed oops Summary: Correctly pass the requested base address for the heap to the OS function to reserve memory. Reviewed-by: brutisso, stefank ! src/os/windows/vm/os_windows.cpp Changeset: ff218fdb30ba Author: tschatzl Date: 2013-09-11 10:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ff218fdb30ba 8021823: G1: Concurrent marking crashes with -XX:ObjectAlignmentInBytes>=32 in 64bit VMs Summary: Correctly calculate the initialization value for the shift between object start and bitmap bit in the G1 mark bitmaps. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp + test/gc/TestObjectAlignment.java Changeset: 040895ec3920 Author: tschatzl Date: 2013-09-11 12:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/040895ec3920 Merge Changeset: 24e87613ee58 Author: mgerdin Date: 2013-09-11 09:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/24e87613ee58 8009561: NPG: Metaspace fragmentation when retiring a Metachunk Summary: Use best-fit block-splitting freelist allocation from the block freelist. Reviewed-by: jmasa, stefank ! src/share/vm/memory/metaspace.cpp Changeset: 6608fa23708f Author: mgerdin Date: 2013-09-11 06:15 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6608fa23708f Merge Changeset: 40136aa2cdb1 Author: tschatzl Date: 2013-09-11 16:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/40136aa2cdb1 8010722: assert: failed: heap size is too big for compressed oops Summary: Use conservative assumptions of required alignment for the various garbage collector components into account when determining the maximum heap size that supports compressed oops. Using this conservative value avoids several circular dependencies in the calculation. Reviewed-by: stefank, dholmes ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp + test/gc/arguments/TestUseCompressedOopsErgo.java + test/gc/arguments/TestUseCompressedOopsErgoTools.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: b82260e84582 Author: tschatzl Date: 2013-09-11 18:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b82260e84582 Merge Changeset: d6c266999345 Author: ehelin Date: 2013-09-12 10:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d6c266999345 8023476: Metaspace capacity > reserved Reviewed-by: stefank, hseigel, mgerdin ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceCounters.cpp Changeset: c4c768305a8f Author: stefank Date: 2013-09-12 10:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c4c768305a8f 8024638: Count and expose the amount of committed memory in the metaspaces Reviewed-by: brutisso, ehelin ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp Changeset: 335b388c4b28 Author: stefank Date: 2013-09-13 22:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/335b388c4b28 8024651: Remove the incorrect usage of Metablock::overhead() Reviewed-by: brutisso, mgerdin, coleenp, jmasa ! src/share/vm/memory/metablock.cpp ! src/share/vm/memory/metablock.hpp ! src/share/vm/memory/metaspace.cpp Changeset: 9e11762cee52 Author: stefank Date: 2013-09-13 22:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9e11762cee52 8024650: Don't adjust MaxMetaspaceSize up to MetaspaceSize Reviewed-by: jwilhelm, brutisso, tschatzl ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp ! src/share/vm/memory/collectorPolicy.cpp + test/gc/metaspace/TestMetaspaceSizeFlags.java ! test/testlibrary/OutputAnalyzerTest.java ! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java Changeset: 8227700da288 Author: stefank Date: 2013-09-13 22:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8227700da288 8024751: Fix bugs in TraceMetadata Reviewed-by: jmasa, brutisso ! src/share/vm/memory/metaspace.cpp Changeset: 8c5e6482cbfc Author: stefank Date: 2013-09-13 22:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8c5e6482cbfc 8024752: Log TraceMetadata* output to gclog_or_tty instead of tty Reviewed-by: brutisso, mgerdin, coleenp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp Changeset: 9cb63cd234a0 Author: shade Date: 2013-09-13 07:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9cb63cd234a0 8024671: G1 generates assert error messages in product builds Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp ! src/share/vm/gc_implementation/g1/g1CardCounts.hpp Changeset: 884ed7a10f09 Author: tschatzl Date: 2013-09-16 09:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/884ed7a10f09 Merge ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/globals.hpp Changeset: 23ae5a04724d Author: tschatzl Date: 2013-09-16 10:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/23ae5a04724d 8024396: VM crashing with assert(!UseLargePages || UseParallelOldGC || use_large_pages) failed: Wrong alignment to use large pages Summary: Loosen wrong assert for UseParallelOldGC to UseParallelGC Reviewed-by: stefank, brutisso ! src/share/vm/memory/universe.cpp + test/gc/arguments/TestAlignmentToUseLargePages.java Changeset: f9b58dbeab91 Author: tschatzl Date: 2013-09-16 13:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f9b58dbeab91 Merge Changeset: 17deed6716af Author: tschatzl Date: 2013-09-17 12:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/17deed6716af 8024914: Swapped usage of idx_t and bm_word_t types in bitMap.inline.hpp Summary: Incorrect usage of idx_t where bm_word_t is appropriate. Reviewed-by: tschatzl, brutisso Contributed-by: Dan Horak ! src/share/vm/utilities/bitMap.inline.hpp Changeset: 5767996b7b7b Author: jwilhelm Date: 2013-09-17 14:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5767996b7b7b 8024884: Test name changed, test list not updated Summary: Updated the test list with the new test name. Reviewed-by: brutisso, ehelin ! test/TEST.groups Changeset: fac394091d73 Author: jwilhelm Date: 2013-09-18 00:08 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/fac394091d73 Merge Changeset: 73d0d0218068 Author: ehelin Date: 2013-09-17 20:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/73d0d0218068 8024718: Metaspace performance counters and memory pools should report the same data Reviewed-by: stefank, dholmes, coleenp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryUsage.hpp ! test/gc/metaspace/TestMetaspaceMemoryPool.java ! test/gc/metaspace/TestMetaspacePerfCounters.java + test/gc/metaspace/TestPerfCountersAndMemoryPools.java ! test/testlibrary/com/oracle/java/testlibrary/InputArguments.java Changeset: 2f426063daea Author: tschatzl Date: 2013-09-18 10:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2f426063daea 8024662: gc/arguments/TestUseCompressedOopsErgo.java does not compile. Summary: Fix compilation error and use of an outdated VM option in the test Reviewed-by: stefank, jwilhelm ! test/gc/arguments/TestUseCompressedOopsErgoTools.java Changeset: 9044964f9163 Author: tschatzl Date: 2013-09-18 13:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9044964f9163 8024669: Native OOME when allocating after changes to maximum heap supporting Coops sizing on sparcv9 Summary: After changes in 8010722 the ergonomics for calculating the size of the heap that supports zero based compressed oops changed. This lead to the VM actually using zero based compressed oops. Due to low default HeapBaseMinAddress, the OS mapping in the application image at the same address, and limitations of the malloc implementation on Solaris this resulted in very little C heap available for the VM. So the VM immediately gives a native OOME when the machine has lots of physical memory (>=32G). The solution is to increase the HeapBaseMinAddress so that the VM has enough C heap. Reviewed-by: kvn, brutisso ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp Changeset: 719e886d4f72 Author: tschatzl Date: 2013-09-18 15:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/719e886d4f72 Merge Changeset: 06ae47d9d088 Author: tschatzl Date: 2013-09-19 09:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/06ae47d9d088 Merge ! src/os/linux/vm/os_linux.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java Changeset: 179cd89fb279 Author: tschatzl Date: 2013-09-19 09:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/179cd89fb279 Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp ! test/TEST.groups Changeset: 8c83625e3a53 Author: adlertz Date: 2013-09-12 23:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8c83625e3a53 8024646: Remove LRG_List container, replace it with GrowableArray Summary: We already have GrowableArray, use it instead of LRG_List Reviewed-by: kvn ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/coalesce.hpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/live.hpp Changeset: 3a4e6c929bf3 Author: twisti Date: 2013-09-12 14:53 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3a4e6c929bf3 8024275: During CTW: assert(sig_bt[member_arg_pos] == T_OBJECT) failed: dispatch argument must be an object Reviewed-by: kvn, vlivanov ! src/share/vm/classfile/classLoader.cpp Changeset: 591b49112612 Author: twisti Date: 2013-09-12 18:13 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/591b49112612 Merge Changeset: 01b268b3080a Author: vlivanov Date: 2013-09-13 04:16 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/01b268b3080a 8023134: Rename VM LogFile to hotspot_pid{pid}.log (was hotspot.log) Reviewed-by: twisti, kvn, sla ! src/share/tools/LogCompilation/README ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/ostream.cpp Changeset: 69f26e8e09f9 Author: twisti Date: 2013-09-13 16:55 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/69f26e8e09f9 8024760: add more types, fields and constants to VMStructs Reviewed-by: kvn, coleenp ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ae3e68933caf Author: adlertz Date: 2013-09-17 05:30 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ae3e68933caf Merge ! src/share/vm/runtime/arguments.cpp Changeset: 22194f27fbfb Author: ctornqvi Date: 2013-09-17 16:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/22194f27fbfb 8014905: [TESTBUG] Some hotspot tests should be updated to divide test jdk and compile jdk Summary: Change JDKToolFinder to look in compile.jdk if the executable cannot be found in test.jdk Reviewed-by: dholmes, hseigel ! test/TEST.groups ! test/gc/TestVerifyDuringStartup.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolFinder.java Changeset: 2c98370f2611 Author: ctornqvi Date: 2013-09-17 23:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2c98370f2611 Merge Changeset: 6d7eba360ba4 Author: anoll Date: 2013-09-17 08:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6d7eba360ba4 8024128: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation Summary: Increase interpreter size for x86 template interpreter Reviewed-by: kvn, iveresov ! src/cpu/x86/vm/templateInterpreter_x86.hpp Changeset: a4788ba67e20 Author: adlertz Date: 2013-09-17 16:07 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a4788ba67e20 Merge Changeset: b2e698d2276c Author: drchase Date: 2013-09-13 22:38 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/b2e698d2276c 8014013: CallInfo structure no longer accurately reports the result of a LinkResolver operation Summary: Enhance method resolution and resulting data structures, plus some refactoring. Reviewed-by: twisti, acorn, jrose ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp ! src/share/vm/oops/fieldStreams.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 67bae56fdd69 Author: jrose Date: 2013-09-17 20:48 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/67bae56fdd69 Merge Changeset: ab274453d37f Author: anoll Date: 2013-09-18 07:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ab274453d37f 8022883: Assertion failed: sweptCount >= flushedCount + markedCount + zombifiedCount Summary: Provide correct number of visited nmethods to Tracing Reviewed-by: kvn, iveresov ! src/share/vm/runtime/sweeper.cpp Changeset: 04cbe2026912 Author: rbackman Date: 2013-09-18 09:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/04cbe2026912 Merge Changeset: 2795dff62b6c Author: iveresov Date: 2013-09-18 14:10 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2795dff62b6c 8023542: Test java/io/File/CheckPermission.java fails due to unfinished recursion (java.lang.StackOverflowError) when JIT'ed code (-client,-server) is running Summary: Move null check before klass reference materialization in checkcast Reviewed-by: kvn, roland ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: da051ce490eb Author: adlertz Date: 2013-09-19 18:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/da051ce490eb Merge ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/ostream.cpp ! test/TEST.groups Changeset: 566db1b0e6ef Author: amurillo Date: 2013-09-20 11:09 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/566db1b0e6ef Merge - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar Changeset: bf13c3da3d11 Author: amurillo Date: 2013-09-20 11:09 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/bf13c3da3d11 Added tag hs25-b51 for changeset 566db1b0e6ef ! .hgtags Changeset: c81dd5393a5e Author: tbell Date: 2013-09-25 12:23 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c81dd5393a5e 8025411: JPRT to switch to the new Win platforms for JDK8 builds this week Reviewed-by: ksrini, katleman ! make/jprt.properties Changeset: fff4842215d1 Author: cl Date: 2013-09-26 10:43 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/fff4842215d1 Added tag jdk8-b109 for changeset c81dd5393a5e ! .hgtags Changeset: 8a6a85321d3a Author: amurillo Date: 2013-09-20 11:17 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8a6a85321d3a 8025127: new hotspot build - hs25-b52 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 63147986a428 Author: dcubed Date: 2013-09-18 07:02 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/63147986a428 8019835: Strings interned in different threads equal but does not == Summary: Add -XX:+VerifyStringTableAtExit option and code to verify StringTable invariants. Reviewed-by: rdurbin, sspitsyn, coleenp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp Changeset: dfae98867ee8 Author: dholmes Date: 2013-09-18 20:08 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/dfae98867ee8 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps Reviewed-by: alanb, chegar, dholmes, ksrini Contributed-by: Mike Duigou ! src/share/vm/runtime/arguments.cpp Changeset: c1d7040a1183 Author: sgabdura Date: 2013-09-18 16:48 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/c1d7040a1183 8022836: JVM crashes in JVMTIENVBASE::GET_CURRENT_CONTENDED_MONITOR and GET_OWNED_MONITOR Summary: Check that the _java_thread parameter is valid when it is possible that the JavaThread has exited after the initial checks were made in generated/jvmtifiles/jvmtiEnter.cpp: jvmti_GetCurrentContendedMonitor() Reviewed-by: dcubed, dsamersoff ! src/share/vm/prims/jvmtiEnvBase.hpp Changeset: 8c84f04ff977 Author: kevinw Date: 2013-09-18 19:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8c84f04ff977 Merge Changeset: 6eb908998b32 Author: kevinw Date: 2013-09-19 08:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6eb908998b32 Merge Changeset: 9ed97b511b26 Author: hseigel Date: 2013-09-19 11:04 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/9ed97b511b26 8024517: runtime/CDSCompressedKPtrs/XShareAuto.java failed with RuntimeException Summary: Make sure CDS is off by default when running server compiler. Reviewed-by: dholmes, coleenp ! src/share/vm/runtime/arguments.cpp ! test/runtime/CDSCompressedKPtrs/XShareAuto.java Changeset: 4f9a42c33738 Author: coleenp Date: 2013-09-20 09:30 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/4f9a42c33738 8022887: Assertion hit while using class and redefining it with RedefineClasses simultaneously Summary: Need to refetch each method from InstanceKlass after all safepoints. Removed leaky PreviousVersionInfo code. Reviewed-by: dcubed, sspitsyn ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/handles.inline.hpp Changeset: f201713502e0 Author: coleenp Date: 2013-09-20 09:44 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/f201713502e0 Merge Changeset: 1b03bed31241 Author: allwin Date: 2013-09-17 17:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1b03bed31241 7196151: ParserTest SEGv on solaris Reviewed-by: sla, coleenp, ctornqvi, dsamersoff ! src/share/vm/services/diagnosticArgument.cpp Changeset: e5a25e4ae509 Author: mgerdin Date: 2013-09-20 10:34 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e5a25e4ae509 Merge Changeset: 7c29904fdfa2 Author: coleenp Date: 2013-09-20 18:34 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/7c29904fdfa2 8014956: nashorn/api/javaaccess/MethodAccessTest.java test fails on sparc-solaris 64 Summary: reference_map[] array had uninitialized junk that was causing a bogus bootstrap method to be found. Reviewed-by: hseigel, dcubed, sspitsyn ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp Changeset: df03413ad1a9 Author: coleenp Date: 2013-09-21 01:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/df03413ad1a9 Merge Changeset: 0f37d1badced Author: dcubed Date: 2013-09-20 12:58 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0f37d1badced Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: a7609ec351d6 Author: dcubed Date: 2013-09-20 18:19 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a7609ec351d6 Merge ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java Changeset: 8ddc26f62476 Author: sla Date: 2013-09-22 06:31 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8ddc26f62476 6989981: jstack causes "fatal error: ExceptionMark destructor expects no pending exceptions" Reviewed-by: sla, dsamersoff Contributed-by: Yasumasa Suenaga ! src/share/vm/services/attachListener.cpp Changeset: 1f42d3ec1759 Author: dsamersoff Date: 2013-09-22 18:49 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/1f42d3ec1759 7133122: SA throws sun.jvm.hotspot.debugger.UnmappedAddressException when it should not Summary: replace PT_LOAD segment with library segment when necessary Reviewed-by: dholmes, sla ! agent/src/os/linux/ps_core.c Changeset: ae2edb3df7fb Author: dsamersoff Date: 2013-09-22 18:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ae2edb3df7fb Merge Changeset: 084b21cd0228 Author: iklam Date: 2013-09-23 08:56 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/084b21cd0228 8025088: Missing cases for JVM_CONSTANT_MethodHandleInError cause crash if debugger steps into error-tagged method handle Summary: Need to refetch each method from InstanceKlass after all safepoints. Removed leaky PreviousVersionInfo code. Reviewed-by: coleenp, sspitsyn ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp Changeset: e8a0010ba69e Author: zgu Date: 2013-09-25 13:03 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/e8a0010ba69e Merge Changeset: 891687731b59 Author: anoll Date: 2013-09-24 15:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/891687731b59 7009641: Don't fail VM when CodeCache is full Summary: Allocation in the code cache returns NULL instead of failing the entire VM Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 1b64d46620a3 Author: kvn Date: 2013-09-24 16:08 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1b64d46620a3 8022585: VM crashes when ran with -XX:+PrintInlining Summary: use adr_at() to access inline info structures in growableArray. Add ability to specify print inlining per method. Reviewed-by: twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/library_call.cpp + test/compiler/print/PrintInlining.java Changeset: f637d4dc21bb Author: adlertz Date: 2013-09-26 08:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f637d4dc21bb Merge Changeset: 586fa1919a89 Author: bpittore Date: 2013-09-20 15:06 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/586fa1919a89 8014911: Should use SUPPORTS_NATIVE_CX8 define to help C/C++ compiler elide blocks of code Summary: If SUPPORTS_NATIVE_CX8 true then supports_cx8() function hard coded to return 'true' Reviewed-by: kvn, twisti, dholmes ! src/share/vm/runtime/vm_version.hpp Changeset: 504d8f519adf Author: jiangli Date: 2013-09-20 20:19 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/504d8f519adf Merge Changeset: d682c6e24fe3 Author: bdelsart Date: 2013-09-26 01:30 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d682c6e24fe3 Merge Changeset: 60a2d625db36 Author: bdelsart Date: 2013-09-26 04:00 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/60a2d625db36 Merge Changeset: 2c022e432e10 Author: stefank Date: 2013-09-20 10:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2c022e432e10 8024974: Incorrect use of GC_locker::is_active() Summary: SymbolTable and StringTable can make calls to GC_locker::is_active() outside a safepoint. This isn't safe because the GC_locker active state (lock count) is only updated at a safepoint and only remains valid as long as _needs_gc is true. However, outside a safepoint_needs_gc can change to false at any time, which makes it impossible to do a correct call to is_active() in that context. In this case these calls can just be removed since the input argument to basic_add() should never be on the heap and so there's no need to check the GC_locker state. This change also adjusts the assert() in is_active() to makes sure all calls to this function are always done under a safepoint. Reviewed-by: brutisso, dcubed Contributed-by: per.liden at oracle.com ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp Changeset: 9361de86a50f Author: stefank Date: 2013-09-20 11:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9361de86a50f 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize Reviewed-by: coleenp, brutisso, mgerdin, jmasa ! src/share/vm/memory/metaspace.cpp Changeset: b960c9df4f11 Author: stefank Date: 2013-09-21 10:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b960c9df4f11 8025096: Move the ChunkManager instances out of the VirtualSpaceLists Reviewed-by: coleenp, mgerdin, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 10cc3b624f8f Author: tschatzl Date: 2013-09-24 10:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/10cc3b624f8f Merge - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar Changeset: a19bea467577 Author: tschatzl Date: 2013-09-25 13:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a19bea467577 7163191: G1: introduce a "heap spanning table" abstraction Summary: Add G1BiasedArray that is an array where each element represents a fixed-sized subdivision of the heap. Use this abstraction to refactor the HeapRegionSeq class. Reviewed-by: brutisso ! make/excludeSrc.make + src/share/vm/gc_implementation/g1/g1BiasedArray.cpp + src/share/vm/gc_implementation/g1/g1BiasedArray.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/prims/jni.cpp Changeset: 03f493ce3a71 Author: brutisso Date: 2013-09-25 17:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/03f493ce3a71 8025228: assert(new_entry->reserved_words() == vs_word_size) fails in nightly Reviewed-by: mgerdin, tschatzl, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/prims/jni.cpp Changeset: 461159cd7a91 Author: tschatzl Date: 2013-09-26 12:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/461159cd7a91 Merge ! src/share/vm/classfile/symbolTable.cpp Changeset: 3da9fad1391e Author: tschatzl Date: 2013-09-26 06:34 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3da9fad1391e Merge Changeset: 58043478c26d Author: amurillo Date: 2013-09-26 13:33 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/58043478c26d Merge Changeset: 6209b0ed51c0 Author: amurillo Date: 2013-09-26 13:33 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6209b0ed51c0 Added tag hs25-b52 for changeset 58043478c26d ! .hgtags Changeset: ebfa5793d349 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ebfa5793d349 Added tag jdk8-b110 for changeset 6209b0ed51c0 ! .hgtags Changeset: 24250c363d7f Author: amurillo Date: 2013-09-26 13:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/24250c363d7f 8025536: new hotspot build - hs25-b53 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 899ecf76b570 Author: dsimms Date: 2013-09-25 13:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/899ecf76b570 8023956: Provide a work-around to broken Linux 32 bit "Exec Shield" using CS for NX emulation (crashing with SI_KERNEL) Summary: Execute some code at a high virtual address value, and keep mapped Reviewed-by: coleenp, zgu ! src/os/linux/vm/os_linux.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp Changeset: 5b1191bf0b4b Author: ctornqvi Date: 2013-09-25 17:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5b1191bf0b4b 8024677: [TESTBUG] Move tests for classes in /testlibrary Summary: Moved the tests to /testlibrary_tests and updated TEST.groups Reviewed-by: dholmes, sla ! test/TEST.groups - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java + test/testlibrary_tests/AssertsTest.java + test/testlibrary_tests/OutputAnalyzerReportingTest.java + test/testlibrary_tests/OutputAnalyzerTest.java Changeset: c1fbf21c7397 Author: ctornqvi Date: 2013-09-25 17:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c1fbf21c7397 8024492: [TESTBUG] Test library class Platform.java needs to include methods for missing OS's and architectures Summary: Added methods for 32bit, arm, ppc, x64 and x86 Reviewed-by: zgu, hseigel, mseledtsov ! test/testlibrary/com/oracle/java/testlibrary/Platform.java Changeset: 190899198332 Author: hseigel Date: 2013-09-26 10:25 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/190899198332 7195622: CheckUnhandledOops has limited usefulness now Summary: Enable CHECK_UNHANDLED_OOPS in fastdebug builds across all supported platforms. Reviewed-by: coleenp, hseigel, dholmes, stefank, twisti, ihse, rdurbin Contributed-by: lois.foltan at oracle.com ! make/bsd/makefiles/fastdebug.make ! make/linux/makefiles/fastdebug.make ! make/windows/makefiles/fastdebug.make ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parOopClosures.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: a5ac0873476c Author: zgu Date: 2013-09-27 10:08 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/a5ac0873476c Merge ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 36b97be47bde Author: acorn Date: 2013-10-01 08:10 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/36b97be47bde 8011311: Private interface methods. Default conflicts:ICCE. no erased_super_default. Reviewed-by: coleenp, bharadwaj, minqi ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/defaultMethods.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klassVtable.cpp Changeset: de059a14e159 Author: zgu Date: 2013-10-01 08:54 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/de059a14e159 8022187: Missing ResourceMark crash when assertion using FormatBufferResource fails Summary: Uses stack for the format buffer instead of resource memory Reviewed-by: kvn, coleenp ! src/share/vm/utilities/array.hpp Changeset: 90b27e931639 Author: zgu Date: 2013-10-01 09:21 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/90b27e931639 Merge Changeset: 31f0118ea584 Author: zgu Date: 2013-10-01 11:06 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/31f0118ea584 Merge Changeset: 72b7e96c1922 Author: twisti Date: 2013-09-26 12:07 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/72b7e96c1922 8024545: make develop and notproduct flag values available in product builds Reviewed-by: dholmes, kvn ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/dtraceAttacher.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/memoryService.cpp Changeset: c9ccd7b85f20 Author: rbackman Date: 2013-09-27 08:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c9ccd7b85f20 8024924: Intrinsify java.lang.Math.addExact Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/classes.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp + src/share/vm/opto/mathexactnode.cpp + src/share/vm/opto/mathexactnode.hpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/subnode.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/intrinsics/mathexact/CondTest.java + test/compiler/intrinsics/mathexact/ConstantTest.java + test/compiler/intrinsics/mathexact/LoadTest.java + test/compiler/intrinsics/mathexact/LoopDependentTest.java + test/compiler/intrinsics/mathexact/NonConstantTest.java + test/compiler/intrinsics/mathexact/Verify.java Changeset: 510fbd28919c Author: anoll Date: 2013-09-27 10:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/510fbd28919c 8020151: PSR:PERF Large performance regressions when code cache is filled Summary: Code cache sweeping based on method hotness; removed speculatively disconnect Reviewed-by: kvn, iveresov ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/trace/trace.xml Changeset: a07c25e4f67e Author: adlertz Date: 2013-09-27 12:43 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a07c25e4f67e Merge ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/services/attachListener.cpp Changeset: 1c3486050433 Author: adlertz Date: 2013-09-27 15:43 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1c3486050433 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: e8e077292da3 Author: iignatyev Date: 2013-09-28 12:32 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/e8e077292da3 8024678: Java source files in hotspot/test/testlibrary should not use @author tag in JavaDoc Reviewed-by: twisti ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathDirEntry.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathJarEntry.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathJarInDirEntry.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassesListInFile.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/CompileTheWorld.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Compiler.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/PathHandler.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Utils.java Changeset: 303826f477c6 Author: iignatyev Date: 2013-09-28 12:32 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/303826f477c6 8023452: TestCase$Helper(java.lang.Object) must be osr_compiled Reviewed-by: kvn ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java Changeset: f2512d89ad0c Author: twisti Date: 2013-09-28 12:42 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f2512d89ad0c 8025613: clang: remove -Wno-unused-value Reviewed-by: iveresov ! agent/src/os/linux/LinuxDebuggerLocal.c ! agent/src/os/linux/ps_proc.c ! agent/src/os/linux/salibelf.c ! agent/src/os/linux/symtab.c ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/classfile/defaultMethods.cpp Changeset: 29bdcf12457c Author: shade Date: 2013-09-27 11:52 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/29bdcf12457c 8014447: Object.hashCode intrinsic breaks inline caches Summary: Try to inline as normal method first, then fall back to intrinsic. Reviewed-by: kvn, twisti ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/library_call.cpp Changeset: d8d059e90ec1 Author: twisti Date: 2013-09-30 15:42 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d8d059e90ec1 8025599: Missing store barrier with OptimizeStringConcat Reviewed-by: kvn, twisti Contributed-by: Axel Siebenborn ! src/share/vm/opto/graphKit.cpp Changeset: dc261f466b6d Author: drchase Date: 2013-09-27 13:36 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/dc261f466b6d 8025260: Methodhandles/JSR292: NullPointerException (NPE) thrown instead of AbstractMethodError (AME) Summary: Copied null-checks from templateInterpreter_CPU into methodHandles_CPU Reviewed-by: jrose, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.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 Changeset: cacc4c6bfc80 Author: vlivanov Date: 2013-10-02 06:17 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/cacc4c6bfc80 8025233: Move sun.invoke.Stable into java.lang.invoke package Reviewed-by: twisti, iveresov ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.hpp Changeset: 268e7a2178d7 Author: iveresov Date: 2013-10-03 16:38 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/268e7a2178d7 Merge ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/services/classLoadingService.cpp Changeset: d68894a09c7c Author: jiangli Date: 2013-09-27 13:49 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/d68894a09c7c 8024990: JT_JDK: 11 failures with SIGSEGV on arm-sflt platforms in nightly fastdebug build. Summary: Enable patching for load_appendix_id. Reviewed-by: kvn, dlong, bdelsart ! src/share/vm/c1/c1_Runtime1.cpp Changeset: 5186dcaca431 Author: jiangli Date: 2013-09-27 13:53 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/5186dcaca431 Merge ! src/share/vm/c1/c1_Runtime1.cpp - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar Changeset: d0cfa6502dfe Author: jprovino Date: 2013-10-03 10:25 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/d0cfa6502dfe Merge ! src/share/vm/c1/c1_Runtime1.cpp Changeset: 100614790c1e Author: vladidan Date: 2013-10-03 10:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/100614790c1e Merge Changeset: c319b188c7b2 Author: tschatzl Date: 2013-09-26 12:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c319b188c7b2 8014078: G1: improve remembered set summary information by providing per region type information Summary: Add memory consumption breakdown on a per region type in the G1 remembered set summary statistics. This simplifies remembered set memory consumption analysis. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! test/gc/g1/TestSummarizeRSetStats.java + test/gc/g1/TestSummarizeRSetStatsPerRegion.java + test/gc/g1/TestSummarizeRSetStatsTools.java Changeset: bc918fd1e584 Author: mgerdin Date: 2013-09-27 10:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bc918fd1e584 8025279: metaspace/flags/maxMetaspaceSize throws OOM: out of Compressed Klass space Summary: Only put "Compressed class space" as OOM cause if actually using Compressed class space Reviewed-by: jwilhelm, stefank, ehelin, coleenp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 4fa18058548e Author: tschatzl Date: 2013-09-27 11:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4fa18058548e Merge Changeset: ccef6e165e8b Author: tschatzl Date: 2013-09-27 13:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ccef6e165e8b Merge Changeset: d55c004e1d4d Author: mgerdin Date: 2013-09-24 14:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d55c004e1d4d 8025305: Cleanup CardTableModRefBS usage in G1 Summary: Move some G1 specific code from CardTableModRefBS to G1SATBCardTableModRefBS. Reviewed-by: brutisso, tschatzl, ehelin ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp Changeset: 7ec10139bf37 Author: tschatzl Date: 2013-09-30 12:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7ec10139bf37 8025441: G1: assert "assert(thread < _num_vtimes) failed: just checking" fails when G1ConcRefinementThreads > ParallelGCThreads Summary: The initialization for the remembered set summary data structures used the wrong thread count, i.e. number of worker threads instead of number of refinement threads. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.hpp + test/gc/g1/TestSummarizeRSetStatsThreads.java Changeset: 9de9169ddde6 Author: brutisso Date: 2013-10-01 07:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9de9169ddde6 8025605: G1: Heap expansion logging misleading for fully expanded heap Reviewed-by: tschatzl, jwilhelm, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 9ecd6d3782b1 Author: ehelin Date: 2013-10-01 15:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9ecd6d3782b1 8025313: MetaspaceMemoryPool incorrectly reports undefined size for max Reviewed-by: stefank, tschatzl ! src/share/vm/memory/collectorPolicy.cpp Changeset: 77a774ab3cf0 Author: mgerdin Date: 2013-10-02 14:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/77a774ab3cf0 8012525: gc/metaspace/G1AddMetaspaceDependency.java Test fails a safepoint timeout assertion or hangs. Reviewed-by: brutisso, tschatzl ! test/gc/metaspace/G1AddMetaspaceDependency.java Changeset: 6e22e7042433 Author: ehelin Date: 2013-09-30 11:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6e22e7042433 8025226: TestPerfCountersAndMemoryPools.java fails with -Xmixed or -Xcomp Reviewed-by: brutisso, mgerdin ! test/gc/metaspace/TestPerfCountersAndMemoryPools.java Changeset: 379ef2cc19c0 Author: ehelin Date: 2013-10-02 18:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/379ef2cc19c0 Merge Changeset: ab68fc0101ce Author: jwilhelm Date: 2013-10-03 13:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ab68fc0101ce 8025855: Simplify GenRemSet code slightly Summary: Remove a few redundant switch-statements Reviewed-by: jcoomes, tschatzl ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/genRemSet.cpp Changeset: c49c7f835e8d Author: jwilhelm Date: 2013-10-03 17:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c49c7f835e8d 8025853: Remove unnecessary uses of GenerationSizer Summary: Removed stray includes and some minor cleanup of GenerationSizer Reviewed-by: tschatzl, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp Changeset: 798522662fcd Author: jcoomes Date: 2013-10-04 13:37 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/798522662fcd Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp Changeset: 562a3d356de6 Author: amurillo Date: 2013-10-04 14:10 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/562a3d356de6 Merge - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java Changeset: f6962730bbde Author: amurillo Date: 2013-10-04 14:10 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f6962730bbde Added tag hs25-b53 for changeset 562a3d356de6 ! .hgtags Changeset: cefad50507d8 Author: Gilles Duboscq Date: 2013-10-11 10:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cefad50507d8 Merge with hs25-b53 ! .hgtags ! make/hotspot_version ! make/linux/makefiles/jsig.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/vm.make ! make/windows/build_vm_def.sh ! make/windows/create.bat ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86.hpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/defaultMethods.cpp - src/share/vm/classfile/genericSignatures.cpp - src/share/vm/classfile/genericSignatures.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/vmError.cpp - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar - test/runtime/7051189/Xchecksig.sh - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java Changeset: 359f7e70ae7f Author: Gilles Duboscq Date: 2013-10-11 15:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/359f7e70ae7f Reduce HotSpot diff and fix previous merge ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! make/defs.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/vm.make ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/compiledIC_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/graal/graalCompiler.hpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/interpreter/invocationCounter.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodCounters.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiLib.xsl ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 36b1f3224948 Author: Gilles Duboscq Date: 2013-10-11 17:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/36b1f3224948 Revert changes to globalDefinitions (needs more work) and disable CHECK_UNHANDLED_OOPS in fastdebug until it's fixed upstream ! make/bsd/makefiles/fastdebug.make ! make/linux/makefiles/fastdebug.make ! make/solaris/makefiles/fastdebug.make ! make/windows/makefiles/fastdebug.make ! src/share/vm/utilities/globalDefinitions.hpp Changeset: c2407e223244 Author: Gilles Duboscq Date: 2013-10-11 17:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c2407e223244 Merge - graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/DelegatingCodeCacheProvider.java - graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/DelegatingMetaAccessProvider.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/DelegatingGraalCodeCacheProvider.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/GraalCodeCacheProvider.java Changeset: e800bf0c230c Author: Bernhard Urban Date: 2013-10-11 19:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e800bf0c230c gate: temporarily disable G1 verification until merge issues are resolved ! mx/commands.py Changeset: cfba4fd3d616 Author: Doug Simon Date: 2013-10-11 21:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cfba4fd3d616 fixed C compilation warnings on MacOS ! src/gpu/ptx/vm/ptxKernelArguments.cpp Changeset: ec57cc36371e Author: Doug Simon Date: 2013-10-11 21:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ec57cc36371e introduced @InjectedNodeParameter annotation to make injection of arguments during node intrinsification more extensible ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewMultiArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/StubForeignCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java Changeset: f53dc8bbb88c Author: Doug Simon Date: 2013-10-12 00:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f53dc8bbb88c refactored isReexecutable(), getKilledLocations() and canDeoptimize() out of MetaAccessProvider into ForeignCallsProvider (GRAAL-511) + graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ForeignCallsProvider.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaAccessProvider.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/ForEachToGraal.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILCompilationResult.java ! 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/FinalizableSubclassTest.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/ea/EscapeAnalysisTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.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/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReplacementsImpl.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/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewMultiArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/StubForeignCallNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/LoadExceptionObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.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.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/VerifyOptionsPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.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/LoweringPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/PhaseContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/util/Providers.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/ObjectAccessTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/PointerTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/WordTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.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 ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.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 ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleReplacements.java Changeset: 78e5badf4b8e Author: Doug Simon Date: 2013-10-12 01:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/78e5badf4b8e moved lookupForeignCall() from CodeCacheProvider to ForeignCallsProvider (GRAAL-511) ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CodeCacheProvider.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ForeignCallsProvider.java < graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ForeignCallsProvider.java ! 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/HSAILBackend.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILCompilationResult.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! 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/PTXBackend.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXTargetMethodAssembler.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.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/AMD64HotSpotDeoptimizeCallerOp.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/AMD64HotSpotUnwindOp.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/SPARCHotSpotDeoptimizeCallerOp.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/SPARCHotSpotUnwindOp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorExitStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewInstanceStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewMultiArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/StubForeignCallNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VMErrorNode.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/VerifyOptionsPhase.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/TargetMethodAssembler.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/RegisterFinalizerNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LIRGeneratorTool.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java Changeset: 651cc32247d7 Author: Christos Kotselidis Date: 2013-10-11 17:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/651cc32247d7 Add Graal option for deferring write barriers of eden allocated objects ! src/share/vm/graal/graalGlobals.hpp Changeset: ee746f35ae17 Author: Christos Kotselidis Date: 2013-10-11 17:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ee746f35ae17 Delegate deferred barrier arguments to graal ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java Changeset: 0991c12c4186 Author: Christos Kotselidis Date: 2013-10-11 17:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0991c12c4186 Defer barriers upon slow-path allocation ! src/share/vm/graal/graalRuntime.cpp Changeset: c4af81d4fcc3 Author: Christos Kotselidis Date: 2013-10-11 17:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c4af81d4fcc3 Customize deferred barrier flags fro Graal ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: a2866cf1c9af Author: Christos Kotselidis Date: 2013-10-11 17:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a2866cf1c9af Do not add write barriers to newly allocated objects ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 380ef624593c Author: Christos Kotselidis Date: 2013-10-11 17:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/380ef624593c Augment WriteBarrier Verification phase error reporting ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierVerificationPhase.java Changeset: 1e4d1c150ed5 Author: Christos Kotselidis Date: 2013-10-11 17:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1e4d1c150ed5 Augment unit tests to account for deferred init barriers ! 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 Changeset: e32f2b195867 Author: Christos Kotselidis Date: 2013-10-11 17:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e32f2b195867 Merge - graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/DelegatingCodeCacheProvider.java - graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/DeoptimizationAction.java - graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/DelegatingMetaAccessProvider.java - graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MemoryMap.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/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/VerifyHotSpotOptionsPhase.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryState.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/debug/SurvivingCounterNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/Canonicalizable.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/CanonicalizerTool.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/DelegatingGraalCodeCacheProvider.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/GraalCodeCacheProvider.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/Simplifiable.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/SimplifierTool.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/PhiStampPhase.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomTypeCheckMacroNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomTypeCheckNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/TypeCastMacroNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/TypeCastNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/UnsafeCustomizationMacroNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/UnsafeCustomizationNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/phases/ReplaceLoadFinalPhase.java - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad - test/runtime/7196045/Test7196045.java - test/runtime/8000968/Test8000968.sh Changeset: 2dfccd93510a Author: Christos Kotselidis Date: 2013-10-11 21:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2dfccd93510a Merge ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java - src/share/vm/classfile/genericSignatures.cpp - src/share/vm/classfile/genericSignatures.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/graal/graalRuntime.cpp - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar - test/runtime/7051189/Xchecksig.sh - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java Changeset: 10b7986aa452 Author: Christos Kotselidis Date: 2013-10-11 22:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/10b7986aa452 Merge Changeset: ae1bc462075c Author: Christos Kotselidis Date: 2013-10-11 23:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ae1bc462075c Merge Changeset: 819c0394c6e3 Author: Christos Kotselidis Date: 2013-10-12 00:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/819c0394c6e3 Fix warning ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: 7b1f522884ee Author: Christos Kotselidis Date: 2013-10-12 01:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7b1f522884ee Merge ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 5fc50ffe4e65 Author: Christos Kotselidis Date: 2013-10-12 02:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5fc50ffe4e65 Merge - graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ForeignCallsProvider.java Changeset: 1e76b14e1b3a Author: Bernhard Urban Date: 2013-10-12 10:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1e76b14e1b3a NodeClassIterator: remove reference to NodeClass there's already an implicit one in the subclasses as they're inner classes ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: edb2e6bd6a01 Author: Andreas Woess Date: 2013-10-12 20:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/edb2e6bd6a01 fix hosted mode on windows after hotspot merge. ! make/windows/makefiles/projectcreator.make From Vasanth.Venkatachalam at amd.com Wed Oct 16 08:38:23 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Wed, 16 Oct 2013 15:38:23 +0000 Subject: enhancements we'd like to see out of the graal redesign Message-ID: <5DD1503F815BD14889DC81D28643E3A7553A49BE@SATLEXDAG02.amd.com> Hi Doug, You mentioned that Graal is being redesigned to support multiple GPU targets. I'd like to participate in the redesign discussion if possible. As you suggested, I've made an initial list of things we'd like to see come out of this redesign. I know we talked about some of this already. 1. We'd like to see a clear separation between the host runtime and the runtime of the target that we're generating code for, and the ability for the target runtime (or backend) to reuse data structures from the host if needed. Currently, AMD64HotSpotRuntime is being treated as the host and target runtime when we are generating code for HSAIL. This puts the execution in an inconsistent state where HSAIL registers are being used, but the target runtime is still being treated as AMD64. When generating code for a target other than the host runtime, the only place where we should have to rely on the host runtime is when we are reusing data structures defined in the host runtime. 2. Related to 1), we need the ability to specify in a central location what the target runtime is (e.g., HSAIL) and have this change be automatically percolated to all parts of the code that are referring to the target runtime. 3. As a result of the problem mentioned in 1), we're seeing errors and exceptions when we run HSAIL test cases. Two examples below. a. CFGPrinterObserver line 146 looks up the runtime to be AMD64HotSpotRuntime, and as a result CompilationPrinter.debugInfoToString (line 124) gets an ArrayIndexOutOfBoundsException when it tries to lookup an HSAIL register number in an array of AMD64 registers (which has fewer registers than HSAIL). This is causing test cases that exercise a lot of HSAIL registers to fail when we run them with flags to dump a data file for the C1visualizer. b. The other example is that test cases involving method calls are causing some exception handling snippets to be invoked. The AMD64 definition of these snippets gets loaded and looks for a threadregister (which we haven't specified in HSAIL) and this leads to an assertion error. As mentioned earlier, we would like the ability to fix all such problems by making changes to a central location, as opposed to having to code around them in several places. For example, you mentioned one possible solution would be the ability to pass in an HSAIL specific CodeCacheProvider to GraalCompiler.compileGraph(), which in turn causes the right target runtime to be percolated to all of these code regions.. We'd like the redesign to make such a centralized solution possible. 4. Currently, Graal is building up a superset of intrinsics for the host runtime (x86) and allowing the different backends to filter off of that list. For the case of supporting GPU targets, we'd like a way for each backend to define its own intrinsics that may not be part of the x86 intrinsics. 5. We need to be able to declare our own snippets without affecting the AMD64 snippets. a. Similarly our own Replacements 6. We may have a need to define our own new nodes in the HSAIL backend, for example used by our own snippets. It would be preferable if we can do this in a way without having to define NYI node handlers for that node in all the other backends. 7. Since there are multiple GPU targets (.e.g, HSAIL, PTX), we need to make sure the infrastructure supports multiple ISA targets, not just one. Vasanth -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Tuesday, October 08, 2013 1:08 PM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net; dl.Runtimes Subject: Re: handling of Math intrinsics for multiple GPU targets This is obviously something else that needs to be vectored to each backend, allowing each to make their own decision as you say. It will be factored into the redesign currently going on. Please let us know of other abstractions like this that need to be broadened or exposed to each backend. On Oct 8, 2013, at 6:11 PM, "Venkatachalam, Vasanth" > wrote: > Hi, > > I noticed that Graal is building a superset of math intrinsics for the host runtime (x86) and then filtering out some of these methods from being intrinsified based on the value of a config parameter (e.g., config.usePopCountIinstruction, config.useAESIntrinsics, etc.). > > In more detail when the VM first starts up in VMToCompilerImpl.start() it gets the host runtime (which is x86) and builds a superset of intrinsics for that runtime by calling GraalMethodSubstitutions.registerReplacements( ). This in turn processes a class file MathSubstitutionsx86.class to get a list of math routines to be intrinsified, filters out some of these routines (via a call to HotSpotReplacementsImpl.registerMethodSubstitution()) and adds the remaining ones to a HashMap called registeredMethodSubstitutions. > > For the case of supporting multiple GPU targets, it sounds like this logic is the reverse of what we need. Instead of building a superset of intrinsics for x86 and filtering them for the target runtime, we need a way for each target runtime (e.g., HSAIL) to specify its own list of supported intrinsics. Has anyone thought about how this should be handled? > > Vasanth > From doug.simon at oracle.com Wed Oct 16 08:54:49 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 16 Oct 2013 15:54:49 +0000 Subject: hg: graal/graal: 72 new changesets Message-ID: <20131016155936.E577162468@hg.openjdk.java.net> Changeset: e027a51bdd33 Author: Lukas Stadler Date: 2013-10-14 10:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e027a51bdd33 exclude java.lang.ref.Reference from Escape Analysis ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PartialEscapeAnalysisTest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewInstanceNode.java Changeset: 20150eaa1dc7 Author: Lukas Stadler Date: 2013-10-14 13:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/20150eaa1dc7 remove unused parameters from doProfile methods ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java Changeset: ce5e6f9075b6 Author: Gilles Duboscq Date: 2013-10-14 13:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ce5e6f9075b6 Replace some wrong GRAAL_ONLY with GRAALVM_ONLY ! src/share/vm/compiler/oopMap.cpp Changeset: 1d2d7924033a Author: Gilles Duboscq Date: 2013-10-14 15:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1d2d7924033a Remove reduduant guards stage check in GuardingPiNode.lower ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java Changeset: 28d80a9260cd Author: Gilles Duboscq Date: 2013-10-14 16:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/28d80a9260cd During CheckCast lowering, if null was never seen and a guard is created for the null case, the instanceof should be done on a non-null value. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java Changeset: 2391d44f9d2c Author: Christian Humer Date: 2013-09-06 17:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2391d44f9d2c Truffle-DSL: fixed a if bug target parameters and executes accidently do not match. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: 91dbb0b7dc8b Author: Christian Humer Date: 2013-09-06 21:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/91dbb0b7dc8b Merge. Changeset: aff825fef0fd Author: Christian Humer Date: 2013-10-02 13:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/aff825fef0fd Merge. - graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/DeoptimizationAction.java - graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ArrayTest.java - graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ControlTest.java - graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64SafepointOp.java - graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCSafepointOp.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ArrayRangeWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1ArrayRangePostWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1ArrayRangePreWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1PostWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1PreWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/G1ReferentFieldReadBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/SerialArrayRangeWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/SerialWriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ShortCircuitAndNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ShortCircuitBooleanNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/WriteBarrier.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AbstractCallNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeArrayCastNode.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InsertStateAfterPlaceholderPhase.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/SafepointInsertionPhase.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/phases/InlineTrivialGettersPhase.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/SlowPathExceptionSubstitutions.java - mx/.pylintrc - src/gpu/ptx/vm/kernelArguments.cpp - src/gpu/ptx/vm/kernelArguments.hpp Changeset: 96c1d057a5ed Author: Christian Humer Date: 2013-10-02 15:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/96c1d057a5ed Truffle: Added experimental serialization API. + graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/nodes/serial/PostOrderDeserializerTest.java + graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/nodes/serial/PostOrderSerializerTest.java + graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/nodes/serial/TestNodes.java + graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/nodes/serial/TestSerializerConstantPool.java + graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/nodes/serial/VariableLengthIntBufferTest.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/serial/PostOrderDeserializer.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/serial/PostOrderSerializer.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/serial/SerializerConstantPool.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/serial/UnsupportedConstantPoolTypeException.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/serial/VariableLengthIntBuffer.java Changeset: 9d1a5d61cc11 Author: Christian Humer Date: 2013-10-02 15:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9d1a5d61cc11 Merge. Changeset: 5151a7588384 Author: Christian Humer Date: 2013-10-02 15:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5151a7588384 SL: fixed literals generate unnecessary code. ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/NodeFactory.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/BigIntegerLiteralNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/IntegerLiteralNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/StringLiteralNode.java Changeset: 7aa2a8c69ba3 Author: Christian Humer Date: 2013-10-03 16:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7aa2a8c69ba3 TruffleDSL: improved code generation layout for implicit casts. ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/ImplicitCastTest.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: 4e26955b6da2 Author: Christian Humer Date: 2013-10-03 18:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4e26955b6da2 Truffle-DSL: new implicit cast code generation layout supports now executeWith. ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/ImplicitCastTest.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: 7cce548b0b60 Author: Christian Humer Date: 2013-10-03 18:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7cce548b0b60 Truffle-DSL: fixed minor issue in implicit cast tests. ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/ImplicitCastTest.java Changeset: df3af5e007ad Author: Christian Humer Date: 2013-10-09 15:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/df3af5e007ad Merge. - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/debug/SurvivingCounterNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/Canonicalizable.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/CanonicalizerTool.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/Simplifiable.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/SimplifierTool.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/PhiStampPhase.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomTypeCheckMacroNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomTypeCheckNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/TypeCastMacroNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/TypeCastNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/UnsafeCustomizationMacroNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/UnsafeCustomizationNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/phases/ReplaceLoadFinalPhase.java Changeset: 8e8347ecabbc Author: Christian Humer Date: 2013-10-11 20:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8e8347ecabbc Truffle-DSL: implemented new polymorphic more compact generation strategy ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/ImplicitCastTest.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/TruffleTypes.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeElement.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/ExecutableTypeData.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/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/TemplateMethod.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/TypeSystemCodeGenerator.java Changeset: 3faec5ab0696 Author: Christian Humer Date: 2013-10-11 20:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3faec5ab0696 SL: updated simple lanugage type system to use an implicit cast. ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLTypes.java Changeset: 80963ec8134e Author: Christian Humer Date: 2013-10-11 20:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/80963ec8134e Merge. - graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/DelegatingCodeCacheProvider.java - graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/DelegatingMetaAccessProvider.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/VerifyHotSpotOptionsPhase.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/DelegatingGraalCodeCacheProvider.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/GraalCodeCacheProvider.java - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad - test/runtime/7196045/Test7196045.java - test/runtime/8000968/Test8000968.sh Changeset: c78612fb0120 Author: Christian Humer Date: 2013-10-11 20:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c78612fb0120 Truffle-DSL. fixed some issues with new generation strategy. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: 980db6c0bcd3 Author: Christian Humer Date: 2013-10-14 13:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/980db6c0bcd3 Truffle-DSL: fixed invalid @SlowPath on generic execute methods. (GRAAL-490 #resolve) + graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/SlowPathTest.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/SpecializationData.java Changeset: 28e7396dca1d Author: Christian Humer Date: 2013-10-14 14:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/28e7396dca1d Merge. - src/share/vm/classfile/genericSignatures.cpp - src/share/vm/classfile/genericSignatures.hpp - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar - test/runtime/7051189/Xchecksig.sh - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java Changeset: 85dcc7f59c34 Author: Christian Humer Date: 2013-10-14 15:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/85dcc7f59c34 Truffle-DSL: fixed incorrect else guard connections for executeAndSpecialize. ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/SpecializationGroupingTest.java ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/TestHelper.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/SpecializationGroup.java Changeset: bfcae72b61a0 Author: Christian Humer Date: 2013-10-14 15:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bfcae72b61a0 merge. Changeset: 52caeb1c19a0 Author: Christian Humer Date: 2013-10-14 18:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/52caeb1c19a0 Truffle-DSL: fixed wrong targetType for implicit casts. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: 47eb670c1634 Author: Christian Humer Date: 2013-10-14 18:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/47eb670c1634 Merge. Changeset: 139b84d713bc Author: Thomas Wuerthinger Date: 2013-10-14 23:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/139b84d713bc Truffle API adjustments: Simplify frame handling. Introduce cast for MaterializedFrame objects. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeCastNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeLoadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeStoreNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/StoreIndexedNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/nodes/StoreLocalTestNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/FrameWithoutBoxing.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameAccessNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameGetNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameSetNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/NewFrameNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/phases/VerifyFrameDoesNotEscapePhase.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/CompilerDirectivesSubstitutions.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/FrameWithoutBoxingSubstitutions.java ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/FrameSlotTypeSpecializationTest.java ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/FrameTest.java ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/ReturnTypeSpecializationTest.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerDirectives.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/Frame.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/FrameSlotImpl.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/FrameSlotKind.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/FrameUtil.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultFrameTypeConversion.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultMaterializedFrame.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultVirtualFrame.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/WriteLocalNode.java Changeset: 11e4744f1e86 Author: Thomas Wuerthinger Date: 2013-10-14 23:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/11e4744f1e86 Improve canonicalization of FixedGuardNode. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java Changeset: 53297646b011 Author: Thomas Wuerthinger Date: 2013-10-14 23:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/53297646b011 Improve convert deoptimize to guard phase to recognize FixedGuardNode following MergeNode. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConvertDeoptimizeToGuardPhase.java Changeset: a9837a03127e Author: Thomas Wuerthinger Date: 2013-10-15 00:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a9837a03127e Fix wrong modification of ReplacementsImpl macro node method handling. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/CompilerDirectivesSubstitutions.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerDirectives.java Changeset: edacadae40a0 Author: Thomas Wuerthinger Date: 2013-10-15 01:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/edacadae40a0 Make sure HotSpot installed code link is cut when code is explicitely invalidated. ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 1c4e9cb77ac6 Author: Christos Kotselidis Date: 2013-10-14 23:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1c4e9cb77ac6 Field renaming in unsafe load snippet ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeLoadSnippets.java Changeset: 738023c641c2 Author: Christos Kotselidis Date: 2013-10-14 23:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/738023c641c2 Fix in G1 GC after latest HotSpot merge ! src/share/vm/code/nmethod.cpp Changeset: 3c11430f62d8 Author: Christos Kotselidis Date: 2013-10-14 23:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3c11430f62d8 Re-enable G1 verification in gate ! mx/commands.py Changeset: 5ae8c9cf46e9 Author: Christos Kotselidis Date: 2013-10-14 23:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5ae8c9cf46e9 Merge Changeset: 98031e66de15 Author: Christos Kotselidis Date: 2013-10-15 01:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/98031e66de15 Fix unittests ! src/share/vm/code/nmethod.cpp Changeset: 083e90f11c93 Author: Christos Kotselidis Date: 2013-10-15 02:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/083e90f11c93 Merge - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameAccessNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameGetNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameSetNode.java Changeset: 9ad59f7fd57e Author: twisti Date: 2013-10-14 19:46 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9ad59f7fd57e ConstantNode methods should not throw InternalError ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConstantNode.java Changeset: 0b71e8b6418c Author: Lukas Stadler Date: 2013-10-15 11:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0b71e8b6418c preliminary fix for MonitorExitNodes with AFTER_BCI ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MonitorExitNode.java Changeset: 8c53ba3efbc9 Author: Lukas Stadler Date: 2013-10-15 11:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8c53ba3efbc9 PEA: fix up FrameStates *after* dealing with unhandled inputs ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java Changeset: 5b1a2e8e82d6 Author: Lukas Stadler Date: 2013-10-15 13:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5b1a2e8e82d6 make EscapeObjectState value numberable ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/EscapeObjectState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/nodes/MaterializedObjectState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/nodes/VirtualObjectState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/GraphEffectList.java Changeset: c1910f6400d7 Author: Matthias Grimmer Date: 2013-10-15 17:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c1910f6400d7 Remove truffle.printer ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java ! mx/projects Changeset: dc4b09c9d68e Author: Gilles Duboscq Date: 2013-10-14 17:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dc4b09c9d68e When FixedGuardNode is canonicalized away, it should not be replaced with the previous begin ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java Changeset: d837abecd503 Author: Gilles Duboscq Date: 2013-10-15 14:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d837abecd503 Merge ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java Changeset: 370b5f07f9e2 Author: Gilles Duboscq Date: 2013-10-15 14:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/370b5f07f9e2 The runtime entries need to use oopDesc* rather than oop in their signature ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: 737151a29a1f Author: Gilles Duboscq Date: 2013-10-15 14:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/737151a29a1f Fix intptr_t to oop casts in vframeArray.cpp and re-enable CHECK_UNHANDLED_OOPS in fastdebug mode ! make/bsd/makefiles/fastdebug.make ! make/linux/makefiles/fastdebug.make ! make/solaris/makefiles/fastdebug.make ! make/windows/makefiles/fastdebug.make ! src/share/vm/runtime/vframeArray.cpp Changeset: f9d27a88bbda Author: Doug Simon Date: 2013-10-14 11:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f9d27a88bbda narrowed TargetDescription dependency of ReplacementsImpl to word kind ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReplacementsImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/ObjectAccessTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/PointerTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/WordTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleReplacements.java Changeset: 492c428f6035 Author: Doug Simon Date: 2013-10-14 11:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/492c428f6035 made use of substitution when deriving a new Providers object ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java Changeset: 13ae3f7017b5 Author: Doug Simon Date: 2013-10-15 21:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/13ae3f7017b5 Merge. ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameAccessNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameGetNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameSetNode.java Changeset: 15141192206d Author: Doug Simon Date: 2013-10-15 21:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/15141192206d Backed out changeset: 5b1a2e8e82d6 ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/EscapeObjectState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/nodes/MaterializedObjectState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/nodes/VirtualObjectState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/GraphEffectList.java Changeset: 5124eeec1a7b Author: Doug Simon Date: 2013-10-15 14:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5124eeec1a7b split HotSpotRuntime into separate provider implementations moved HotSpot specific parts of HSAIL into new com.oracle.graal.hotspot.hsail project ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/BytecodeDisassemblerProvider.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/GraalKernelTester.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BasicHSAILTest.java - graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/ForEachToGraal.java - graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILBackend.java - graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILCompilationResult.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! 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/PTXBackend.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXTargetMethodAssembler.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.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/gen/LIRGenerator.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.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/AMD64HotSpotCodeCacheProvider.java + graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotForeignCallsProvider.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotGraalRuntime.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/AMD64HotSpotLIRGenerator.java + graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLoweringProvider.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/AMD64HotSpotReturnOp.java - graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java + graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/ForEachToGraal.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.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotCodeCacheProvider.java + graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotGraalRuntime.java + graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java + graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java + graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotCodeCacheProvider.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotGraalRuntime.java + graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotLoweringProvider.java - graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotRuntime.java + graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/AMD64SPARCForeignCallsProvider.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/SPARCHotSpotGraalRuntime.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/SPARCHotSpotLIRGenerator.java + graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLoweringProvider.java - graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRuntime.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/CompileTheWorld.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotForeignCallLinkage.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReplacementsImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotRuntimeInterpreterInterface.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/BenchmarkCounters.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotCodeCacheProvider.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotConstantReflectionProvider.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotDisassemblerProvider.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotForeignCallsProvider.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotLoweringProvider.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/HotSpotMethodData.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotProviders.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRegisters.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/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/HotSpotRuntime.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotSuitesProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CurrentJavaThreadNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/LoadJavaMirrorWithKlassPhase.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/InstanceOfSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/LoadExceptionObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/SnippetStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/UnwindExceptionToCallerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VerifyOopStub.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeDisassembler.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64FrameMap.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILFrameMap.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXFrameMap.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCFrameMap.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/FrameMap.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/TargetMethodAssembler.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadFieldNode.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/ObjectAccessTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/PointerTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/WordTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleReplacements.java ! mx/projects Changeset: c0e660b07e02 Author: Doug Simon Date: 2013-10-15 22:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c0e660b07e02 introduced HotSpotRegistersProvider interface ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotCRuntimeCallPrologueOp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/debug/BenchmarkCounters.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotProviders.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRegisters.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRegistersProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/LoadExceptionObjectSnippets.java Changeset: 7080a96be216 Author: Doug Simon Date: 2013-10-15 22:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7080a96be216 rename: graalRuntime -> runtime, getGraalRuntime -> getRuntime ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXTargetMethodAssembler.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/AMD64HotSpotCodeCacheProvider.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotForeignCallsProvider.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotGraalRuntime.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/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLoweringProvider.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/AMD64HotspotDirectStaticCallOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotspotDirectVirtualCallOp.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/ForEachToGraal.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.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotCodeCacheProvider.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotCodeCacheProvider.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/AMD64SPARCForeignCallsProvider.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/SPARCHotSpotGraalRuntime.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/SPARCHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLoweringProvider.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/SPARCHotspotDirectStaticCallOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotspotDirectVirtualCallOp.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotCryptoSubstitutionTest.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/CompileTheWorld.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilerThread.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotForeignCallLinkage.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 ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/debug/LocalImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotCodeCacheProvider.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/HotSpotConstantReflectionProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotDisassemblerProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotForeignCallsProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotLoweringProvider.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/HotSpotMethodData.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotNmethod.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/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 ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotSignature.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotSuitesProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotUnresolvedJavaType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CurrentJavaThreadNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/TailcallNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CRC32Substitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/InstanceOfSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopySnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/StubUtil.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: 90494fdf11c8 Author: Doug Simon Date: 2013-10-15 23:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/90494fdf11c8 Merge. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReplacementsImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/ObjectAccessTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/PointerTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/WordTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleReplacements.java ! mx/projects Changeset: 808348377021 Author: Christos Kotselidis Date: 2013-10-16 01:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/808348377021 Fix inconsistent oops in slow path allocation ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: 90f3c090a002 Author: Christos Kotselidis Date: 2013-10-16 01:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/90f3c090a002 Enable Deferred Init Barriers ! src/share/vm/graal/graalGlobals.hpp Changeset: 43e004461248 Author: Christos Kotselidis Date: 2013-10-16 01:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/43e004461248 Merge - graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/ForEachToGraal.java - graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILBackend.java - graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILCompilationResult.java - graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java - graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotRuntime.java - graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: 39308acea2f7 Author: twisti Date: 2013-10-15 18:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/39308acea2f7 revert Unsafe.getObject hack to read uncompressed pointers ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotMethodSubstitutionTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/Word.java ! src/share/vm/prims/unsafe.cpp Changeset: c991f8291f1b Author: twisti Date: 2013-10-15 22:38 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c991f8291f1b add missing @Override to Iterator.remove overrides ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java Changeset: 27a67adaf4f7 Author: Doug Simon Date: 2013-10-15 23:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/27a67adaf4f7 added LoweringProvider to ReplacementsProvider.registerReplacements ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CallSiteSubstitutions.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/ReplacementsProvider.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/GraalMethodSubstitutions.java Changeset: 6adc06f18b80 Author: Doug Simon Date: 2013-10-16 12:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6adc06f18b80 increased AMD64 template interpreter size in GRAALVM to allow the VM to be debugged with a Java debugger ! src/cpu/x86/vm/templateInterpreter_x86.hpp Changeset: b3490a7bb1b7 Author: Doug Simon Date: 2013-10-16 13:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b3490a7bb1b7 fixed name of SPARC class - graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/AMD64SPARCForeignCallsProvider.java + graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotForeignCallsProvider.java Changeset: 3de38bb7bc1d Author: Doug Simon Date: 2013-10-16 14:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3de38bb7bc1d attempt to fix Eclipse build loop issue ! mxtool/mx.py Changeset: bef1738b58d9 Author: Doug Simon Date: 2013-10-16 14:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bef1738b58d9 increased generated interpreter size to accomodate Windows ! src/cpu/x86/vm/templateInterpreter_x86.hpp Changeset: 7421885a2b9d Author: Thomas Wuerthinger Date: 2013-10-15 01:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7421885a2b9d Add LoweringProvider parameter to registerReplacements method. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CallSiteSubstitutions.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/ReplacementsProvider.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/GraalMethodSubstitutions.java Changeset: b6e3b44ab44f Author: Thomas Wuerthinger Date: 2013-10-15 13:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b6e3b44ab44f Merge. Changeset: 66efe95dd46b Author: Thomas Wuerthinger Date: 2013-10-16 03:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/66efe95dd46b Make sure constants have the correct stack kind and unsafe accesses the correct access kind. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConstantNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeLoadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeStoreNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/NewFrameNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomizedUnsafeLoadMacroNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/typesystem/CustomizedUnsafeStoreMacroNode.java Changeset: 4811a78ced14 Author: Thomas Wuerthinger Date: 2013-10-16 03:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4811a78ced14 Merge. - graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/ForEachToGraal.java - graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILBackend.java - graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILCompilationResult.java - graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java - graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotRuntime.java - graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRuntime.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/HotSpotRuntime.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java Changeset: 97fe8342a90f Author: Thomas Wuerthinger Date: 2013-10-16 03:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/97fe8342a90f Remove files of Truffle printer. - graal/com.oracle.graal.truffle.printer/src/com/oracle/graal/truffle/printer/InlinePrinterProcessor.java - graal/com.oracle.graal.truffle.printer/src/com/oracle/graal/truffle/printer/method/CallStackElement.java - graal/com.oracle.graal.truffle.printer/src/com/oracle/graal/truffle/printer/method/MethodHolder.java - graal/com.oracle.graal.truffle.printer/src/com/oracle/graal/truffle/printer/method/TruffleMethodNode.java Changeset: 930eb01324ec Author: Thomas Wuerthinger Date: 2013-10-16 03:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/930eb01324ec Merge. Changeset: c0fa3796819b Author: Thomas Wuerthinger Date: 2013-10-16 15:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c0fa3796819b Fix integer stamp test. ! graal/com.oracle.graal.nodes.test/src/com/oracle/graal/nodes/test/IntegerStampTest.java Changeset: aace760df495 Author: Thomas Wuerthinger Date: 2013-10-16 15:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/aace760df495 Merge. - graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/AMD64SPARCForeignCallsProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: d60cdea43920 Author: Thomas Wuerthinger Date: 2013-10-16 16:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d60cdea43920 Merge. From doug.simon at oracle.com Wed Oct 16 16:57:27 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 17 Oct 2013 01:57:27 +0200 Subject: enhancements we'd like to see out of the graal redesign In-Reply-To: <5DD1503F815BD14889DC81D28643E3A7553A49BE@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A7553A49BE@SATLEXDAG02.amd.com> Message-ID: <525F27E7.4050408@oracle.com> Hi Vasanth, I spent the last few days on this and am pushing a changeset now that gets us a lot closer to where we want to be. The general idea (and implementation) is that there is a single HotSpotGraalRuntime that supports a host backend as well any number of extra backends. More inline below: On 10/16/2013 05:38 PM, Venkatachalam, Vasanth wrote: > > Hi Doug, > > You mentioned that Graal is being redesigned to support multiple GPU > targets. I'd like to participate in the redesign discussion if > possible. As you suggested, I've made an initial list of things we'd > like to see come out of this redesign. I know we talked about some of > this already. > > 1.We'd like to see a clear separation between the host runtime and the > runtime of the target that we're generating code for, and the ability > for the target runtime (or backend) to reuse data structures from the > host if needed. Currently, AMD64HotSpotRuntime is being treated as the > host and target runtime when we are generating code for HSAIL. This > puts the execution in an inconsistent state where HSAIL registers are > being used, but the target runtime is still being treated as AMD64. > When generating code for a target other than the host runtime, the > only place where we should have to rely on the host runtime is when we > are reusing data structures defined in the host runtime. > > 2.Related to 1), we need the ability to specify in a central location > what the target runtime is (e.g., HSAIL) and have this change be > automatically percolated to all parts of the code that are referring > to the target runtime. > This is partly done. I have still yet to work out how to make snippets be reusable across different backends but have some ideas I will investigate further tomorrow. > 3.As a result of the problem mentioned in 1), we're seeing errors and > exceptions when we run HSAIL test cases. Two examples below. > > a.CFGPrinterObserver line 146 looks up the runtime to be > AMD64HotSpotRuntime, and as a result > CompilationPrinter.debugInfoToString (line 124) gets an > ArrayIndexOutOfBoundsException when it tries to lookup an HSAIL > register number in an array of AMD64 registers (which has fewer > registers than HSAIL). This is causing test cases that exercise a lot > of HSAIL registers to fail when we run them with flags to dump a data > file for the C1visualizer. > > b.The other example is that test cases involving method calls are > causing some exception handling snippets to be invoked. The AMD64 > definition of these snippets gets loaded and looks for a > threadregister (which we haven't specified in HSAIL) and this leads to > an assertion error. > > As mentioned earlier, we would like the ability to fix > all such problems by making changes to a central location, as opposed > to having to code around them in several places. For example, you > mentioned one possible solution would be the ability to pass in an > HSAIL specific CodeCacheProvider to GraalCompiler.compileGraph(), > which in turn causes the right target runtime to be percolated to all > of these code regions.. We'd like the redesign to make such a > centralized solution possible. > You'll see in the recent changes that we are moving in this direction. > > 4.Currently, Graal is building up a superset of intrinsics for the > host runtime (x86) and allowing the different backends to filter off > of that list. For the case of supporting GPU targets, we'd like a way > for each backend to define its own intrinsics that may not be part of > the x86 intrinsics. > Yes, I should have a solution for that. > > 5.We need to be able to declare our own snippets without affecting the > AMD64 snippets. > > a.Similarly our own Replacements > Understood. > > 6.We may have a need to define our own new nodes in the HSAIL backend, > for example used by our own snippets. It would be preferable if we > can do this in a way without having to define NYI node handlers for > that node in all the other backends. > As long as the nodes are defined and used only in HSAIL projects, there will be no need for NYI place holder code anywhere. > > 7.Since there are multiple GPU targets (.e.g, HSAIL, PTX), we need to > make sure the infrastructure supports multiple ISA targets, not just one. > Done. -Doug > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, October 08, 2013 1:08 PM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net ; > dl.Runtimes > Subject: Re: handling of Math intrinsics for multiple GPU targets > > This is obviously something else that needs to be vectored to each > backend, allowing each to make their own decision as you say. It will > be factored into the redesign currently going on. Please let us know > of other abstractions like this that need to be broadened or exposed > to each backend. > > On Oct 8, 2013, at 6:11 PM, "Venkatachalam, Vasanth" > > > wrote: > > > Hi, > > > > > > I noticed that Graal is building a superset of math intrinsics for > the host runtime (x86) and then filtering out some of these methods > from being intrinsified based on the value of a config parameter > (e.g., config.usePopCountIinstruction, config.useAESIntrinsics, etc.). > > > > > > In more detail when the VM first starts up in > VMToCompilerImpl.start() it gets the host runtime (which is x86) and > builds a superset of intrinsics for that runtime by calling > GraalMethodSubstitutions.registerReplacements( ). This in turn > processes a class file MathSubstitutionsx86.class to get a list of > math routines to be intrinsified, filters out some of these routines > (via a call to HotSpotReplacementsImpl.registerMethodSubstitution()) > and adds the remaining ones to a HashMap called > registeredMethodSubstitutions. > > > > > > For the case of supporting multiple GPU targets, it sounds like this > logic is the reverse of what we need. Instead of building a superset > of intrinsics for x86 and filtering them for the target runtime, we > need a way for each target runtime (e.g., HSAIL) to specify its own > list of supported intrinsics. Has anyone thought about how this should > be handled? > > > > > > Vasanth > > > > From doug.simon at oracle.com Wed Oct 16 23:30:19 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 17 Oct 2013 06:30:19 +0000 Subject: hg: graal/graal: 10 new changesets Message-ID: <20131017063205.DC192624A0@hg.openjdk.java.net> Changeset: 5f022aa41631 Author: Christian Humer Date: 2013-10-16 18:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5f022aa41631 Truffle-DSL: fixed an NPE if invalid TypeData are compared. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/ImplicitCastData.java Changeset: 8970574702a4 Author: Christian Humer Date: 2013-10-16 18:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8970574702a4 Truffle-DSL: fixed type comparison of inner classes fails with ECJ when class was loaded from binary file. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/Utils.java Changeset: ce4836e0212d Author: Christian Humer Date: 2013-10-16 18:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ce4836e0212d Merge. - graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/ForEachToGraal.java - graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILBackend.java - graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILCompilationResult.java - graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java - graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotRuntime.java - graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java - graal/com.oracle.graal.truffle.printer/src/com/oracle/graal/truffle/printer/InlinePrinterProcessor.java - graal/com.oracle.graal.truffle.printer/src/com/oracle/graal/truffle/printer/method/CallStackElement.java - graal/com.oracle.graal.truffle.printer/src/com/oracle/graal/truffle/printer/method/MethodHolder.java - graal/com.oracle.graal.truffle.printer/src/com/oracle/graal/truffle/printer/method/TruffleMethodNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameAccessNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameGetNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/FrameSetNode.java Changeset: d08accd58925 Author: Doug Simon Date: 2013-10-17 01:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d08accd58925 added support for wrapping long lines in mx/projects by placing a "\" at the end of the line (like the C preprocessor accepts) ! mxtool/mx.py Changeset: f87c68d79f07 Author: Doug Simon Date: 2013-10-17 01:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f87c68d79f07 improved support for co-existing, multiple backends (GRAAL-363) ! graal/com.oracle.graal.api.runtime/src/com/oracle/graal/api/runtime/Graal.java ! graal/com.oracle.graal.api.runtime/src/com/oracle/graal/api/runtime/GraalRuntime.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BasicHSAILTest.java ! 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/PTXBackend.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.test/src/com/oracle/graal/compiler/test/backend/AllocatorTest.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/AMD64HotSpotBackendFactory.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/AMD64HotSpotCodeCacheProvider.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotForeignCallsProvider.java - graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotGraalRuntime.java - graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotGraalRuntimeFactory.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/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLoweringProvider.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/ForEachToGraal.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/HSAILHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotCodeCacheProvider.java + graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotForeignCallsProvider.java - graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java + graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotCodeCacheProvider.java + graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotForeignCallsProvider.java - graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotGraalRuntime.java + 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/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/SPARCHotSpotCodeCacheProvider.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotForeignCallsProvider.java - graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotGraalRuntime.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/SPARCHotSpotLIRGenerator.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/CompileTheWorld.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotForeignCallLinkage.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntimeFactory.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToGPU.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToGPUImpl.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/HotSpotCodeCacheProvider.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotForeignCallsProvider.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostForeignCallsProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotLoweringProvider.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/HotSpotResolvedJavaField.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/nodes/CurrentJavaThreadNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/LoadExceptionObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VerifyOopStub.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/CompiledExceptionHandlerTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/DeoptimizeOnExceptionTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/InstanceOfTest.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/InvokeTest.java ! mx/projects ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCompilerToGPU.cpp ! src/share/vm/graal/graalVMToCompiler.cpp Changeset: 5c6f55dcd629 Author: Doug Simon Date: 2013-10-17 01:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5c6f55dcd629 added missing file + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotForeignCallsProvider.java Changeset: d155f67c4941 Author: Doug Simon Date: 2013-10-17 01:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d155f67c4941 fixed project canonicalization ! mx/projects Changeset: bb5a7574ae81 Author: Doug Simon Date: 2013-10-17 01:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bb5a7574ae81 fixed C++ compilation error in fastdebug build ! src/share/vm/graal/graalCompilerToGPU.cpp Changeset: 99ca997f4eae Author: twisti Date: 2013-10-16 19:49 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/99ca997f4eae added NegateNodeCanonicalizationTest + graal/com.oracle.graal.nodes.test/src/com/oracle/graal/nodes/test/NegateNodeCanonicalizationTest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/NegateNode.java Changeset: 3e559d1db048 Author: twisti Date: 2013-10-16 22:06 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3e559d1db048 make TimedBootstrap work with lower time limits ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java From doug.simon at oracle.com Thu Oct 17 04:34:36 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 17 Oct 2013 11:34:36 +0000 Subject: hg: graal/graal: 11 new changesets Message-ID: <20131017113552.A6CF8624AA@hg.openjdk.java.net> Changeset: 88d451c7c484 Author: Doug Simon Date: 2013-10-17 09:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/88d451c7c484 factored out retrieving the host architecture name to handle variations in value of os.arch system property ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java Changeset: 3661954321aa Author: Doug Simon Date: 2013-10-17 09:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3661954321aa removed more uses of HotSpotGraalRuntime.getHostProviders() (GRAAL-363) ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotForeignCallsProvider.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotForeignCallsProvider.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotForeignCallsProvider.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/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotForeignCallsProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostForeignCallsProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java Changeset: 59ce8d220e11 Author: Doug Simon Date: 2013-10-17 10:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/59ce8d220e11 replaced HotSpotGraalRuntime.wordKind with an access via the host backend (GRAAL-363) ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotForeignCallLinkage.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java Changeset: 9c35e2cef4a2 Author: Doug Simon Date: 2013-10-17 10:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9c35e2cef4a2 removed yet more uses of HotSpotGraalRuntime.getHostProviders() (GRAAL-363) ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/ForEachToGraal.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILCompilationResult.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 Changeset: b11213c41769 Author: Doug Simon Date: 2013-10-17 10:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b11213c41769 preliminary support for initializing multiple ForeignCallProviders and LoweringProviders (GRAAL-363) ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotLoweringProvider.java ! 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/SPARCHotSpotLoweringProvider.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/HotSpotHostLoweringProvider.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java Changeset: b7fd9efe24c5 Author: Doug Simon Date: 2013-10-17 11:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b7fd9efe24c5 prevent npe in Buffer.copyData() when Buffer.data is null ! graal/com.oracle.graal.asm/src/com/oracle/graal/asm/Buffer.java Changeset: be9971b46cc8 Author: Doug Simon Date: 2013-10-17 11:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/be9971b46cc8 replace new InternalError("NYI") with GraalInternalError.unimplemented() ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java Changeset: 2a833e0d4e0a Author: Doug Simon Date: 2013-10-17 11:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2a833e0d4e0a gave HSAIL its own Replacements implementation (HSAILHotSpotReplacementsImpl) ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotForeignCallsProvider.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLoweringProvider.java + graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotReplacementsImpl.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotForeignCallsProvider.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackendFactory.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/HotSpotHostLoweringProvider.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java Changeset: 458676bcc4e0 Author: Doug Simon Date: 2013-10-17 11:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/458676bcc4e0 marked HSAIL tests that rely on unimplemented features ! 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/StaticNBodySpillTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticNBodyTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StringContainsTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StringIndexOfTest.java Changeset: 073e4d6cd3dd Author: Doug Simon Date: 2013-10-17 12:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/073e4d6cd3dd fixed regression ! graal/com.oracle.graal.asm/src/com/oracle/graal/asm/Buffer.java Changeset: 85d03b72f269 Author: Doug Simon Date: 2013-10-17 12:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/85d03b72f269 added support disassembling during CodeGen ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java From doug.simon at oracle.com Thu Oct 17 07:45:41 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 17 Oct 2013 16:45:41 +0200 Subject: enhancements we'd like to see out of the graal redesign In-Reply-To: <525F27E7.4050408@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A7553A49BE@SATLEXDAG02.amd.com> <525F27E7.4050408@oracle.com> Message-ID: <525FF815.5030709@oracle.com> On 10/17/2013 01:57 AM, Doug Simon wrote: > Hi Vasanth, > > I spent the last few days on this and am pushing a changeset now that > gets us a lot closer to where we want to be. The general idea (and > implementation) is that there is a single HotSpotGraalRuntime that > supports a host backend as well any number of extra backends. > > More inline below: > > On 10/16/2013 05:38 PM, Venkatachalam, Vasanth wrote: >> >> Hi Doug, >> >> You mentioned that Graal is being redesigned to support multiple GPU >> targets. I'd like to participate in the redesign discussion if >> possible. As you suggested, I've made an initial list of things we'd >> like to see come out of this redesign. I know we talked about some of >> this already. >> >> 1.We'd like to see a clear separation between the host runtime and the >> runtime of the target that we're generating code for, and the ability >> for the target runtime (or backend) to reuse data structures from the >> host if needed. Currently, AMD64HotSpotRuntime is being treated as the >> host and target runtime when we are generating code for HSAIL. This >> puts the execution in an inconsistent state where HSAIL registers are >> being used, but the target runtime is still being treated as AMD64. >> When generating code for a target other than the host runtime, the >> only place where we should have to rely on the host runtime is when we >> are reusing data structures defined in the host runtime. >> >> 2.Related to 1), we need the ability to specify in a central location >> what the target runtime is (e.g., HSAIL) and have this change be >> automatically percolated to all parts of the code that are referring >> to the target runtime. >> > > This is partly done. I have still yet to work out how to make snippets > be reusable across different backends but have some ideas I will > investigate further tomorrow. The only way to do this is to pass all relevant configuration information into this snippets as @ConstantParameter arguments. This means every snippet that directly or indirectly uses a @Fold method (e.g., in HotSpotReplacementUtils) needs to be modified. Before making this investment, it would be good know which of the existing snippets you think could be used by the HSAIL backend. The same analysis would apply for the PTX. >> 3.As a result of the problem mentioned in 1), we're seeing errors and >> exceptions when we run HSAIL test cases. Two examples below. >> >> a.CFGPrinterObserver line 146 looks up the runtime to be >> AMD64HotSpotRuntime, and as a result >> CompilationPrinter.debugInfoToString (line 124) gets an >> ArrayIndexOutOfBoundsException when it tries to lookup an HSAIL >> register number in an array of AMD64 registers (which has fewer >> registers than HSAIL). This is causing test cases that exercise a lot >> of HSAIL registers to fail when we run them with flags to dump a data >> file for the C1visualizer. This should now be fixed. >> b.The other example is that test cases involving method calls are >> causing some exception handling snippets to be invoked. The AMD64 >> definition of these snippets gets loaded and looks for a >> threadregister (which we haven't specified in HSAIL) and this leads to >> an assertion error. >> >> As mentioned earlier, we would like the ability to fix >> all such problems by making changes to a central location, as opposed >> to having to code around them in several places. For example, you >> mentioned one possible solution would be the ability to pass in an >> HSAIL specific CodeCacheProvider to GraalCompiler.compileGraph(), >> which in turn causes the right target runtime to be percolated to all >> of these code regions.. We'd like the redesign to make such a >> centralized solution possible. >> > > You'll see in the recent changes that we are moving in this direction. >> >> 4.Currently, Graal is building up a superset of intrinsics for the >> host runtime (x86) and allowing the different backends to filter off >> of that list. For the case of supporting GPU targets, we'd like a way >> for each backend to define its own intrinsics that may not be part of >> the x86 intrinsics. That should now be solved with the new HSAILHotSpotReplacementsImpl and HSAILHotSpotLoweringProvider classes. >> 5.We need to be able to declare our own snippets without affecting the >> AMD64 snippets. To prevent us from holding you up, you could simply copy the existing snippets you think are reusable in the HSAIL backend. Of course, you'd need to redirect them to alternative @Fold utility methods. >> a.Similarly our own Replacements That should now be supported as described above. >> 6.We may have a need to define our own new nodes in the HSAIL backend, >> for example used by our own snippets. It would be preferable if we >> can do this in a way without having to define NYI node handlers for >> that node in all the other backends. >> > As long as the nodes are defined and used only in HSAIL projects, there > will be no need for NYI place holder code anywhere. >> >> 7.Since there are multiple GPU targets (.e.g, HSAIL, PTX), we need to >> make sure the infrastructure supports multiple ISA targets, not just one. >> > Done. -Doug >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Tuesday, October 08, 2013 1:08 PM >> To: Venkatachalam, Vasanth >> Cc: graal-dev at openjdk.java.net ; >> dl.Runtimes >> Subject: Re: handling of Math intrinsics for multiple GPU targets >> >> This is obviously something else that needs to be vectored to each >> backend, allowing each to make their own decision as you say. It will >> be factored into the redesign currently going on. Please let us know >> of other abstractions like this that need to be broadened or exposed >> to each backend. >> >> On Oct 8, 2013, at 6:11 PM, "Venkatachalam, Vasanth" >> > >> wrote: >> >> > Hi, >> >> > >> >> > I noticed that Graal is building a superset of math intrinsics for >> the host runtime (x86) and then filtering out some of these methods >> from being intrinsified based on the value of a config parameter >> (e.g., config.usePopCountIinstruction, config.useAESIntrinsics, etc.). >> >> > >> >> > In more detail when the VM first starts up in >> VMToCompilerImpl.start() it gets the host runtime (which is x86) and >> builds a superset of intrinsics for that runtime by calling >> GraalMethodSubstitutions.registerReplacements( ). This in turn >> processes a class file MathSubstitutionsx86.class to get a list of >> math routines to be intrinsified, filters out some of these routines >> (via a call to HotSpotReplacementsImpl.registerMethodSubstitution()) >> and adds the remaining ones to a HashMap called >> registeredMethodSubstitutions. >> >> > >> >> > For the case of supporting multiple GPU targets, it sounds like this >> logic is the reverse of what we need. Instead of building a superset >> of intrinsics for x86 and filtering them for the target runtime, we >> need a way for each target runtime (e.g., HSAIL) to specify its own >> list of supported intrinsics. Has anyone thought about how this should >> be handled? >> >> > >> >> > Vasanth >> >> > >> > From tom.deneau at amd.com Thu Oct 17 09:13:58 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 17 Oct 2013 16:13:58 +0000 Subject: enhancements we'd like to see out of the graal redesign In-Reply-To: <525FF815.5030709@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A7553A49BE@SATLEXDAG02.amd.com> <525F27E7.4050408@oracle.com> <525FF815.5030709@oracle.com> Message-ID: Doug -- Not sure I understand this statement To prevent us from holding you up, you could simply copy the existing snippets you think are reusable in the HSAIL backend. Of course, you'd need to redirect them to alternative @Fold utility methods. I'm not sure of the semantics of the @Fold annotation but would we not be able to reuse some of the existing @Fold utility methods if appropriate? -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Thursday, October 17, 2013 9:46 AM To: Venkatachalam, Vasanth Cc: dl.Runtimes; graal-dev at openjdk.java.net Subject: Re: enhancements we'd like to see out of the graal redesign On 10/17/2013 01:57 AM, Doug Simon wrote: > Hi Vasanth, > > I spent the last few days on this and am pushing a changeset now that > gets us a lot closer to where we want to be. The general idea (and > implementation) is that there is a single HotSpotGraalRuntime that > supports a host backend as well any number of extra backends. > > More inline below: > > On 10/16/2013 05:38 PM, Venkatachalam, Vasanth wrote: >> >> Hi Doug, >> >> You mentioned that Graal is being redesigned to support multiple GPU >> targets. I'd like to participate in the redesign discussion if >> possible. As you suggested, I've made an initial list of things we'd >> like to see come out of this redesign. I know we talked about some >> of this already. >> >> 1.We'd like to see a clear separation between the host runtime and >> the runtime of the target that we're generating code for, and the >> ability for the target runtime (or backend) to reuse data structures >> from the host if needed. Currently, AMD64HotSpotRuntime is being >> treated as the host and target runtime when we are generating code >> for HSAIL. This puts the execution in an inconsistent state where >> HSAIL registers are being used, but the target runtime is still being treated as AMD64. >> When generating code for a target other than the host runtime, the >> only place where we should have to rely on the host runtime is when >> we are reusing data structures defined in the host runtime. >> >> 2.Related to 1), we need the ability to specify in a central location >> what the target runtime is (e.g., HSAIL) and have this change be >> automatically percolated to all parts of the code that are referring >> to the target runtime. >> > > This is partly done. I have still yet to work out how to make snippets > be reusable across different backends but have some ideas I will > investigate further tomorrow. The only way to do this is to pass all relevant configuration information into this snippets as @ConstantParameter arguments. This means every snippet that directly or indirectly uses a @Fold method (e.g., in HotSpotReplacementUtils) needs to be modified. Before making this investment, it would be good know which of the existing snippets you think could be used by the HSAIL backend. The same analysis would apply for the PTX. >> 3.As a result of the problem mentioned in 1), we're seeing errors and >> exceptions when we run HSAIL test cases. Two examples below. >> >> a.CFGPrinterObserver line 146 looks up the runtime to be >> AMD64HotSpotRuntime, and as a result >> CompilationPrinter.debugInfoToString (line 124) gets an >> ArrayIndexOutOfBoundsException when it tries to lookup an HSAIL >> register number in an array of AMD64 registers (which has fewer >> registers than HSAIL). This is causing test cases that exercise a lot >> of HSAIL registers to fail when we run them with flags to dump a >> data file for the C1visualizer. This should now be fixed. >> b.The other example is that test cases involving method calls are >> causing some exception handling snippets to be invoked. The AMD64 >> definition of these snippets gets loaded and looks for a >> threadregister (which we haven't specified in HSAIL) and this leads >> to an assertion error. >> >> As mentioned earlier, we would like the ability to fix >> all such problems by making changes to a central location, as opposed >> to having to code around them in several places. For example, you >> mentioned one possible solution would be the ability to pass in an >> HSAIL specific CodeCacheProvider to GraalCompiler.compileGraph(), >> which in turn causes the right target runtime to be percolated to all >> of these code regions.. We'd like the redesign to make such a >> centralized solution possible. >> > > You'll see in the recent changes that we are moving in this direction. >> >> 4.Currently, Graal is building up a superset of intrinsics for the >> host runtime (x86) and allowing the different backends to filter off >> of that list. For the case of supporting GPU targets, we'd like a >> way for each backend to define its own intrinsics that may not be >> part of the x86 intrinsics. That should now be solved with the new HSAILHotSpotReplacementsImpl and HSAILHotSpotLoweringProvider classes. >> 5.We need to be able to declare our own snippets without affecting >> the >> AMD64 snippets. To prevent us from holding you up, you could simply copy the existing snippets you think are reusable in the HSAIL backend. Of course, you'd need to redirect them to alternative @Fold utility methods. >> a.Similarly our own Replacements That should now be supported as described above. >> 6.We may have a need to define our own new nodes in the HSAIL >> backend, for example used by our own snippets. It would be >> preferable if we can do this in a way without having to define NYI >> node handlers for that node in all the other backends. >> > As long as the nodes are defined and used only in HSAIL projects, > there will be no need for NYI place holder code anywhere. >> >> 7.Since there are multiple GPU targets (.e.g, HSAIL, PTX), we need to >> make sure the infrastructure supports multiple ISA targets, not just one. >> > Done. -Doug >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Tuesday, October 08, 2013 1:08 PM >> To: Venkatachalam, Vasanth >> Cc: graal-dev at openjdk.java.net ; >> dl.Runtimes >> Subject: Re: handling of Math intrinsics for multiple GPU targets >> >> This is obviously something else that needs to be vectored to each >> backend, allowing each to make their own decision as you say. It will >> be factored into the redesign currently going on. Please let us know >> of other abstractions like this that need to be broadened or exposed >> to each backend. >> >> On Oct 8, 2013, at 6:11 PM, "Venkatachalam, Vasanth" >> > > >> wrote: >> >> > Hi, >> >> > >> >> > I noticed that Graal is building a superset of math intrinsics for >> the host runtime (x86) and then filtering out some of these methods >> from being intrinsified based on the value of a config parameter >> (e.g., config.usePopCountIinstruction, config.useAESIntrinsics, etc.). >> >> > >> >> > In more detail when the VM first starts up in >> VMToCompilerImpl.start() it gets the host runtime (which is x86) and >> builds a superset of intrinsics for that runtime by calling >> GraalMethodSubstitutions.registerReplacements( ). This in turn >> processes a class file MathSubstitutionsx86.class to get a list of >> math routines to be intrinsified, filters out some of these routines >> (via a call to HotSpotReplacementsImpl.registerMethodSubstitution()) >> and adds the remaining ones to a HashMap called >> registeredMethodSubstitutions. >> >> > >> >> > For the case of supporting multiple GPU targets, it sounds like >> > this >> logic is the reverse of what we need. Instead of building a superset >> of intrinsics for x86 and filtering them for the target runtime, we >> need a way for each target runtime (e.g., HSAIL) to specify its own >> list of supported intrinsics. Has anyone thought about how this >> should be handled? >> >> > >> >> > Vasanth >> >> > >> > From doug.simon at oracle.com Thu Oct 17 10:00:06 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 17 Oct 2013 19:00:06 +0200 Subject: enhancements we'd like to see out of the graal redesign In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A7553A49BE@SATLEXDAG02.amd.com> <525F27E7.4050408@oracle.com> <525FF815.5030709@oracle.com> Message-ID: <52601796.9000401@oracle.com> Consider the snippet below (in NewObjectSnippets.java) for object allocation: @Snippet public static Word allocate(int size) { Word thread = thread(); Word top = readTlabTop(thread); Word end = readTlabEnd(thread); Word newTop = top.add(size); /* * this check might lead to problems if the TLAB is within 16GB of the address space end * (checked in c++ code) */ if (probability(FAST_PATH_PROBABILITY, newTop.belowOrEqual(end))) { writeTlabTop(thread, newTop); return top; } return Word.zero(); } These are the support methods in HotSpotReplacementsUtil called by the first line of the snippet: public static Word thread() { return registerAsWord(threadRegister(), true, false); } @Fold public static Register threadRegister() { return runtime().getHostProviders().getRegisters().getThreadRegister(); } That last @Fold annotated method effectively binds the snippet to the host backend. We could fix this as follows: @Snippet public static Word allocate(int size, @ConstantParameter Register threadReg) { Word thread = registerAsWord(threadReg, true, false); ... } However, before making this change, I'd like to be sure that this snippet and others like are actually usable when compiling for the HSAIL backend. To ascertain that, I'm suggesting you make a copy of the snippet code (and their associated infrastructure) and modify it to use HSAIL-specific @Fold methods. The readTlabTop/readTlabEnd/writeTlabTop methods also use @Fold helpers to get the various TLAB offsets. Are they going to be reusable as is for HSAIL? -Doug On 10/17/2013 06:13 PM, Deneau, Tom wrote: > Doug -- > > Not sure I understand this statement > > To prevent us from holding you up, you could simply copy the existing snippets you think are reusable in the HSAIL backend. > Of course, you'd need to redirect them to alternative @Fold utility methods. > > I'm not sure of the semantics of the @Fold annotation but would we not be able to reuse some of the existing @Fold utility methods if appropriate? > > -- Tom > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Thursday, October 17, 2013 9:46 AM > To: Venkatachalam, Vasanth > Cc: dl.Runtimes; graal-dev at openjdk.java.net > Subject: Re: enhancements we'd like to see out of the graal redesign > > On 10/17/2013 01:57 AM, Doug Simon wrote: >> Hi Vasanth, >> >> I spent the last few days on this and am pushing a changeset now that >> gets us a lot closer to where we want to be. The general idea (and >> implementation) is that there is a single HotSpotGraalRuntime that >> supports a host backend as well any number of extra backends. >> >> More inline below: >> >> On 10/16/2013 05:38 PM, Venkatachalam, Vasanth wrote: >>> >>> Hi Doug, >>> >>> You mentioned that Graal is being redesigned to support multiple GPU >>> targets. I'd like to participate in the redesign discussion if >>> possible. As you suggested, I've made an initial list of things we'd >>> like to see come out of this redesign. I know we talked about some >>> of this already. >>> >>> 1.We'd like to see a clear separation between the host runtime and >>> the runtime of the target that we're generating code for, and the >>> ability for the target runtime (or backend) to reuse data structures >>> from the host if needed. Currently, AMD64HotSpotRuntime is being >>> treated as the host and target runtime when we are generating code >>> for HSAIL. This puts the execution in an inconsistent state where >>> HSAIL registers are being used, but the target runtime is still being treated as AMD64. >>> When generating code for a target other than the host runtime, the >>> only place where we should have to rely on the host runtime is when >>> we are reusing data structures defined in the host runtime. >>> >>> 2.Related to 1), we need the ability to specify in a central location >>> what the target runtime is (e.g., HSAIL) and have this change be >>> automatically percolated to all parts of the code that are referring >>> to the target runtime. >>> >> >> This is partly done. I have still yet to work out how to make snippets >> be reusable across different backends but have some ideas I will >> investigate further tomorrow. > > The only way to do this is to pass all relevant configuration information into this snippets as @ConstantParameter arguments. This means every snippet that directly or indirectly uses a @Fold method (e.g., in HotSpotReplacementUtils) needs to be modified. > > Before making this investment, it would be good know which of the existing snippets you think could be used by the HSAIL backend. The same analysis would apply for the PTX. > >>> 3.As a result of the problem mentioned in 1), we're seeing errors and >>> exceptions when we run HSAIL test cases. Two examples below. >>> >>> a.CFGPrinterObserver line 146 looks up the runtime to be >>> AMD64HotSpotRuntime, and as a result >>> CompilationPrinter.debugInfoToString (line 124) gets an >>> ArrayIndexOutOfBoundsException when it tries to lookup an HSAIL >>> register number in an array of AMD64 registers (which has fewer >>> registers than HSAIL). This is causing test cases that exercise a lot >>> of HSAIL registers to fail when we run them with flags to dump a >>> data file for the C1visualizer. > > This should now be fixed. > >>> b.The other example is that test cases involving method calls are >>> causing some exception handling snippets to be invoked. The AMD64 >>> definition of these snippets gets loaded and looks for a >>> threadregister (which we haven't specified in HSAIL) and this leads >>> to an assertion error. >>> >>> As mentioned earlier, we would like the ability to fix >>> all such problems by making changes to a central location, as opposed >>> to having to code around them in several places. For example, you >>> mentioned one possible solution would be the ability to pass in an >>> HSAIL specific CodeCacheProvider to GraalCompiler.compileGraph(), >>> which in turn causes the right target runtime to be percolated to all >>> of these code regions.. We'd like the redesign to make such a >>> centralized solution possible. >>> >> >> You'll see in the recent changes that we are moving in this direction. >>> >>> 4.Currently, Graal is building up a superset of intrinsics for the >>> host runtime (x86) and allowing the different backends to filter off >>> of that list. For the case of supporting GPU targets, we'd like a >>> way for each backend to define its own intrinsics that may not be >>> part of the x86 intrinsics. > > That should now be solved with the new HSAILHotSpotReplacementsImpl and HSAILHotSpotLoweringProvider classes. > >>> 5.We need to be able to declare our own snippets without affecting >>> the >>> AMD64 snippets. > > To prevent us from holding you up, you could simply copy the existing snippets you think are reusable in the HSAIL backend. Of course, you'd need to redirect them to alternative @Fold utility methods. > >>> a.Similarly our own Replacements > > That should now be supported as described above. > >>> 6.We may have a need to define our own new nodes in the HSAIL >>> backend, for example used by our own snippets. It would be >>> preferable if we can do this in a way without having to define NYI >>> node handlers for that node in all the other backends. >>> >> As long as the nodes are defined and used only in HSAIL projects, >> there will be no need for NYI place holder code anywhere. >>> >>> 7.Since there are multiple GPU targets (.e.g, HSAIL, PTX), we need to >>> make sure the infrastructure supports multiple ISA targets, not just one. >>> >> Done. > > -Doug > >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Tuesday, October 08, 2013 1:08 PM >>> To: Venkatachalam, Vasanth >>> Cc: graal-dev at openjdk.java.net ; >>> dl.Runtimes >>> Subject: Re: handling of Math intrinsics for multiple GPU targets >>> >>> This is obviously something else that needs to be vectored to each >>> backend, allowing each to make their own decision as you say. It will >>> be factored into the redesign currently going on. Please let us know >>> of other abstractions like this that need to be broadened or exposed >>> to each backend. >>> >>> On Oct 8, 2013, at 6:11 PM, "Venkatachalam, Vasanth" >>> >> > >>> wrote: >>> >>>> Hi, >>> >>>> >>> >>>> I noticed that Graal is building a superset of math intrinsics for >>> the host runtime (x86) and then filtering out some of these methods >>> from being intrinsified based on the value of a config parameter >>> (e.g., config.usePopCountIinstruction, config.useAESIntrinsics, etc.). >>> >>>> >>> >>>> In more detail when the VM first starts up in >>> VMToCompilerImpl.start() it gets the host runtime (which is x86) and >>> builds a superset of intrinsics for that runtime by calling >>> GraalMethodSubstitutions.registerReplacements( ). This in turn >>> processes a class file MathSubstitutionsx86.class to get a list of >>> math routines to be intrinsified, filters out some of these routines >>> (via a call to HotSpotReplacementsImpl.registerMethodSubstitution()) >>> and adds the remaining ones to a HashMap called >>> registeredMethodSubstitutions. >>> >>>> >>> >>>> For the case of supporting multiple GPU targets, it sounds like >>>> this >>> logic is the reverse of what we need. Instead of building a superset >>> of intrinsics for x86 and filtering them for the target runtime, we >>> need a way for each target runtime (e.g., HSAIL) to specify its own >>> list of supported intrinsics. Has anyone thought about how this >>> should be handled? >>> >>>> >>> >>>> Vasanth >>> >>>> >>> >> > > From tom.deneau at amd.com Thu Oct 17 11:12:25 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 17 Oct 2013 18:12:25 +0000 Subject: enhancements we'd like to see out of the graal redesign In-Reply-To: <52601796.9000401@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A7553A49BE@SATLEXDAG02.amd.com> <525F27E7.4050408@oracle.com> <525FF815.5030709@oracle.com> <52601796.9000401@oracle.com> Message-ID: Doug -- I don't know whether there will be snippets we can use exactly as is including all the @Fold methods they call. But I do envision us writing our own snippets which might use some of the existing @Fold methods and also might define some of our own @Fold methods. Would that be possible? -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Thursday, October 17, 2013 12:00 PM To: Deneau, Tom; Venkatachalam, Vasanth Cc: dl.Runtimes; graal-dev at openjdk.java.net Subject: Re: enhancements we'd like to see out of the graal redesign Consider the snippet below (in NewObjectSnippets.java) for object allocation: @Snippet public static Word allocate(int size) { Word thread = thread(); Word top = readTlabTop(thread); Word end = readTlabEnd(thread); Word newTop = top.add(size); /* * this check might lead to problems if the TLAB is within 16GB of the address space end * (checked in c++ code) */ if (probability(FAST_PATH_PROBABILITY, newTop.belowOrEqual(end))) { writeTlabTop(thread, newTop); return top; } return Word.zero(); } These are the support methods in HotSpotReplacementsUtil called by the first line of the snippet: public static Word thread() { return registerAsWord(threadRegister(), true, false); } @Fold public static Register threadRegister() { return runtime().getHostProviders().getRegisters().getThreadRegister(); } That last @Fold annotated method effectively binds the snippet to the host backend. We could fix this as follows: @Snippet public static Word allocate(int size, @ConstantParameter Register threadReg) { Word thread = registerAsWord(threadReg, true, false); ... } However, before making this change, I'd like to be sure that this snippet and others like are actually usable when compiling for the HSAIL backend. To ascertain that, I'm suggesting you make a copy of the snippet code (and their associated infrastructure) and modify it to use HSAIL-specific @Fold methods. The readTlabTop/readTlabEnd/writeTlabTop methods also use @Fold helpers to get the various TLAB offsets. Are they going to be reusable as is for HSAIL? -Doug On 10/17/2013 06:13 PM, Deneau, Tom wrote: > Doug -- > > Not sure I understand this statement > > To prevent us from holding you up, you could simply copy the existing snippets you think are reusable in the HSAIL backend. > Of course, you'd need to redirect them to alternative @Fold utility methods. > > I'm not sure of the semantics of the @Fold annotation but would we not be able to reuse some of the existing @Fold utility methods if appropriate? > > -- Tom > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Thursday, October 17, 2013 9:46 AM > To: Venkatachalam, Vasanth > Cc: dl.Runtimes; graal-dev at openjdk.java.net > Subject: Re: enhancements we'd like to see out of the graal redesign > > On 10/17/2013 01:57 AM, Doug Simon wrote: >> Hi Vasanth, >> >> I spent the last few days on this and am pushing a changeset now that >> gets us a lot closer to where we want to be. The general idea (and >> implementation) is that there is a single HotSpotGraalRuntime that >> supports a host backend as well any number of extra backends. >> >> More inline below: >> >> On 10/16/2013 05:38 PM, Venkatachalam, Vasanth wrote: >>> >>> Hi Doug, >>> >>> You mentioned that Graal is being redesigned to support multiple GPU >>> targets. I'd like to participate in the redesign discussion if >>> possible. As you suggested, I've made an initial list of things we'd >>> like to see come out of this redesign. I know we talked about some >>> of this already. >>> >>> 1.We'd like to see a clear separation between the host runtime and >>> the runtime of the target that we're generating code for, and the >>> ability for the target runtime (or backend) to reuse data structures >>> from the host if needed. Currently, AMD64HotSpotRuntime is being >>> treated as the host and target runtime when we are generating code >>> for HSAIL. This puts the execution in an inconsistent state where >>> HSAIL registers are being used, but the target runtime is still being treated as AMD64. >>> When generating code for a target other than the host runtime, the >>> only place where we should have to rely on the host runtime is when >>> we are reusing data structures defined in the host runtime. >>> >>> 2.Related to 1), we need the ability to specify in a central >>> location what the target runtime is (e.g., HSAIL) and have this >>> change be automatically percolated to all parts of the code that are >>> referring to the target runtime. >>> >> >> This is partly done. I have still yet to work out how to make >> snippets be reusable across different backends but have some ideas I >> will investigate further tomorrow. > > The only way to do this is to pass all relevant configuration information into this snippets as @ConstantParameter arguments. This means every snippet that directly or indirectly uses a @Fold method (e.g., in HotSpotReplacementUtils) needs to be modified. > > Before making this investment, it would be good know which of the existing snippets you think could be used by the HSAIL backend. The same analysis would apply for the PTX. > >>> 3.As a result of the problem mentioned in 1), we're seeing errors >>> and exceptions when we run HSAIL test cases. Two examples below. >>> >>> a.CFGPrinterObserver line 146 looks up the runtime to be >>> AMD64HotSpotRuntime, and as a result >>> CompilationPrinter.debugInfoToString (line 124) gets an >>> ArrayIndexOutOfBoundsException when it tries to lookup an HSAIL >>> register number in an array of AMD64 registers (which has fewer >>> registers than HSAIL). This is causing test cases that exercise a >>> lot of HSAIL registers to fail when we run them with flags to dump >>> a data file for the C1visualizer. > > This should now be fixed. > >>> b.The other example is that test cases involving method calls are >>> causing some exception handling snippets to be invoked. The AMD64 >>> definition of these snippets gets loaded and looks for a >>> threadregister (which we haven't specified in HSAIL) and this leads >>> to an assertion error. >>> >>> As mentioned earlier, we would like the ability to >>> fix all such problems by making changes to a central location, as >>> opposed to having to code around them in several places. For >>> example, you mentioned one possible solution would be the ability to >>> pass in an HSAIL specific CodeCacheProvider to >>> GraalCompiler.compileGraph(), which in turn causes the right target >>> runtime to be percolated to all of these code regions.. We'd like >>> the redesign to make such a centralized solution possible. >>> >> >> You'll see in the recent changes that we are moving in this direction. >>> >>> 4.Currently, Graal is building up a superset of intrinsics for the >>> host runtime (x86) and allowing the different backends to filter off >>> of that list. For the case of supporting GPU targets, we'd like a >>> way for each backend to define its own intrinsics that may not be >>> part of the x86 intrinsics. > > That should now be solved with the new HSAILHotSpotReplacementsImpl and HSAILHotSpotLoweringProvider classes. > >>> 5.We need to be able to declare our own snippets without affecting >>> the >>> AMD64 snippets. > > To prevent us from holding you up, you could simply copy the existing snippets you think are reusable in the HSAIL backend. Of course, you'd need to redirect them to alternative @Fold utility methods. > >>> a.Similarly our own Replacements > > That should now be supported as described above. > >>> 6.We may have a need to define our own new nodes in the HSAIL >>> backend, for example used by our own snippets. It would be >>> preferable if we can do this in a way without having to define NYI >>> node handlers for that node in all the other backends. >>> >> As long as the nodes are defined and used only in HSAIL projects, >> there will be no need for NYI place holder code anywhere. >>> >>> 7.Since there are multiple GPU targets (.e.g, HSAIL, PTX), we need >>> to make sure the infrastructure supports multiple ISA targets, not just one. >>> >> Done. > > -Doug > >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Tuesday, October 08, 2013 1:08 PM >>> To: Venkatachalam, Vasanth >>> Cc: graal-dev at openjdk.java.net ; >>> dl.Runtimes >>> Subject: Re: handling of Math intrinsics for multiple GPU targets >>> >>> This is obviously something else that needs to be vectored to each >>> backend, allowing each to make their own decision as you say. It >>> will be factored into the redesign currently going on. Please let us >>> know of other abstractions like this that need to be broadened or >>> exposed to each backend. >>> >>> On Oct 8, 2013, at 6:11 PM, "Venkatachalam, Vasanth" >>> >> > >>> wrote: >>> >>>> Hi, >>> >>>> >>> >>>> I noticed that Graal is building a superset of math intrinsics for >>> the host runtime (x86) and then filtering out some of these methods >>> from being intrinsified based on the value of a config parameter >>> (e.g., config.usePopCountIinstruction, config.useAESIntrinsics, etc.). >>> >>>> >>> >>>> In more detail when the VM first starts up in >>> VMToCompilerImpl.start() it gets the host runtime (which is x86) and >>> builds a superset of intrinsics for that runtime by calling >>> GraalMethodSubstitutions.registerReplacements( ). This in turn >>> processes a class file MathSubstitutionsx86.class to get a list of >>> math routines to be intrinsified, filters out some of these routines >>> (via a call to HotSpotReplacementsImpl.registerMethodSubstitution()) >>> and adds the remaining ones to a HashMap called >>> registeredMethodSubstitutions. >>> >>>> >>> >>>> For the case of supporting multiple GPU targets, it sounds like >>>> this >>> logic is the reverse of what we need. Instead of building a superset >>> of intrinsics for x86 and filtering them for the target runtime, we >>> need a way for each target runtime (e.g., HSAIL) to specify its own >>> list of supported intrinsics. Has anyone thought about how this >>> should be handled? >>> >>>> >>> >>>> Vasanth >>> >>>> >>> >> > > From doug.simon at oracle.com Thu Oct 17 11:15:05 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 17 Oct 2013 20:15:05 +0200 Subject: enhancements we'd like to see out of the graal redesign In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A7553A49BE@SATLEXDAG02.amd.com> <525F27E7.4050408@oracle.com> <525FF815.5030709@oracle.com> <52601796.9000401@oracle.com> Message-ID: <52602929.2020101@oracle.com> On 10/17/2013 08:12 PM, Deneau, Tom wrote: > Doug -- > > I don't know whether there will be snippets we can use exactly as is including all the @Fold methods they call. > > But I do envision us writing our own snippets which might use some of the existing @Fold methods and also might define some of our own @Fold methods. Would that be possible? Writing your own snippets is not only possible, but recommended ;-) You can also use any @Fold methods that don't access host backend information (or any information that is not valid when executing on the GPU). -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Thursday, October 17, 2013 12:00 PM > To: Deneau, Tom; Venkatachalam, Vasanth > Cc: dl.Runtimes; graal-dev at openjdk.java.net > Subject: Re: enhancements we'd like to see out of the graal redesign > > Consider the snippet below (in NewObjectSnippets.java) for object allocation: > > @Snippet > public static Word allocate(int size) { > Word thread = thread(); > Word top = readTlabTop(thread); > Word end = readTlabEnd(thread); > Word newTop = top.add(size); > /* > * this check might lead to problems if the TLAB is within 16GB of the address space end > * (checked in c++ code) > */ > if (probability(FAST_PATH_PROBABILITY, newTop.belowOrEqual(end))) { > writeTlabTop(thread, newTop); > return top; > } > return Word.zero(); > } > > These are the support methods in HotSpotReplacementsUtil called by the first line of the snippet: > > public static Word thread() { > return registerAsWord(threadRegister(), true, false); > } > > @Fold > public static Register threadRegister() { > return runtime().getHostProviders().getRegisters().getThreadRegister(); > } > > That last @Fold annotated method effectively binds the snippet to the host backend. > > We could fix this as follows: > > @Snippet > public static Word allocate(int size, @ConstantParameter Register threadReg) { > Word thread = registerAsWord(threadReg, true, false); > ... > } > > However, before making this change, I'd like to be sure that this snippet and others like are actually usable when compiling for the HSAIL backend. > To ascertain that, I'm suggesting you make a copy of the snippet code (and their associated infrastructure) and modify it to use HSAIL-specific @Fold methods. > The readTlabTop/readTlabEnd/writeTlabTop methods also use @Fold helpers to get the various TLAB offsets. Are they going to be reusable as is for HSAIL? > > -Doug > > On 10/17/2013 06:13 PM, Deneau, Tom wrote: >> Doug -- >> >> Not sure I understand this statement >> >> To prevent us from holding you up, you could simply copy the existing snippets you think are reusable in the HSAIL backend. >> Of course, you'd need to redirect them to alternative @Fold utility methods. >> >> I'm not sure of the semantics of the @Fold annotation but would we not be able to reuse some of the existing @Fold utility methods if appropriate? >> >> -- Tom >> >> >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Thursday, October 17, 2013 9:46 AM >> To: Venkatachalam, Vasanth >> Cc: dl.Runtimes; graal-dev at openjdk.java.net >> Subject: Re: enhancements we'd like to see out of the graal redesign >> >> On 10/17/2013 01:57 AM, Doug Simon wrote: >>> Hi Vasanth, >>> >>> I spent the last few days on this and am pushing a changeset now that >>> gets us a lot closer to where we want to be. The general idea (and >>> implementation) is that there is a single HotSpotGraalRuntime that >>> supports a host backend as well any number of extra backends. >>> >>> More inline below: >>> >>> On 10/16/2013 05:38 PM, Venkatachalam, Vasanth wrote: >>>> >>>> Hi Doug, >>>> >>>> You mentioned that Graal is being redesigned to support multiple GPU >>>> targets. I'd like to participate in the redesign discussion if >>>> possible. As you suggested, I've made an initial list of things we'd >>>> like to see come out of this redesign. I know we talked about some >>>> of this already. >>>> >>>> 1.We'd like to see a clear separation between the host runtime and >>>> the runtime of the target that we're generating code for, and the >>>> ability for the target runtime (or backend) to reuse data structures >>>> from the host if needed. Currently, AMD64HotSpotRuntime is being >>>> treated as the host and target runtime when we are generating code >>>> for HSAIL. This puts the execution in an inconsistent state where >>>> HSAIL registers are being used, but the target runtime is still being treated as AMD64. >>>> When generating code for a target other than the host runtime, the >>>> only place where we should have to rely on the host runtime is when >>>> we are reusing data structures defined in the host runtime. >>>> >>>> 2.Related to 1), we need the ability to specify in a central >>>> location what the target runtime is (e.g., HSAIL) and have this >>>> change be automatically percolated to all parts of the code that are >>>> referring to the target runtime. >>>> >>> >>> This is partly done. I have still yet to work out how to make >>> snippets be reusable across different backends but have some ideas I >>> will investigate further tomorrow. >> >> The only way to do this is to pass all relevant configuration information into this snippets as @ConstantParameter arguments. This means every snippet that directly or indirectly uses a @Fold method (e.g., in HotSpotReplacementUtils) needs to be modified. >> >> Before making this investment, it would be good know which of the existing snippets you think could be used by the HSAIL backend. The same analysis would apply for the PTX. >> >>>> 3.As a result of the problem mentioned in 1), we're seeing errors >>>> and exceptions when we run HSAIL test cases. Two examples below. >>>> >>>> a.CFGPrinterObserver line 146 looks up the runtime to be >>>> AMD64HotSpotRuntime, and as a result >>>> CompilationPrinter.debugInfoToString (line 124) gets an >>>> ArrayIndexOutOfBoundsException when it tries to lookup an HSAIL >>>> register number in an array of AMD64 registers (which has fewer >>>> registers than HSAIL). This is causing test cases that exercise a >>>> lot of HSAIL registers to fail when we run them with flags to dump >>>> a data file for the C1visualizer. >> >> This should now be fixed. >> >>>> b.The other example is that test cases involving method calls are >>>> causing some exception handling snippets to be invoked. The AMD64 >>>> definition of these snippets gets loaded and looks for a >>>> threadregister (which we haven't specified in HSAIL) and this leads >>>> to an assertion error. >>>> >>>> As mentioned earlier, we would like the ability to >>>> fix all such problems by making changes to a central location, as >>>> opposed to having to code around them in several places. For >>>> example, you mentioned one possible solution would be the ability to >>>> pass in an HSAIL specific CodeCacheProvider to >>>> GraalCompiler.compileGraph(), which in turn causes the right target >>>> runtime to be percolated to all of these code regions.. We'd like >>>> the redesign to make such a centralized solution possible. >>>> >>> >>> You'll see in the recent changes that we are moving in this direction. >>>> >>>> 4.Currently, Graal is building up a superset of intrinsics for the >>>> host runtime (x86) and allowing the different backends to filter off >>>> of that list. For the case of supporting GPU targets, we'd like a >>>> way for each backend to define its own intrinsics that may not be >>>> part of the x86 intrinsics. >> >> That should now be solved with the new HSAILHotSpotReplacementsImpl and HSAILHotSpotLoweringProvider classes. >> >>>> 5.We need to be able to declare our own snippets without affecting >>>> the >>>> AMD64 snippets. >> >> To prevent us from holding you up, you could simply copy the existing snippets you think are reusable in the HSAIL backend. Of course, you'd need to redirect them to alternative @Fold utility methods. >> >>>> a.Similarly our own Replacements >> >> That should now be supported as described above. >> >>>> 6.We may have a need to define our own new nodes in the HSAIL >>>> backend, for example used by our own snippets. It would be >>>> preferable if we can do this in a way without having to define NYI >>>> node handlers for that node in all the other backends. >>>> >>> As long as the nodes are defined and used only in HSAIL projects, >>> there will be no need for NYI place holder code anywhere. >>>> >>>> 7.Since there are multiple GPU targets (.e.g, HSAIL, PTX), we need >>>> to make sure the infrastructure supports multiple ISA targets, not just one. >>>> >>> Done. >> >> -Doug >> >>>> -----Original Message----- >>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>> Sent: Tuesday, October 08, 2013 1:08 PM >>>> To: Venkatachalam, Vasanth >>>> Cc: graal-dev at openjdk.java.net ; >>>> dl.Runtimes >>>> Subject: Re: handling of Math intrinsics for multiple GPU targets >>>> >>>> This is obviously something else that needs to be vectored to each >>>> backend, allowing each to make their own decision as you say. It >>>> will be factored into the redesign currently going on. Please let us >>>> know of other abstractions like this that need to be broadened or >>>> exposed to each backend. >>>> >>>> On Oct 8, 2013, at 6:11 PM, "Venkatachalam, Vasanth" >>>> >>> > >>>> wrote: >>>> >>>>> Hi, >>>> >>>>> >>>> >>>>> I noticed that Graal is building a superset of math intrinsics for >>>> the host runtime (x86) and then filtering out some of these methods >>>> from being intrinsified based on the value of a config parameter >>>> (e.g., config.usePopCountIinstruction, config.useAESIntrinsics, etc.). >>>> >>>>> >>>> >>>>> In more detail when the VM first starts up in >>>> VMToCompilerImpl.start() it gets the host runtime (which is x86) and >>>> builds a superset of intrinsics for that runtime by calling >>>> GraalMethodSubstitutions.registerReplacements( ). This in turn >>>> processes a class file MathSubstitutionsx86.class to get a list of >>>> math routines to be intrinsified, filters out some of these routines >>>> (via a call to HotSpotReplacementsImpl.registerMethodSubstitution()) >>>> and adds the remaining ones to a HashMap called >>>> registeredMethodSubstitutions. >>>> >>>>> >>>> >>>>> For the case of supporting multiple GPU targets, it sounds like >>>>> this >>>> logic is the reverse of what we need. Instead of building a superset >>>> of intrinsics for x86 and filtering them for the target runtime, we >>>> need a way for each target runtime (e.g., HSAIL) to specify its own >>>> list of supported intrinsics. Has anyone thought about how this >>>> should be handled? >>>> >>>>> >>>> >>>>> Vasanth >>>> >>>>> >>>> >>> >> >> > > From tom.deneau at amd.com Thu Oct 17 12:40:12 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 17 Oct 2013 19:40:12 +0000 Subject: emit vs. visit in LIR interface Message-ID: Say you've defined a new XxxNode and a LoweredXxxNode version also. In the generate method for the LoweredXxxNode, what determines whether one should a) define a emitXxx in the LIRGenerator interface, do the parsing work in the LoweredXxxNode.generate method itself, and then call gen.emitXXX (like for example the say BitCountNode.generate works) b) define a visitXxx routine as part of the LIRGenerator interface, and the LoweredXxxNode.generate basically just calls gen.visitXxx(LoweredXxxNode) and do the real work in the visitXxx (like for example VisitCompareAndSwap) -- Tom From doug.simon at oracle.com Thu Oct 17 13:55:49 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 17 Oct 2013 22:55:49 +0200 Subject: emit vs. visit in LIR interface In-Reply-To: References: Message-ID: <52604ED5.2050408@oracle.com> On 10/17/2013 09:40 PM, Deneau, Tom wrote: > Say you've defined a new XxxNode and a LoweredXxxNode version also. > In the generate method for the LoweredXxxNode, what determines whether one should > > a) define a emitXxx in the LIRGenerator interface, do the parsing work in the LoweredXxxNode.generate method itself, and then call gen.emitXXX (like for example the say BitCountNode.generate works) > > b) define a visitXxx routine as part of the LIRGenerator interface, and the LoweredXxxNode.generate basically just calls gen.visitXxx(LoweredXxxNode) and do the real work in the visitXxx (like for example VisitCompareAndSwap) Or: c) For a backend-specific node, cast the LIRGenerator/LIRGeneratorTool parameter in LoweredXxxNode.generate() to a backend-specific generator interface and call a backend-specific emitXXX method. Look at PatchReturnAddressNode or JumpToExceptionHandlerInCallerNode. I'm assuming c) matches your use case. -Doug From Vasanth.Venkatachalam at amd.com Fri Oct 18 08:39:42 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Fri, 18 Oct 2013 15:39:42 +0000 Subject: bitwise operator support webrev Message-ID: <5DD1503F815BD14889DC81D28643E3A7553A7CE3@SATLEXDAG02.amd.com> Hi, I've uploaded a webrev that extends the HSAIL backend to generate code for three of the bitwise logical operators AND, OR and XOR. http://cr.openjdk.java.net/~tdeneau/bitwiseopsupport.03/webrev/ Please review and provide feedback. Summary: The main changes are in HSAILLIRGenerator, where I implemented the routines emitOr and emitXor which were previously throwing NYIs, and in HSAiLAssembler, where I added a routine, emitBitwiseLogical. I've added test cases to test these bitwise operations on all the primitive types that they support. There are two variants of each test case, one which casts the result of the bitwise operation to the original data type that was being operated on (e.g., byte, char, short) and another which simply returns the default return type which is an int. To support the cast operation that the new tests exercise I also had to enhance the emitConvert( ) routine in HSAILLiRGenerator to handle additional types of conversions which weren't previously supported. In particular, I2S, I2C and I2B required special handling since Graal was returning an int for the destination. This required me to refactor the emitConvert routine in the assembler into multiple routines. I've also added additional test cases to exercise the different conversion types that this webrev adds support for. Vasanth From christian.thalinger at oracle.com Fri Oct 18 09:11:52 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Oct 2013 09:11:52 -0700 Subject: bitwise operator support webrev In-Reply-To: <5DD1503F815BD14889DC81D28643E3A7553A7CE3@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A7553A7CE3@SATLEXDAG02.amd.com> Message-ID: <2CD4888D-ECC9-4397-A1F2-D889CF447FC5@oracle.com> graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILArithmetic.java: Could you remove the // @formatter:off in that file so we get proper formatting? Or at least turn it on after the enum values. You should also fix the copyright years in you new test files: 2 * Copyright (c) 2009, 2012, Oracle and/or its affiliates. All rights reserved. Use "2013, ". Otherwise this looks good. On Oct 18, 2013, at 8:39 AM, "Venkatachalam, Vasanth" wrote: > Hi, > > I've uploaded a webrev that extends the HSAIL backend to generate code for three of the bitwise logical operators AND, OR and XOR. > > http://cr.openjdk.java.net/~tdeneau/bitwiseopsupport.03/webrev/ > > Please review and provide feedback. > > Summary: > > The main changes are in HSAILLIRGenerator, where I implemented the routines emitOr and emitXor which were previously throwing NYIs, and in HSAiLAssembler, where I added a routine, emitBitwiseLogical. I've added test cases to test these bitwise operations on all the primitive types that they support. There are two variants of each test case, one which casts the result of the bitwise operation to the original data type that was being operated on (e.g., byte, char, short) and another which simply returns the default return type which is an int. > > To support the cast operation that the new tests exercise I also had to enhance the emitConvert( ) routine in HSAILLiRGenerator to handle additional types of conversions which weren't previously supported. In particular, I2S, I2C and I2B required special handling since Graal was returning an int for the destination. This required me to refactor the emitConvert routine in the assembler into multiple routines. I've also added additional test cases to exercise the different conversion types that this webrev adds support for. > > Vasanth > > From ndrzmansn at gmail.com Fri Oct 18 16:44:52 2013 From: ndrzmansn at gmail.com (Wei Zhang) Date: Fri, 18 Oct 2013 16:44:52 -0700 Subject: Truffle Node replacement problem caused by recursion Message-ID: Hi guys, I came across a problem with Truffle node replacement when I was trying to apply Python level inlining to binarytrees.py (one of the shootout benchmarks). I thought it is worth sharing it with all of you that are using Truffle. Basically, recursion might cause inconsistencies in a Truffle AST. That is a node's parent's children don't include itself. We all know binarytrees. This is the simplified AST that is enough to show the problem: RootNodeOfFoo Statement0 Statement1 BinaryOp Call(foo) Constant(1) When the function foo starts execution, BinaryOp node is specializing itself from the Uninitialized state by executing its two operands before it replaces itself with a specialized version. Because one of its operand is a recursive call, the deepest recursive invocation will specialized BinaryOp first. When it returns to an earlier active BinaryOp.executeAndSpecialize0(), the node replacement will fail. At that point, the children of BinaryOp have already adopted by the lastly created BinaryOpSpecialized. We end up with a situation where Call(foo)'s parent is not a child of RootNodeOfFoo. So when I try to replace the recursive call(foo) node with a inlined version, I cannot do a simple node replacement. I have to lookup the real parent that is reachable from the RootNodeOfFoo. Maybe it's not a bad idea to have some kind of failure detection of node replacement... Thanks, -------------------------- Wei Zhang Personal: NdrZmansN at Gmail.com From Vasanth.Venkatachalam at amd.com Fri Oct 18 17:55:56 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Sat, 19 Oct 2013 00:55:56 +0000 Subject: bitwise operator support webrev In-Reply-To: <2CD4888D-ECC9-4397-A1F2-D889CF447FC5@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A7553A7CE3@SATLEXDAG02.amd.com> <2CD4888D-ECC9-4397-A1F2-D889CF447FC5@oracle.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A7553A7EF7@SATLEXDAG02.amd.com> I've made the fixes you recommended. Vasanth -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Friday, October 18, 2013 11:12 AM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: Re: bitwise operator support webrev graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILArithmetic.java: Could you remove the // @formatter:off in that file so we get proper formatting? Or at least turn it on after the enum values. You should also fix the copyright years in you new test files: 2 * Copyright (c) 2009, 2012, Oracle and/or its affiliates. All rights reserved. Use "2013, ". Otherwise this looks good. On Oct 18, 2013, at 8:39 AM, "Venkatachalam, Vasanth" wrote: > Hi, > > I've uploaded a webrev that extends the HSAIL backend to generate code for three of the bitwise logical operators AND, OR and XOR. > > http://cr.openjdk.java.net/~tdeneau/bitwiseopsupport.03/webrev/ > > Please review and provide feedback. > > Summary: > > The main changes are in HSAILLIRGenerator, where I implemented the routines emitOr and emitXor which were previously throwing NYIs, and in HSAiLAssembler, where I added a routine, emitBitwiseLogical. I've added test cases to test these bitwise operations on all the primitive types that they support. There are two variants of each test case, one which casts the result of the bitwise operation to the original data type that was being operated on (e.g., byte, char, short) and another which simply returns the default return type which is an int. > > To support the cast operation that the new tests exercise I also had to enhance the emitConvert( ) routine in HSAILLiRGenerator to handle additional types of conversions which weren't previously supported. In particular, I2S, I2C and I2B required special handling since Graal was returning an int for the destination. This required me to refactor the emitConvert routine in the assembler into multiple routines. I've also added additional test cases to exercise the different conversion types that this webrev adds support for. > > Vasanth > > From doug.simon at oracle.com Sat Oct 19 01:53:23 2013 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 19 Oct 2013 10:53:23 +0200 Subject: bitwise operator support webrev In-Reply-To: <5DD1503F815BD14889DC81D28643E3A7553A7EF7@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A7553A7CE3@SATLEXDAG02.amd.com> <2CD4888D-ECC9-4397-A1F2-D889CF447FC5@oracle.com> <5DD1503F815BD14889DC81D28643E3A7553A7EF7@SATLEXDAG02.amd.com> Message-ID: <1AB4D202-6A46-44F7-81B0-649DE84A8BCE@oracle.com> Christian, Can you please integrate these changes. Thanks. -Doug On Oct 19, 2013, at 2:55 AM, "Venkatachalam, Vasanth" wrote: > I've made the fixes you recommended. > > Vasanth > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Friday, October 18, 2013 11:12 AM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: bitwise operator support webrev > > graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILArithmetic.java: > > Could you remove the // @formatter:off in that file so we get proper formatting? Or at least turn it on after the enum values. > > You should also fix the copyright years in you new test files: > > 2 * Copyright (c) 2009, 2012, Oracle and/or its affiliates. All rights reserved. > > Use "2013, ". > > Otherwise this looks good. > > On Oct 18, 2013, at 8:39 AM, "Venkatachalam, Vasanth" wrote: > >> Hi, >> >> I've uploaded a webrev that extends the HSAIL backend to generate code for three of the bitwise logical operators AND, OR and XOR. >> >> http://cr.openjdk.java.net/~tdeneau/bitwiseopsupport.03/webrev/ >> >> Please review and provide feedback. >> >> Summary: >> >> The main changes are in HSAILLIRGenerator, where I implemented the routines emitOr and emitXor which were previously throwing NYIs, and in HSAiLAssembler, where I added a routine, emitBitwiseLogical. I've added test cases to test these bitwise operations on all the primitive types that they support. There are two variants of each test case, one which casts the result of the bitwise operation to the original data type that was being operated on (e.g., byte, char, short) and another which simply returns the default return type which is an int. >> >> To support the cast operation that the new tests exercise I also had to enhance the emitConvert( ) routine in HSAILLiRGenerator to handle additional types of conversions which weren't previously supported. In particular, I2S, I2C and I2B required special handling since Graal was returning an int for the destination. This required me to refactor the emitConvert routine in the assembler into multiple routines. I've also added additional test cases to exercise the different conversion types that this webrev adds support for. >> >> Vasanth >> >> > > > From java at stefan-marr.de Sat Oct 19 09:53:31 2013 From: java at stefan-marr.de (Stefan Marr) Date: Sat, 19 Oct 2013 18:53:31 +0200 Subject: Truffle Node replacement problem caused by recursion In-Reply-To: References: Message-ID: <274BA668-5EC1-4108-B129-0A60918A313D@stefan-marr.de> Hi Wei: On 19 Oct 2013, at 01:44, Wei Zhang wrote: > Hi guys, > > I came across a problem with Truffle node replacement when I was > trying to apply Python level inlining to binarytrees.py (one of the > shootout benchmarks). I thought it is worth sharing it with all of you > that are using Truffle. > > Basically, recursion might cause inconsistencies in a Truffle AST. > That is a node's parent's children don't include itself. I had similar issues. A simple fibonacci function is a good example. The plus operation got specialized in a recursive call, and the unspecialized plus node was still on the Java call stack and tried to specialize itself after completing execution of its arguments. My solution first was based on remembering in the node that it got specialized. See [1] and [2] for the code in my nodes. However, after I switched to using the Truffle DSL, that problem went away. Don't know exactly why. And even more mysterious is a commit that was done by Andreas recently and later reverted: [3] "Truffle: fix node rewrite issue that can occur when a currently executing node is replaced in a recursive call." Not sure why it got reverted later on, but since I am not experiencing the issue anymore, I hope it is solved somehow by the Truffle DSL implementation. Best regards Stefan [1] https://github.com/smarr/TruffleSOM/blob/bf97e05836c0c9c9647b41e6da305c007ac94236/src/som/interpreter/nodes/MessageNode.java#L141 [2] https://github.com/smarr/TruffleSOM/blob/bf97e05836c0c9c9647b41e6da305c007ac94236/src/som/interpreter/nodes/MessageNode.java#L257 [3] http://hg.openjdk.java.net/graal/graal/rev/be0a33a631fa -- 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 Oct 19 18:00:28 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 20 Oct 2013 01:00:28 +0000 Subject: hg: graal/graal: 20 new changesets Message-ID: <20131020010216.726DC62579@hg.openjdk.java.net> Changeset: 237aff48d57e Author: Lukas Stadler Date: 2013-10-16 11:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/237aff48d57e fixed 5b1a2e8e82d6: make EscapeObjectState value numberable ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/EscapeObjectState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/GraphEffectList.java Changeset: f04f58c8206b Author: Doug Simon Date: 2013-10-17 14:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f04f58c8206b made HSAILCompilationResult subclass CompilationResult ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/ForEachToGraal.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/HSAILHotSpotCodeCacheProvider.java Changeset: 7022b22647ed Author: Doug Simon Date: 2013-10-17 15:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7022b22647ed Merge. Changeset: 67566565053a Author: Doug Simon Date: 2013-10-17 22:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/67566565053a made AMD64HotSpotBackendFactory more easily extensible ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackendFactory.java Changeset: a5d83166dca6 Author: Mick Jordan Date: 2013-10-17 19:59 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a5d83166dca6 mxtool hg support for suites ! mxtool/mx.py Changeset: b4b7d39cdf73 Author: Christian Wirth Date: 2013-10-18 13:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b4b7d39cdf73 Truffle: Update for the CompilationPolicy ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/CompilationPolicy.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java Changeset: 36a438ebab50 Author: Lukas Stadler Date: 2013-10-18 14:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/36a438ebab50 duplicate VirtualObjectNodes when peeling / unrolling loops ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EscapeAnalysisTest.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java Changeset: 47200418768d Author: Gilles Duboscq Date: 2013-10-17 18:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/47200418768d Small optimizations to Binary Printer and IGV's BinaryParser ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/BinaryGraphPrinter.java ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/BinaryParser.java Changeset: 45daf0d65522 Author: Gilles Duboscq Date: 2013-10-17 18:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/45daf0d65522 Replace EliminatePartiallyRedundantGuardsPhase with OptimizeGuardAnchors * OptimizeGuardAnchors implements optimization at control split in a more efficient way * OptimizeGuardAnchors ensure Guards have their optimal anchor point *** OptimizeGuardAnchors header ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ReadAfterCheckCastTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ControlSplitNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/EliminatePartiallyRedundantGuardsPhase.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/OptimizeGuardAnchors.java Changeset: f8c99c2bbb37 Author: Gilles Duboscq Date: 2013-10-17 18:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f8c99c2bbb37 Binary Graphs: use 16bits for pool indices ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/BinaryGraphPrinter.java ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/BinaryParser.java Changeset: 134671fbf973 Author: Gilles Duboscq Date: 2013-10-17 18:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/134671fbf973 Optimize Binary Graph format for more compact size ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/BinaryGraphPrinter.java ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/BinaryParser.java Changeset: 2d8a8980eda8 Author: Gilles Duboscq Date: 2013-10-17 18:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2d8a8980eda8 Canonicalize DynamicDeoptimize nodes back to Deoptimize when used with a constant reason&action ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaAccessProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMetaAccessProvider.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DynamicDeoptimizeNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: b433297f21c4 Author: Gilles Duboscq Date: 2013-10-17 18:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b433297f21c4 Conditional Elimination should not skip registering ShortCut conditions ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java Changeset: cfb89901214a Author: Gilles Duboscq Date: 2013-10-17 18:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cfb89901214a Add canonicalizations for more diamond shapes to Conditional if one of the input of the Phi is also a conditional with constants ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java Changeset: 28d7a11ba008 Author: Doug Simon Date: 2013-10-18 17:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/28d7a11ba008 revert attempt to avoid Eclipse build loops "We need a way the refresh the created jar file in Eclipse. Doing it directly in Jar.launch does not work for some reasons I still do not completely understand. So Refresh.launch is the workaround for that problem. Unfortunately the Refresh.launch needs to be async and that causes the well known build loop. Setting the Refresh.launch not to be async does sadly not help." -Christian Humer ! mxtool/mx.py Changeset: 1a4dc163cd0a Author: Doug Simon Date: 2013-10-18 18:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1a4dc163cd0a abstracted HotSpotGraalRuntime as a RuntimeProvider which removes the recent selector addition to the Graal capabilities API and also makes Truffle independent of the graal.hotspot project (GRAAL-363) ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/NameAndSignature.java ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestBytecodeDisassemblerProvider.java ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TypeUniverse.java ! graal/com.oracle.graal.api.runtime/src/com/oracle/graal/api/runtime/Graal.java ! graal/com.oracle.graal.api.runtime/src/com/oracle/graal/api/runtime/GraalRuntime.java ! graal/com.oracle.graal.asm.test/src/com/oracle/graal/asm/test/AssemblerTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BasicHSAILTest.java ! 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/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.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.test/src/com/oracle/graal/hotspot/test/CompressedOopTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/InstalledCodeExecuteHelperTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.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 ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotGraphCache.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotProviders.java ! graal/com.oracle.graal.java.decompiler.test/src/com/oracle/graal/java/decompiler/test/Test.java ! graal/com.oracle.graal.java.decompiler.test/src/com/oracle/graal/java/decompiler/test/TestUtil.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/GraphCache.java + graal/com.oracle.graal.runtime/src/com/oracle/graal/runtime/RuntimeProvider.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/ExactMathTest.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/TruffleRuntimeTest.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! 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/TruffleReplacements.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/NewFrameNode.java ! mx/projects Changeset: 0c651af30cc8 Author: Doug Simon Date: 2013-10-18 21:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0c651af30cc8 added ptx sources to hotspot Eclipse project ! hotspot/.project Changeset: 4dba97fb1a6f Author: Doug Simon Date: 2013-10-18 23:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4dba97fb1a6f available GPUs are exposed to Graal only by the graal.gpu.isalist system property which is set up during command line argument parsing ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToGPU.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToGPUImpl.java ! src/share/vm/graal/graalCompilerToGPU.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp Changeset: 11f217e8476a Author: Mick Jordan Date: 2013-10-18 15:58 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/11f217e8476a mxtool: fix command-specific option parsing regression ! mxtool/mx.py Changeset: 1499d4d73eee Author: Mick Jordan Date: 2013-10-18 15:59 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1499d4d73eee Merge From thomas.wuerthinger at oracle.com Mon Oct 21 07:10:51 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Mon, 21 Oct 2013 16:10:51 +0200 Subject: Truffle Node replacement problem caused by recursion In-Reply-To: <274BA668-5EC1-4108-B129-0A60918A313D@stefan-marr.de> References: <274BA668-5EC1-4108-B129-0A60918A313D@stefan-marr.de> Message-ID: Thanks both Wei and Stefan for describing the issue. We are currently experimenting with various possible of fixes (this is why you can see change sets being pushed and backed out again ;)). Andreas is going to post a description of the solution once we are confident that we have solved the problem. - thomas On Oct 19, 2013, at 6:53 PM, Stefan Marr wrote: > Hi Wei: > > On 19 Oct 2013, at 01:44, Wei Zhang wrote: > >> Hi guys, >> >> I came across a problem with Truffle node replacement when I was >> trying to apply Python level inlining to binarytrees.py (one of the >> shootout benchmarks). I thought it is worth sharing it with all of you >> that are using Truffle. >> >> Basically, recursion might cause inconsistencies in a Truffle AST. >> That is a node's parent's children don't include itself. > > I had similar issues. A simple fibonacci function is a good example. > The plus operation got specialized in a recursive call, and the unspecialized plus node was still on the Java call stack and tried to specialize itself after completing execution of its arguments. > > My solution first was based on remembering in the node that it got specialized. > See [1] and [2] for the code in my nodes. > > However, after I switched to using the Truffle DSL, that problem went away. Don't know exactly why. > > And even more mysterious is a commit that was done by Andreas recently and later reverted: [3] "Truffle: fix node rewrite issue that can occur when a currently executing node is replaced in a recursive call." > Not sure why it got reverted later on, but since I am not experiencing the issue anymore, I hope it is solved somehow by the Truffle DSL implementation. > > Best regards > Stefan > > [1] https://github.com/smarr/TruffleSOM/blob/bf97e05836c0c9c9647b41e6da305c007ac94236/src/som/interpreter/nodes/MessageNode.java#L141 > [2] https://github.com/smarr/TruffleSOM/blob/bf97e05836c0c9c9647b41e6da305c007ac94236/src/som/interpreter/nodes/MessageNode.java#L257 > > [3] http://hg.openjdk.java.net/graal/graal/rev/be0a33a631fa > > -- > 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 Vasanth.Venkatachalam at amd.com Mon Oct 21 08:50:40 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Mon, 21 Oct 2013 15:50:40 +0000 Subject: bitwise operator support webrev Message-ID: <5DD1503F815BD14889DC81D28643E3A7553A93A9@SATLEXDAG02.amd.com> Doug and Christian, If there are no further edits required, please integrate this webrev into the Graal OpenJDK repository. Please attribute the changes to Vasanth Venkatachalam. Commit message: Adds support to the HSAIL backend for three of the bitwise logical operators, bitwise AND, bitwise OR and bitwise XOR. Thanks. Vasanth -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Saturday, October 19, 2013 3:53 AM To: Christian Thalinger Cc: graal-dev at openjdk.java.net; Venkatachalam, Vasanth Subject: Re: bitwise operator support webrev Christian, Can you please integrate these changes. Thanks. -Doug On Oct 19, 2013, at 2:55 AM, "Venkatachalam, Vasanth" wrote: > I've made the fixes you recommended. > > Vasanth > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Friday, October 18, 2013 11:12 AM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: bitwise operator support webrev > > graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILArithmetic.java: > > Could you remove the // @formatter:off in that file so we get proper formatting? Or at least turn it on after the enum values. > > You should also fix the copyright years in you new test files: > > 2 * Copyright (c) 2009, 2012, Oracle and/or its affiliates. All rights reserved. > > Use "2013, ". > > Otherwise this looks good. > > On Oct 18, 2013, at 8:39 AM, "Venkatachalam, Vasanth" wrote: > >> Hi, >> >> I've uploaded a webrev that extends the HSAIL backend to generate code for three of the bitwise logical operators AND, OR and XOR. >> >> http://cr.openjdk.java.net/~tdeneau/bitwiseopsupport.03/webrev/ >> >> Please review and provide feedback. >> >> Summary: >> >> The main changes are in HSAILLIRGenerator, where I implemented the routines emitOr and emitXor which were previously throwing NYIs, and in HSAiLAssembler, where I added a routine, emitBitwiseLogical. I've added test cases to test these bitwise operations on all the primitive types that they support. There are two variants of each test case, one which casts the result of the bitwise operation to the original data type that was being operated on (e.g., byte, char, short) and another which simply returns the default return type which is an int. >> >> To support the cast operation that the new tests exercise I also had to enhance the emitConvert( ) routine in HSAILLiRGenerator to handle additional types of conversions which weren't previously supported. In particular, I2S, I2C and I2B required special handling since Graal was returning an int for the destination. This required me to refactor the emitConvert routine in the assembler into multiple routines. I've also added additional test cases to exercise the different conversion types that this webrev adds support for. >> >> Vasanth >> >> > > > From Vasanth.Venkatachalam at amd.com Mon Oct 21 10:21:15 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Mon, 21 Oct 2013 17:21:15 +0000 Subject: hsail test case failures in the latest tip Message-ID: <5DD1503F815BD14889DC81D28643E3A7553A93EB@SATLEXDAG02.amd.com> Doug- There are a couple of HSAIL test cases that are failing on the latest tip, namely hsail.test.StaticNBodyCallTest and hsail.test.StringContainsAcceptTest. These test cases were passing as of rev 12895, which was uploaded around a week before the refactoring changes that you checked in. Can you examine which got checked in that's causing these tests to fail? Vasanth From christian.thalinger at oracle.com Mon Oct 21 10:28:25 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 21 Oct 2013 10:28:25 -0700 Subject: bitwise operator support webrev In-Reply-To: <5DD1503F815BD14889DC81D28643E3A7553A93A9@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A7553A93A9@SATLEXDAG02.amd.com> Message-ID: <68EF8B58-29D3-4CC4-86BD-B577C97FAF1F@oracle.com> Will do. On Oct 21, 2013, at 8:50 AM, "Venkatachalam, Vasanth" wrote: > Doug and Christian, > > If there are no further edits required, please integrate this webrev into the Graal OpenJDK repository. > > Please attribute the changes to Vasanth Venkatachalam. > > Commit message: Adds support to the HSAIL backend for three of the bitwise logical operators, bitwise AND, bitwise OR and bitwise XOR. > > Thanks. > > Vasanth > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Saturday, October 19, 2013 3:53 AM > To: Christian Thalinger > Cc: graal-dev at openjdk.java.net; Venkatachalam, Vasanth > Subject: Re: bitwise operator support webrev > > Christian, > > Can you please integrate these changes. Thanks. > > -Doug > > On Oct 19, 2013, at 2:55 AM, "Venkatachalam, Vasanth" wrote: > >> I've made the fixes you recommended. >> >> Vasanth >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Friday, October 18, 2013 11:12 AM >> To: Venkatachalam, Vasanth >> Cc: graal-dev at openjdk.java.net >> Subject: Re: bitwise operator support webrev >> >> graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILArithmetic.java: >> >> Could you remove the // @formatter:off in that file so we get proper formatting? Or at least turn it on after the enum values. >> >> You should also fix the copyright years in you new test files: >> >> 2 * Copyright (c) 2009, 2012, Oracle and/or its affiliates. All rights reserved. >> >> Use "2013, ". >> >> Otherwise this looks good. >> >> On Oct 18, 2013, at 8:39 AM, "Venkatachalam, Vasanth" wrote: >> >>> Hi, >>> >>> I've uploaded a webrev that extends the HSAIL backend to generate code for three of the bitwise logical operators AND, OR and XOR. >>> >>> http://cr.openjdk.java.net/~tdeneau/bitwiseopsupport.03/webrev/ >>> >>> Please review and provide feedback. >>> >>> Summary: >>> >>> The main changes are in HSAILLIRGenerator, where I implemented the routines emitOr and emitXor which were previously throwing NYIs, and in HSAiLAssembler, where I added a routine, emitBitwiseLogical. I've added test cases to test these bitwise operations on all the primitive types that they support. There are two variants of each test case, one which casts the result of the bitwise operation to the original data type that was being operated on (e.g., byte, char, short) and another which simply returns the default return type which is an int. >>> >>> To support the cast operation that the new tests exercise I also had to enhance the emitConvert( ) routine in HSAILLiRGenerator to handle additional types of conversions which weren't previously supported. In particular, I2S, I2C and I2B required special handling since Graal was returning an int for the destination. This required me to refactor the emitConvert routine in the assembler into multiple routines. I've also added additional test cases to exercise the different conversion types that this webrev adds support for. >>> >>> Vasanth >>> >>> >> >> >> > > > From doug.simon at oracle.com Mon Oct 21 11:16:23 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 21 Oct 2013 20:16:23 +0200 Subject: hsail test case failures in the latest tip In-Reply-To: <5DD1503F815BD14889DC81D28643E3A7553A93EB@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A7553A93EB@SATLEXDAG02.amd.com> Message-ID: Can you please tell me how to reproduce the failures. They passed the gate as seem to pass when I run them locally: $ mx --vm server unittest StaticNBodyCallTest StringContainsAcceptTest executing junit tests now... (2 test classes) JUnit version 4.8 .. Time: 0.009 OK (2 tests) -Doug On Oct 21, 2013, at 7:21 PM, "Venkatachalam, Vasanth" wrote: > Doug- > > There are a couple of HSAIL test cases that are failing on the latest tip, namely hsail.test.StaticNBodyCallTest and hsail.test.StringContainsAcceptTest. > These test cases were passing as of rev 12895, which was uploaded around a week before the refactoring changes that you checked in. > > Can you examine which got checked in that?s causing these tests to fail? > > Vasanth > > > From doug.simon at oracle.com Mon Oct 21 11:27:14 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 21 Oct 2013 20:27:14 +0200 Subject: Code must (soon) comply with Eclipse formatting command References: Message-ID: <3BAD7365-0CCB-4143-8395-7D90E707C3C2@oracle.com> The bugs preventing the Eclipse formatter from being used from the command line seem to have been fixed as of Eclipse 4.3[1]. As such, we will soon add a check in the gate that all incoming code is formatted according to this tool. If you are using Eclipse for development, this should not be a problem. If not, you should run the following before trying to push or submit a webrev: $ mx eclipseformat -e /path/to/eclipse4.3installation If this command reports that 0 files were modified, your changes should get through (this part of) the gate. -Doug [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=405338 From tom.deneau at amd.com Mon Oct 21 15:18:11 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 21 Oct 2013 22:18:11 +0000 Subject: non-foreign-call tlab refill from hsail Message-ID: We are experimenting with object (and array) allocation from an HSA device (using graal for the HSAIL codegen). Where we are now: * the hsa workitems are using TLABs from "donor threads" who exist just to supply TLABs and don't do any allocation themselves. * To reduce the number of donor threads required, a TLAB can be used by more than one workitem, in which case the workitems use HSAIL atomic_add instructions to bump the tlab top pointer. * the HSAIL backend has its own fastpath allocation snippets which generate the HSAIL atomic_add instructions which override the snippets in NewObjectSnippets.java Some junit tests have been written and pass which allocate objects, or arrays of primitives, or arrays of objects. All the above only works for the fastpath case, i.e., if there is indeed enough space in the donor TLAB. We realize there are other cases: a) not enough space in current TLAB but ability to allocate a new TLAB. b) not able to allocate a new TLAB, GC required. For only case a) above, we would like to experiment with grabbing the new TLAB from HSAIL without making a "foreign call" to the VM. From the hotspot code, I assume the logic required is what one sees in mutableSpace::cas_allocate(size_t size) at least for the non-G1 case. Some of this non-foreign-call allocation logic appears to exist in the Snippet called NewInstanceStub.newInstance (as opposed to NewObjectSnippets.allocateInstance snippet which is what we are currently overriding). This comments for this snippet say "Re-attempts allocation after an initial TLAB allocation failed or was skipped (e.g., due to * -XX:-UseTLAB)." Is this NewInstanceStub.newInstance snippet actually used anywhere in the current graal framework. Is this a starting point we could use to get a non-foreign-call TLAB refill working? Or is this a path we should not even try to go down? -- Tom From Vasanth.Venkatachalam at amd.com Mon Oct 21 20:02:01 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Tue, 22 Oct 2013 03:02:01 +0000 Subject: hsail test case failures in the latest tip In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A7553A93EB@SATLEXDAG02.amd.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A7553A957C@SATLEXDAG02.amd.com> Doug, Please try running with -G:+InlineEverything -G:-RemoveNeverExecutedCode Vasanth -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Monday, October 21, 2013 1:16 PM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: Re: hsail test case failures in the latest tip Can you please tell me how to reproduce the failures. They passed the gate as seem to pass when I run them locally: $ mx --vm server unittest StaticNBodyCallTest StringContainsAcceptTest executing junit tests now... (2 test classes) JUnit version 4.8 .. Time: 0.009 OK (2 tests) -Doug On Oct 21, 2013, at 7:21 PM, "Venkatachalam, Vasanth" wrote: > Doug- > > There are a couple of HSAIL test cases that are failing on the latest tip, namely hsail.test.StaticNBodyCallTest and hsail.test.StringContainsAcceptTest. > These test cases were passing as of rev 12895, which was uploaded around a week before the refactoring changes that you checked in. > > Can you examine which got checked in that's causing these tests to fail? > > Vasanth > > > From christian.thalinger at oracle.com Mon Oct 21 20:44:35 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 21 Oct 2013 20:44:35 -0700 Subject: Code must (soon) comply with Eclipse formatting command In-Reply-To: <3BAD7365-0CCB-4143-8395-7D90E707C3C2@oracle.com> References: <3BAD7365-0CCB-4143-8395-7D90E707C3C2@oracle.com> Message-ID: Nice! On Oct 21, 2013, at 11:27 AM, Doug Simon wrote: > The bugs preventing the Eclipse formatter from being used from the command line seem to have been fixed as of Eclipse 4.3[1]. As such, we will soon add a check in the gate that all incoming code is formatted according to this tool. If you are using Eclipse for development, this should not be a problem. If not, you should run the following before trying to push or submit a webrev: > > $ mx eclipseformat -e /path/to/eclipse4.3installation > > If this command reports that 0 files were modified, your changes should get through (this part of) the gate. > > -Doug > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=405338 From doug.simon at oracle.com Tue Oct 22 02:36:28 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 22 Oct 2013 11:36:28 +0200 Subject: hsail test case failures in the latest tip In-Reply-To: <5DD1503F815BD14889DC81D28643E3A7553A957C@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A7553A93EB@SATLEXDAG02.amd.com> <5DD1503F815BD14889DC81D28643E3A7553A957C@SATLEXDAG02.amd.com> Message-ID: As indicated by the exceptions raised by these tests (e.g., below), you need to fix the incomplete/incorrect HSAILLIRGenerator and HSAILHotSpotForeignCallsProvider classes. -Doug 1) test(com.oracle.graal.compiler.hsail.test.StaticNBodyCallTest) com.oracle.graal.graph.GraalInternalError: unimplemented at node: 504|Invoke#Direct#sqrt at com.oracle.graal.graph.GraalInternalError.unimplemented(GraalInternalError.java:38) at com.oracle.graal.compiler.hsail.HSAILLIRGenerator.emitDirectCall(HSAILLIRGenerator.java:553) at com.oracle.graal.compiler.gen.LIRGenerator.emitInvoke(LIRGenerator.java:579) at com.oracle.graal.nodes.InvokeWithExceptionNode.generate(InvokeWithExceptionNode.java:137) at com.oracle.graal.compiler.gen.LIRGenerator.emitNode(LIRGenerator.java:387) at com.oracle.graal.compiler.gen.LIRGenerator.doRoot(LIRGenerator.java:376) at com.oracle.graal.compiler.gen.LIRGenerator.doBlock(LIRGenerator.java:327) at com.oracle.graal.compiler.GraalCompiler$3.emitBlock(GraalCompiler.java:259) at com.oracle.graal.compiler.GraalCompiler$3.run(GraalCompiler.java:246) at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:258) at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:245) at com.oracle.graal.debug.Debug.scope(Debug.java:164) at com.oracle.graal.debug.Debug.scope(Debug.java:159) at com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:242) at com.oracle.graal.compiler.GraalCompiler$1$2.call(GraalCompiler.java:154) at com.oracle.graal.compiler.GraalCompiler$1$2.call(GraalCompiler.java:1) at com.oracle.graal.debug.internal.DebugScope.call(DebugScope.java:383) ... 2) test(com.oracle.graal.compiler.hsail.test.StringContainsAcceptTest) com.oracle.graal.graph.GraalInternalError: unimplemented: createOutOfBoundsException(int)Object at node: 312|ForeignCall#createOutOfBoundsException(int)Object at com.oracle.graal.graph.GraalInternalError.unimplemented(GraalInternalError.java:42) at com.oracle.graal.hotspot.hsail.HSAILHotSpotForeignCallsProvider.lookupForeignCall(HSAILHotSpotForeignCallsProvider.java:52) at com.oracle.graal.nodes.extended.ForeignCallNode.generate(ForeignCallNode.java:82) at com.oracle.graal.compiler.gen.LIRGenerator.emitNode(LIRGenerator.java:387) at com.oracle.graal.compiler.gen.LIRGenerator.doRoot(LIRGenerator.java:376) at com.oracle.graal.compiler.gen.LIRGenerator.doBlock(LIRGenerator.java:327) at com.oracle.graal.compiler.GraalCompiler$3.emitBlock(GraalCompiler.java:259) at com.oracle.graal.compiler.GraalCompiler$3.run(GraalCompiler.java:246) ... On Oct 22, 2013, at 5:02 AM, "Venkatachalam, Vasanth" wrote: > Doug, > > Please try running with -G:+InlineEverything -G:-RemoveNeverExecutedCode > > Vasanth > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Monday, October 21, 2013 1:16 PM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: hsail test case failures in the latest tip > > Can you please tell me how to reproduce the failures. They passed the gate as seem to pass when I run them locally: > > $ mx --vm server unittest StaticNBodyCallTest StringContainsAcceptTest executing junit tests now... (2 test classes) JUnit version 4.8 .. > Time: 0.009 > > OK (2 tests) > > -Doug > > On Oct 21, 2013, at 7:21 PM, "Venkatachalam, Vasanth" wrote: > >> Doug- >> >> There are a couple of HSAIL test cases that are failing on the latest tip, namely hsail.test.StaticNBodyCallTest and hsail.test.StringContainsAcceptTest. >> These test cases were passing as of rev 12895, which was uploaded around a week before the refactoring changes that you checked in. >> >> Can you examine which got checked in that's causing these tests to fail? >> >> Vasanth >> >> >> > > > From doug.simon at oracle.com Tue Oct 22 02:41:44 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 22 Oct 2013 11:41:44 +0200 Subject: non-foreign-call tlab refill from hsail In-Reply-To: References: Message-ID: <33F60C70-33F8-40F6-AE82-DD817293856C@oracle.com> On Oct 22, 2013, at 12:18 AM, "Deneau, Tom" wrote: > We are experimenting with object (and array) allocation from an HSA device (using graal for > > the HSAIL codegen). Where we are now: > > > > * the hsa workitems are using TLABs from "donor threads" who exist > > just to supply TLABs and don't do any allocation themselves. > > > > * To reduce the number of donor threads required, a TLAB can be > > used by more than one workitem, in which case the workitems use > > HSAIL atomic_add instructions to bump the tlab top pointer. > > > > * the HSAIL backend has its own fastpath allocation snippets > > which generate the HSAIL atomic_add instructions which > > override the snippets in NewObjectSnippets.java > > > > Some junit tests have been written and pass which allocate objects, or arrays of primitives, or arrays of objects. > > > > All the above only works for the fastpath case, i.e., if there is indeed enough space in the donor TLAB. We realize there are other cases: > > > > a) not enough space in current TLAB but ability to allocate a new TLAB. > > > > b) not able to allocate a new TLAB, GC required. > > > > For only case a) above, we would like to experiment with grabbing the new TLAB from HSAIL without making a "foreign call" to the VM. From the hotspot code, I assume the logic required is what one sees in > > mutableSpace::cas_allocate(size_t size) at least for the non-G1 case. When the NewInstanceStub fails to allocate a new TLAB, it calls out to GraalRuntime::new_instance (in graalRuntime.cpp). > Some of this non-foreign-call allocation logic appears to exist in the Snippet called NewInstanceStub.newInstance (as opposed to NewObjectSnippets.allocateInstance snippet which is what we are currently overriding). This comments for this snippet say > > "Re-attempts allocation after an initial TLAB allocation failed or > > was skipped (e.g., due to * -XX:-UseTLAB)." > > > > Is this NewInstanceStub.newInstance snippet actually used anywhere in the current graal framework. Yes, you can see a call to NewInstanceStubCall in NewObjectSnippets.allocateInstance. > Is this a starting point we could use to get a non-foreign-call TLAB refill working? Yes. Note that this call *is* a foreign call (see the javadoc for ForeignCallDescriptor). -Doug From lukas.stadler at jku.at Wed Oct 23 07:36:57 2013 From: lukas.stadler at jku.at (Lukas Stadler) Date: Wed, 23 Oct 2013 16:36:57 +0200 Subject: Graal on Mavericks Message-ID: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> In case someone is trying to get Graal to compile on OS X Mavericks - I had to add the following to mx/env to make it run: COMPILER_WARNINGS_FATAL=false USE_CLANG=true LFLAGS=-Xlinker -lstdc++ If it doesn?t take too long, I suggest we wait for the relevant changes from hotspot before we implement them ourselves. - Lukas From michael.haupt at oracle.com Wed Oct 23 08:03:46 2013 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 23 Oct 2013 17:03:46 +0200 Subject: Graal on Mavericks In-Reply-To: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> References: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> Message-ID: Hi Lukas, I'm not on Mavericks (yet) and had to use the compiler warnings setting to make the latest build succeed. The problem was this: ----- Compiling .../src/gpu/ptx/vm/ptxKernelArguments.cpp cc1plus: warnings being treated as errors .../src/gpu/ptx/vm/ptxKernelArguments.cpp: In member function 'virtual void PTXKernelArguments::do_float()': .../src/gpu/ptx/vm/ptxKernelArguments.cpp:102: warning: converting to 'long long unsigned int' from 'jfloat' .../src/gpu/ptx/vm/ptxKernelArguments.cpp: In member function 'virtual void PTXKernelArguments::do_double()': .../src/gpu/ptx/vm/ptxKernelArguments.cpp:137: warning: converting to 'long long unsigned int' from 'jdouble' Compiling .../src/share/vm/utilities/quickSort.cpp Compiling .../src/share/vm/memory/referencePolicy.cpp make[4]: *** [ptxKernelArguments.o] Error 1 make[4]: *** Waiting for unfinished jobs.... make[3]: *** [the_vm] Error 2 make[2]: *** [product] Error 2 make[1]: *** [generic_build2] Error 2 make: *** [product] Error 2 ----- Best, Michael Am 23.10.2013 um 16:36 schrieb Lukas Stadler : > In case someone is trying to get Graal to compile on OS X Mavericks - I had to add the following to mx/env to make it run: > > COMPILER_WARNINGS_FATAL=false > USE_CLANG=true > LFLAGS=-Xlinker -lstdc++ > > If it doesn?t take too long, I suggest we wait for the relevant changes from hotspot before we implement them ourselves. > > - Lukas -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From mick.jordan at oracle.com Wed Oct 23 09:03:18 2013 From: mick.jordan at oracle.com (Mick Jordan) Date: Wed, 23 Oct 2013 09:03:18 -0700 Subject: Graal on Mavericks In-Reply-To: References: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> Message-ID: <5267F346.4080107@oracle.com> On 10/23/13 8:03 AM, Michael Haupt wrote: > Hi Lukas, > > I'm not on Mavericks (yet) and had to use the compiler warnings setting to make the latest build succeed. The problem was this: Indeed, I suffered this yesterday also on M. Lion. Glad to know we have a fix. > > ----- > Compiling .../src/gpu/ptx/vm/ptxKernelArguments.cpp > cc1plus: warnings being treated as errors > > .../src/gpu/ptx/vm/ptxKernelArguments.cpp: In member function 'virtual void PTXKernelArguments::do_float()': > > .../src/gpu/ptx/vm/ptxKernelArguments.cpp:102: warning: converting to 'long long unsigned int' from 'jfloat' > > .../src/gpu/ptx/vm/ptxKernelArguments.cpp: In member function 'virtual void PTXKernelArguments::do_double()': > > .../src/gpu/ptx/vm/ptxKernelArguments.cpp:137: warning: converting to 'long long unsigned int' from 'jdouble' > > Compiling .../src/share/vm/utilities/quickSort.cpp > Compiling .../src/share/vm/memory/referencePolicy.cpp > make[4]: *** [ptxKernelArguments.o] Error 1 > > make[4]: *** Waiting for unfinished jobs.... > > make[3]: *** [the_vm] Error 2 > > make[2]: *** [product] Error 2 > > make[1]: *** [generic_build2] Error 2 > > make: *** [product] Error 2 > ----- > > Best, > > Michael > > Am 23.10.2013 um 16:36 schrieb Lukas Stadler : > >> In case someone is trying to get Graal to compile on OS X Mavericks - I had to add the following to mx/env to make it run: >> >> COMPILER_WARNINGS_FATAL=false >> USE_CLANG=true >> LFLAGS=-Xlinker -lstdc++ >> >> If it doesn?t take too long, I suggest we wait for the relevant changes from hotspot before we implement them ourselves. >> >> - Lukas From lukas.stadler at jku.at Wed Oct 23 09:16:37 2013 From: lukas.stadler at jku.at (Lukas Stadler) Date: Wed, 23 Oct 2013 18:16:37 +0200 Subject: Graal on Mavericks In-Reply-To: <5267F346.4080107@oracle.com> References: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> <5267F346.4080107@oracle.com> Message-ID: That should probably be fixed in the ptx code - it's not going to be fixed from upstream :-) I?ll take a look. - Lukas On 23 Oct 2013, at 18:03, Mick Jordan wrote: > On 10/23/13 8:03 AM, Michael Haupt wrote: >> Hi Lukas, >> >> I'm not on Mavericks (yet) and had to use the compiler warnings setting to make the latest build succeed. The problem was this: > Indeed, I suffered this yesterday also on M. Lion. Glad to know we have a fix. >> >> ----- >> Compiling .../src/gpu/ptx/vm/ptxKernelArguments.cpp >> cc1plus: warnings being treated as errors >> >> .../src/gpu/ptx/vm/ptxKernelArguments.cpp: In member function 'virtual void PTXKernelArguments::do_float()': >> >> .../src/gpu/ptx/vm/ptxKernelArguments.cpp:102: warning: converting to 'long long unsigned int' from 'jfloat' >> >> .../src/gpu/ptx/vm/ptxKernelArguments.cpp: In member function 'virtual void PTXKernelArguments::do_double()': >> >> .../src/gpu/ptx/vm/ptxKernelArguments.cpp:137: warning: converting to 'long long unsigned int' from 'jdouble' >> >> Compiling .../src/share/vm/utilities/quickSort.cpp >> Compiling .../src/share/vm/memory/referencePolicy.cpp >> make[4]: *** [ptxKernelArguments.o] Error 1 >> >> make[4]: *** Waiting for unfinished jobs.... >> >> make[3]: *** [the_vm] Error 2 >> >> make[2]: *** [product] Error 2 >> >> make[1]: *** [generic_build2] Error 2 >> >> make: *** [product] Error 2 >> ----- >> >> Best, >> >> Michael >> >> Am 23.10.2013 um 16:36 schrieb Lukas Stadler : >> >>> In case someone is trying to get Graal to compile on OS X Mavericks - I had to add the following to mx/env to make it run: >>> >>> COMPILER_WARNINGS_FATAL=false >>> USE_CLANG=true >>> LFLAGS=-Xlinker -lstdc++ >>> >>> If it doesn?t take too long, I suggest we wait for the relevant changes from hotspot before we implement them ourselves. >>> >>> - Lukas > From tom.deneau at amd.com Wed Oct 23 10:06:04 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 23 Oct 2013 17:06:04 +0000 Subject: hsail test case failures in the latest tip, mathSubstitutions In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A7553A93EB@SATLEXDAG02.amd.com> <5DD1503F815BD14889DC81D28643E3A7553A957C@SATLEXDAG02.amd.com> Message-ID: Doug or others -- Vasanth is out this week so I am trying to get the HSAIL backend working with this new infrastructure. A specific problem we are having, previously we had a replacement for Math.sqrt(double) to MathSubstitutionsX86.sqrt(double) which was I think just inherited from AMD64HotSpotRuntime. (In the HSAIL LIR and assembler then, we emitted the HSAIL instruction from the MathIntrinsicNode). What is the right way to get just that one substitution working in the new framework? (Once we get that working, we can then add additional substitutions as needed). I can see that HSAILHotSpotReplacementsUtil needs some methods to be implemented (perhaps deferring to its parent), but for the substitution class itself, am not sure of whether new files should be created, or we should reuse existing MathSubstitutions. -- Tom -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon Sent: Tuesday, October 22, 2013 4:36 AM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: Re: hsail test case failures in the latest tip As indicated by the exceptions raised by these tests (e.g., below), you need to fix the incomplete/incorrect HSAILLIRGenerator and HSAILHotSpotForeignCallsProvider classes. -Doug 1) test(com.oracle.graal.compiler.hsail.test.StaticNBodyCallTest) com.oracle.graal.graph.GraalInternalError: unimplemented at node: 504|Invoke#Direct#sqrt at com.oracle.graal.graph.GraalInternalError.unimplemented(GraalInternalError.java:38) at com.oracle.graal.compiler.hsail.HSAILLIRGenerator.emitDirectCall(HSAILLIRGenerator.java:553) at com.oracle.graal.compiler.gen.LIRGenerator.emitInvoke(LIRGenerator.java:579) at com.oracle.graal.nodes.InvokeWithExceptionNode.generate(InvokeWithExceptionNode.java:137) at com.oracle.graal.compiler.gen.LIRGenerator.emitNode(LIRGenerator.java:387) at com.oracle.graal.compiler.gen.LIRGenerator.doRoot(LIRGenerator.java:376) at com.oracle.graal.compiler.gen.LIRGenerator.doBlock(LIRGenerator.java:327) at com.oracle.graal.compiler.GraalCompiler$3.emitBlock(GraalCompiler.java:259) at com.oracle.graal.compiler.GraalCompiler$3.run(GraalCompiler.java:246) at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:258) at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:245) at com.oracle.graal.debug.Debug.scope(Debug.java:164) at com.oracle.graal.debug.Debug.scope(Debug.java:159) at com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:242) at com.oracle.graal.compiler.GraalCompiler$1$2.call(GraalCompiler.java:154) at com.oracle.graal.compiler.GraalCompiler$1$2.call(GraalCompiler.java:1) at com.oracle.graal.debug.internal.DebugScope.call(DebugScope.java:383) ... 2) test(com.oracle.graal.compiler.hsail.test.StringContainsAcceptTest) com.oracle.graal.graph.GraalInternalError: unimplemented: createOutOfBoundsException(int)Object at node: 312|ForeignCall#createOutOfBoundsException(int)Object at com.oracle.graal.graph.GraalInternalError.unimplemented(GraalInternalError.java:42) at com.oracle.graal.hotspot.hsail.HSAILHotSpotForeignCallsProvider.lookupForeignCall(HSAILHotSpotForeignCallsProvider.java:52) at com.oracle.graal.nodes.extended.ForeignCallNode.generate(ForeignCallNode.java:82) at com.oracle.graal.compiler.gen.LIRGenerator.emitNode(LIRGenerator.java:387) at com.oracle.graal.compiler.gen.LIRGenerator.doRoot(LIRGenerator.java:376) at com.oracle.graal.compiler.gen.LIRGenerator.doBlock(LIRGenerator.java:327) at com.oracle.graal.compiler.GraalCompiler$3.emitBlock(GraalCompiler.java:259) at com.oracle.graal.compiler.GraalCompiler$3.run(GraalCompiler.java:246) ... On Oct 22, 2013, at 5:02 AM, "Venkatachalam, Vasanth" wrote: > Doug, > > Please try running with -G:+InlineEverything -G:-RemoveNeverExecutedCode > > Vasanth > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Monday, October 21, 2013 1:16 PM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: hsail test case failures in the latest tip > > Can you please tell me how to reproduce the failures. They passed the gate as seem to pass when I run them locally: > > $ mx --vm server unittest StaticNBodyCallTest StringContainsAcceptTest executing junit tests now... (2 test classes) JUnit version 4.8 .. > Time: 0.009 > > OK (2 tests) > > -Doug > > On Oct 21, 2013, at 7:21 PM, "Venkatachalam, Vasanth" wrote: > >> Doug- >> >> There are a couple of HSAIL test cases that are failing on the latest tip, namely hsail.test.StaticNBodyCallTest and hsail.test.StringContainsAcceptTest. >> These test cases were passing as of rev 12895, which was uploaded around a week before the refactoring changes that you checked in. >> >> Can you examine which got checked in that's causing these tests to fail? >> >> Vasanth >> >> >> > > > From doug.simon at oracle.com Thu Oct 24 08:09:00 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 24 Oct 2013 15:09:00 +0000 Subject: hg: graal/graal: 65 new changesets Message-ID: <20131024151405.0DB7D626DA@hg.openjdk.java.net> Changeset: 0276bea0f72f Author: Andreas Woess Date: 2013-10-20 01:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0276bea0f72f Backed out changeset: edb2e6bd6a01 (superseded by ce5e6f9075b6) ! make/windows/makefiles/projectcreator.make Changeset: 57b8a41c0e18 Author: Andreas Woess Date: 2013-10-20 03:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/57b8a41c0e18 Truffle: fix possible node rewrite failures after recursive calls. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java Changeset: b7c8b843dc7b Author: Andreas Woess Date: 2013-10-20 03:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b7c8b843dc7b Truffle: add sanity check. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java Changeset: c82ed607fada Author: Bernhard Urban Date: 2013-10-21 16:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c82ed607fada FloatingReadNode: simplify assert condition ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatingReadNode.java Changeset: 98caa3872d83 Author: Bernhard Urban Date: 2013-10-21 16:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/98caa3872d83 gate: clean and build IGV (not GV) ! mx/commands.py Changeset: d00c31d8394f Author: Christos Kotselidis Date: 2013-10-21 17:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d00c31d8394f Flush deferred barrier when Graal and G1 are used ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: 249c54db0276 Author: Christos Kotselidis Date: 2013-10-21 17:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/249c54db0276 Merge Changeset: 0806a46dced5 Author: Doug Simon Date: 2013-10-21 17:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0806a46dced5 workaround for bug in Clang 5.0 ! make/bsd/makefiles/gcc.make Changeset: 128bf29518a0 Author: Doug Simon Date: 2013-10-21 17:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/128bf29518a0 added limited ability for one HotSpotBackendFactory to override another ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java Changeset: 28f56bf7c06a Author: Doug Simon Date: 2013-10-21 17:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/28f56bf7c06a added support code for Truffle to inject special tail-call code into the prefix of OptimizedCallTarget.call(PackedFrame, Arguments) ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.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 ! mx/projects Changeset: d7f8dd4fe876 Author: Doug Simon Date: 2013-10-21 18:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d7f8dd4fe876 minor reformatting based on 'mx eclipseformat' ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ExternalCompilationResult.java ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ArrayPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ControlPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/IntegerPTXTest.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotRegisterConfig.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/SPARCHotSpotDeoptimizeCallerOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopyNode.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.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/HSAILMove.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/PTXMemOp.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/ParallelOver.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/ThreadDimension.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/Warp.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/SPARCControlFlow.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRIntrospection.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/TargetMethodAssembler.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BeginStateSplitNode.java ! graal/com.oracle.graal.ptx/src/com/oracle/graal/ptx/PTX.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/MethodSubstitutionTest.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/NodeParser.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Parser.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/Scanner.java Changeset: 1d68b3962a10 Author: Doug Simon Date: 2013-10-21 18:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1d68b3962a10 applied autoformat ! mxtool/mx.py Changeset: 0b0e60214f49 Author: Doug Simon Date: 2013-10-21 18:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0b0e60214f49 Merge. Changeset: 1be3cb11f88e Author: Doug Simon Date: 2013-10-21 22:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1be3cb11f88e enable zero-count metrics to be shown (disable with new -G:+SuppressZeroDebugValues option) ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalDebugConfig.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/MetricImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: d72864a2886e Author: Doug Simon Date: 2013-10-21 22:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d72864a2886e moved snippet timers/metrics from SnippetTemplate to SnippetInfo and added new metric for number of snippet specializations (i.e. number of SnippetTemplate objects created) ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 5cde653f58f9 Author: Mick Jordan Date: 2013-10-21 15:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5cde653f58f9 mxtool: handle missing hg executable gracefully ! mxtool/mx.py Changeset: bddf5ae62522 Author: Christos Kotselidis Date: 2013-10-22 09:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bddf5ae62522 Disable deferred init barriers ! src/share/vm/graal/graalGlobals.hpp Changeset: 11dc3108904f Author: Gilles Duboscq Date: 2013-10-22 10:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/11dc3108904f Fix NodeClass.getFirstLevel(Input|Successor)Positions to use the NODE_LIST constant instead of 0 ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 9e33b386281e Author: Gilles Duboscq Date: 2013-10-22 10:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9e33b386281e Small refactoring of edge dumping in BinaryGraphPrinter ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/BinaryGraphPrinter.java Changeset: 21aa1ce5c666 Author: Doug Simon Date: 2013-10-22 11:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/21aa1ce5c666 made hg be called lazily ! mxtool/mx.py Changeset: bb665959fb12 Author: Doug Simon Date: 2013-10-22 11:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bb665959fb12 commented out eager initialization of Suite.version ! mxtool/mx.py Changeset: 8c64f10f86b7 Author: Doug Simon Date: 2013-10-22 11:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8c64f10f86b7 append output of mx command to (re)build graal.jar to a per-project log file ! mxtool/mx.py Changeset: a7d44c139948 Author: Doug Simon Date: 2013-10-22 11:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a7d44c139948 Merge. Changeset: 2ae286218721 Author: Gilles Duboscq Date: 2013-10-22 15:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2ae286218721 Add setter for GuardNode's action ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardNode.java Changeset: b2882f4ab612 Author: Gilles Duboscq Date: 2013-10-22 15:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b2882f4ab612 Add an optional name to HotSpotNmethod. Print it during deopt. Use it when installing a Truffle compilation ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CompilationResult.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotCryptoSubstitutionTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotCodeCacheProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotNmethod.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java ! src/share/tools/IdealGraphVisualizer/nbproject/project.properties ! src/share/vm/graal/graalJavaAccess.hpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 0916da3633ac Author: Doug Simon Date: 2013-10-22 17:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0916da3633ac only show metric and timer values if -G:Meter or -G:Time is enabled ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalDebugConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: f020e149c1b6 Author: S.Bharadwaj Yadavalli Date: 2013-10-22 14:35 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/f020e149c1b6 PTX codegen enhancements; fixes to PTX test regressions. ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardNode.java ! src/gpu/ptx/vm/gpu_ptx.cpp ! src/gpu/ptx/vm/ptxKernelArguments.cpp ! src/gpu/ptx/vm/ptxKernelArguments.hpp Changeset: 8ee3a8dd762e Author: Mick Jordan Date: 2013-10-21 20:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8ee3a8dd762e mxtool sclone: check import version when imported suite already exists ! mxtool/mx.py Changeset: ef0de9485627 Author: Mick Jordan Date: 2013-10-22 08:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ef0de9485627 Merge ! mxtool/mx.py Changeset: 5ccee20550ea Author: Mick Jordan Date: 2013-10-22 15:48 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5ccee20550ea mxtool: fixes (GRAAL-557) and code cleanups ! mxtool/mx.py Changeset: fe02f4113a69 Author: Mick Jordan Date: 2013-10-22 15:49 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/fe02f4113a69 Merge Changeset: 2583afcd26ee Author: Doug Simon Date: 2013-10-23 10:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2583afcd26ee fixed bug in creation of CreateGRAALDist.launch files ! mxtool/mx.py Changeset: 6975d14ff33f Author: Matthias Grimmer Date: 2013-10-21 17:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6975d14ff33f Add NeverInlineMacro for OptimizedCallTarget.call ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/OptimizedCallTargetSubstitutions.java Changeset: 04671d59e93b Author: Matthias Grimmer Date: 2013-10-21 18:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/04671d59e93b Allow CodeCacheProvider to install default methods ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CodeCacheProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotCodeCacheProvider.java Changeset: 56839b468ecb Author: Matthias Grimmer Date: 2013-10-22 13:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/56839b468ecb Add missing ExplodeLoop annotation in SL ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/BlockNode.java Changeset: 9fe4cd9d7e12 Author: Matthias Grimmer Date: 2013-10-22 13:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9fe4cd9d7e12 Make pointer decoding of AMD64HotSPotMove public ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotMove.java Changeset: 23dc5dfdb9c7 Author: Matthias Grimmer Date: 2013-10-22 13:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/23dc5dfdb9c7 Add OptimizedCallTarget.call(PackedFrame, Arguments) frame prologue injection ! 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/util/OptimizedCallTargetFieldInfo.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java Changeset: ecd85445f77a Author: Matthias Grimmer Date: 2013-10-23 12:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ecd85445f77a Rename CodeCacheProvider.addDefaultMethod to setDefaultMethod ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CodeCacheProvider.java Changeset: 7d5c3ffbee64 Author: Matthias Grimmer Date: 2013-10-23 12:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7d5c3ffbee64 Refactoring of the frame prologue injection ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotCodeCacheProvider.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/GraalTruffleRuntime.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/OptimizedCallTargetSubstitutions.java Changeset: 9b1cc2628961 Author: Matthias Grimmer Date: 2013-10-23 12:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9b1cc2628961 Extend the CompilerToVM interface to explicitly avoid compilation and inlining of methods ! 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.truffle.hotspot.amd64/src/com/oracle/graal/truffle/hotspot/amd64/AMD64HotSpotTruffleBackend.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: e5c23a8f3dd8 Author: Matthias Grimmer Date: 2013-10-23 12:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e5c23a8f3dd8 Remove unused parameter from CompilerToVm.dontInline ! 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/graalCompilerToVM.cpp Changeset: b34114019fd0 Author: Matthias Grimmer Date: 2013-10-23 13:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b34114019fd0 Re-add OptimizedCallTarget.callHelper - prevents frequent reinstallation of frame injection ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/OptimizedCallTargetSubstitutions.java Changeset: cee7f686c470 Author: Matthias Grimmer Date: 2013-10-23 13:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cee7f686c470 rename CompilerToVm.dontInline to doNotInlineOrCompile ! 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/graalCompilerToVM.cpp Changeset: 16e507054ebb Author: Matthias Grimmer Date: 2013-10-23 13:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/16e507054ebb Merge ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotCodeCacheProvider.java Changeset: c95e11c431b0 Author: Roland Schatz Date: 2013-10-23 13:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c95e11c431b0 IGV: Fix cfg edge coloring. ! src/share/tools/IdealGraphVisualizer/Graal/src/com/sun/hotspot/igv/graal/filters/GraalEdgeColorFilter.java Changeset: ae36dae46d50 Author: Gilles Duboscq Date: 2013-10-23 11:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ae36dae46d50 Fix StampTool.unsignedRightShift ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampTool.java Changeset: 97f56b7e978e Author: Gilles Duboscq Date: 2013-10-23 13:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/97f56b7e978e Fix NPE in OptimizeGuardAnchors ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/OptimizeGuardAnchors.java Changeset: 0aa37fd2f33e Author: Bernhard Urban Date: 2013-10-23 15:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0aa37fd2f33e mx: fix detection for sparc. ignore unparsable lines in jvm.cfg ! mx/commands.py Changeset: eb9ac998b46f Author: Bernhard Urban Date: 2013-10-23 15:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/eb9ac998b46f sparc: fix makefile issue from hsx25 merge ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/vm.make Changeset: 7cf8b577b6e1 Author: Gilles Duboscq Date: 2013-10-23 16:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7cf8b577b6e1 Fix integer stamp join for downMask/lowerBound ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/IntegerStamp.java Changeset: 37207d7e9056 Author: Gilles Duboscq Date: 2013-10-23 17:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/37207d7e9056 Fix exception during canonicalization (GRAAL-554): when killing the branch following a FixedGuard, we can not count on this removing all of our usages because some of them may already be dead ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java Changeset: c69d0a705553 Author: Doug Simon Date: 2013-10-23 18:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c69d0a705553 improved debug scope context when compiling Truffle IR graphs by making a Truffle compilable masquerade as a JavaMethod ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleIRJavaMethod.java Changeset: 11b086b1bae4 Author: S.Bharadwaj Yadavalli Date: 2013-10-23 13:54 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/11b086b1bae4 [PTX] fix warnings in ptx code ! src/gpu/ptx/vm/ptxKernelArguments.cpp Changeset: d084c3db9c61 Author: Bernhard Urban Date: 2013-10-23 22:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d084c3db9c61 ArrayCopySnippets: use slow path probability for deopt branches ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopySnippets.java Changeset: da2edc2ceffc Author: Bernhard Urban Date: 2013-10-23 22:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/da2edc2ceffc ArrayCopySnippets: don't do a second bounds check ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopySnippets.java Changeset: e1f40574c309 Author: Bernhard Urban Date: 2013-10-23 22:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e1f40574c309 Unsafe{Load,Store}Node: users must provide an LocationIdentity explicitly. Provide more specific LocationIdentity in UnsafeArraySnippets (instead of ANY_LOCATION) ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AESCryptSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CipherBlockChainingSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopySnippets.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeLoadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeStoreNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeClassSubstitutions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/UnsafeSubstitutions.java Changeset: 2df56730c5a6 Author: Bernhard Urban Date: 2013-10-23 22:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2df56730c5a6 UnsafeArrayCopyNode: try to be more precise about killed location ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopyNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: aac2f1e99352 Author: Bernhard Urban Date: 2013-10-23 22:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/aac2f1e99352 UnsafeArrayCopySnippets: use vectorized version also for Long, Double and Object ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopySnippets.java Changeset: 9b22378a8748 Author: Bernhard Urban Date: 2013-10-23 22:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9b22378a8748 ArrayCopySnippets: remove unused constants ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopySnippets.java Changeset: 0db1d96dd8f0 Author: Bernhard Urban Date: 2013-10-23 22:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0db1d96dd8f0 ArrayCopySnippets: small cleanup ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopySnippets.java Changeset: 9af82ca3f225 Author: Mick Jordan Date: 2013-10-23 15:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9af82ca3f225 mxtool: change about text to refer to Wiki doc, add mx.find script ! mxtool/mx.py Changeset: c41342332b7f Author: Mick Jordan Date: 2013-10-23 17:12 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c41342332b7f Merge Changeset: 2d11b9128e01 Author: Doug Simon Date: 2013-10-24 12:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2d11b9128e01 renamed TruffleIRJavaMethod to TruffleDebugJavaMethod and made Truffle debug scopes more consistent in its usage ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java ! 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/TruffleDebugJavaMethod.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleIRJavaMethod.java Changeset: b247ddd2fa0f Author: Lukas Stadler Date: 2013-10-24 13:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b247ddd2fa0f initialize primitive frame slots for objects to 0 (long) instead of null (object) ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/NewFrameNode.java Changeset: 86c74ef1b6f5 Author: Roland Schatz Date: 2013-10-24 15:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/86c74ef1b6f5 Make AMD64HotSpotTruffleBackend a decorator for the default backend. ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.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/src/com/oracle/graal/truffle/GraalTruffleRuntime.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleBackendFactory.java From bharadwaj.yadavalli at oracle.com Thu Oct 24 12:55:49 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Thu, 24 Oct 2013 15:55:49 -0400 Subject: PTX backend development status Message-ID: <52697B45.2030506@oracle.com> A PTX backend that generates code for simple Java methods is taking shape in the graal sources (|hg clone http:|//hg.openjdk.java.net/graal/graal). | htps://wiki.openjdk.java.net/display/Graal/Main provides necessary information about building and running graal. Current implementation can generate and execute PTX code on CUDA capable hardware (if one exists) for simple Java methods. Primitive type Java method argument passing and capture of return value work. Object type argument passing still needs work. There are a few PTX tests in raal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test that can be run. The generated PTX code can printed to stdout by passing the commandline option -XX:+TraceGPUInteraction to ./mx.sh An initial goal is to be able to recognize Java constructs suitable for GPU execution at runtime. Looking forward to all PTX experts to contribute in enhancing this OpenJDK project. Thanks, Bharadwaj | From tom.deneau at amd.com Thu Oct 24 13:20:36 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 24 Oct 2013 20:20:36 +0000 Subject: CompareAndSwapNode support Message-ID: In the HSAIL backend, we had support for CompareAndSwapNode. (we had not pushed this out to the trunk yet). As part of the merge with the new runtime infrastructure changes, I see that our CompareAndSwapNode support is broken. I'm trying to understand how to get it working again. In the particular test I'm looking at the java code calls atomicInt.getAndAdd(constant) First I noticed that we were getting Invoke nodes for things like getIntVolatile and compareAndSwapInt. So I assumed the UnsafeSubstitutions needed to be enabled for our backend. When I enabled these, I got the following error which doesn't mean anything to me... java.lang.AssertionError: has unexpected usage 20|LoadField#value of checkcast 19|GuardingPi at at com.oracle.graal.replacements.NodeIntrinsificationPhase.checkCheckCastUsage(NodeIntrinsificationPhase.java:387) at com.oracle.graal.replacements.NodeIntrinsificationPhase.checkCheckCastUsage(NodeIntrinsificationPhase.java:382) at com.oracle.graal.replacements.NodeIntrinsificationPhase.cleanUpReturnCheckCast(NodeIntrinsificationPhase.java:328) at com.oracle.graal.replacements.NodeIntrinsificationPhase.run(NodeIntrinsificationPhase.java:67) Any suggestions? -- Tom From tom.deneau at amd.com Thu Oct 24 15:05:15 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 24 Oct 2013 22:05:15 +0000 Subject: instanceof klass "constant" Message-ID: We have some junit tests that test instanceof. The code for these ends up loading from the klass ptr field of the object (offset 8) and comparing to a 64-bit "constant" klass value. Is this constant something that can change with GC and then need to be fixed up? Currently we do handle similar cases like class references for static fields by using a JNI weak reference but is this something that falls in that category? -- Tom From tom.deneau at amd.com Thu Oct 24 15:24:52 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 24 Oct 2013 22:24:52 +0000 Subject: CompareAndSwapNode support Message-ID: Some additional information on this... The original junit test was written using lambdas and so could not be run under java 7. Since our junit framework also supports java7 style tests, I rewrote the test to be java 7, and rebuilt graal with java 7. And with no other changes to graal, the test now passes. Does this make any sense? -- Tom From: Deneau, Tom Sent: Thursday, October 24, 2013 3:21 PM To: graal-dev at openjdk.java.net Subject: CompareAndSwapNode support In the HSAIL backend, we had support for CompareAndSwapNode. (we had not pushed this out to the trunk yet). As part of the merge with the new runtime infrastructure changes, I see that our CompareAndSwapNode support is broken. I'm trying to understand how to get it working again. In the particular test I'm looking at the java code calls atomicInt.getAndAdd(constant) First I noticed that we were getting Invoke nodes for things like getIntVolatile and compareAndSwapInt. So I assumed the UnsafeSubstitutions needed to be enabled for our backend. When I enabled these, I got the following error which doesn't mean anything to me... java.lang.AssertionError: has unexpected usage 20|LoadField#value of checkcast 19|GuardingPi at at com.oracle.graal.replacements.NodeIntrinsificationPhase.checkCheckCastUsage(NodeIntrinsificationPhase.java:387) at com.oracle.graal.replacements.NodeIntrinsificationPhase.checkCheckCastUsage(NodeIntrinsificationPhase.java:382) at com.oracle.graal.replacements.NodeIntrinsificationPhase.cleanUpReturnCheckCast(NodeIntrinsificationPhase.java:328) at com.oracle.graal.replacements.NodeIntrinsificationPhase.run(NodeIntrinsificationPhase.java:67) Any suggestions? -- Tom From tom.deneau at amd.com Thu Oct 24 15:28:37 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 24 Oct 2013 22:28:37 +0000 Subject: another java 8 strangeness Message-ID: I had built all of graal with java 8 and except for the aforementioned CompareAndSwap tests, all our other tests were passing. I wanted to use igv. But the GUI would not start. But when I went back and built graal with java 7, mx igv seemed to work fine. Is this a known problem? -- Tom From duboscq at ssw.jku.at Thu Oct 24 15:35:59 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Fri, 25 Oct 2013 00:35:59 +0200 Subject: another java 8 strangeness In-Reply-To: References: Message-ID: Yes, this is a known problem with the netbeans platform version we are using for IGV, we would need to update it. -Gilles On Fri, Oct 25, 2013 at 12:28 AM, Tom Deneau wrote: > I had built all of graal with java 8 and except for the aforementioned > CompareAndSwap tests, all our other tests were passing. > > I wanted to use igv. But the GUI would not start. > > But when I went back and built graal with java 7, mx igv seemed to work > fine. > Is this a known problem? > > -- Tom > > From doug.simon at oracle.com Thu Oct 24 15:42:10 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 25 Oct 2013 00:42:10 +0200 Subject: another java 8 strangeness In-Reply-To: References: Message-ID: On Oct 25, 2013, at 12:28 AM, "Deneau, Tom" wrote: > I had built all of graal with java 8 and except for the aforementioned CompareAndSwap tests, all our other tests were passing. > > I wanted to use igv. But the GUI would not start. > > But when I went back and built graal with java 7, mx igv seemed to work fine. > Is this a known problem? Yes. We have an internal JIRA issue for migrating to JDK8 but we are not there yet. Until it's officially supported, I recommend staying with JDK7 for Graal development. -Doug From christian.thalinger at oracle.com Thu Oct 24 17:50:53 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 24 Oct 2013 17:50:53 -0700 Subject: Graal on Mavericks In-Reply-To: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> References: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> Message-ID: <56D9F6F1-6200-4155-8902-C4CCFE82A20E@oracle.com> On Oct 23, 2013, at 7:36 AM, Lukas Stadler wrote: > In case someone is trying to get Graal to compile on OS X Mavericks - I had to add the following to mx/env to make it run: > > COMPILER_WARNINGS_FATAL=false > USE_CLANG=true > LFLAGS=-Xlinker -lstdc++ > > If it doesn?t take too long, I suggest we wait for the relevant changes from hotspot before we implement them ourselves. I?m also on Mavericks and I have a fix. Unfortunately it is unlikely that I can push it to hsx25 given we are so late in the 8 cycle. Might have to wait until we open the 9 repositories. Here is the fix. It also adds the missing optimization-level downgrade for loopTransform.o. I can push this to the Graal repository if you want. diff -r f7d928a3181c make/bsd/makefiles/gcc.make --- a/make/bsd/makefiles/gcc.make Thu Oct 24 19:32:34 2013 +0200 +++ b/make/bsd/makefiles/gcc.make Thu Oct 24 17:49:39 2013 -0700 @@ -314,10 +314,16 @@ OPT_CFLAGS/NOOPT=-O0 # Work around some compiler bugs. ifeq ($(USE_CLANG), true) + # Clang 4.2 ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 2), 1) OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) OPT_CFLAGS/unsafe.o += -O1 endif + # Clang 5.0 + ifeq ($(shell expr $(CC_VER_MAJOR) = 5 \& $(CC_VER_MINOR) = 0), 1) + OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) + OPT_CFLAGS/unsafe.o += -O1 + endif else # 6835796. Problem in GCC 4.3.0 with mulnode.o optimized compilation. ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 3), 1) @@ -325,6 +331,14 @@ else endif endif +# We want to use libc++ on Clang 5.0 +ifeq ($(USE_CLANG), true) + # Clang 5.0 + ifeq ($(shell expr $(CC_VER_MAJOR) = 5 \& $(CC_VER_MINOR) = 0), 1) + CFLAGS += -stdlib=libc++ + endif +endif + # Flags for generating make dependency flags. DEPFLAGS = -MMD -MP -MF $(DEP_DIR)/$(@:%=%.d) ifeq ($(USE_CLANG),) > > - Lukas From christian.thalinger at oracle.com Thu Oct 24 17:55:32 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 24 Oct 2013 17:55:32 -0700 Subject: instanceof klass "constant" In-Reply-To: References: Message-ID: <0CE4288B-878E-4F38-ABBE-47295DAFF022@oracle.com> On Oct 24, 2013, at 3:05 PM, Deneau, Tom wrote: > We have some junit tests that test instanceof. > > The code for these ends up loading from the klass ptr field of the object (offset 8) and comparing to a 64-bit "constant" klass value. Is this constant something that can change with GC and then need to be fixed up? No. The value at offset 8 is one of: Klass* _klass; narrowKlass _compressed_klass; These don?t move (yet). I say yet because I have no idea what the runtime team has in mind. > > Currently we do handle similar cases like class references for static fields by using a JNI weak reference but is this something that falls in that category? > > -- Tom From christian.thalinger at oracle.com Thu Oct 24 18:00:53 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 24 Oct 2013 18:00:53 -0700 Subject: CompareAndSwapNode support In-Reply-To: References: Message-ID: <08621896-62DF-466A-958D-9B781B51C0EB@oracle.com> On Oct 24, 2013, at 3:24 PM, Deneau, Tom wrote: > Some additional information on this... > > The original junit test was written using lambdas and so could not be run under java 7. Since our junit framework also supports java7 style tests, I rewrote the test to be java 7, and rebuilt graal with java 7. And with no other changes to graal, the test now passes. > > Does this make any sense? > > -- Tom > > From: Deneau, Tom > Sent: Thursday, October 24, 2013 3:21 PM > To: graal-dev at openjdk.java.net > Subject: CompareAndSwapNode support > > In the HSAIL backend, we had support for CompareAndSwapNode. (we had not pushed this out to the trunk yet). > > As part of the merge with the new runtime infrastructure changes, I see that our CompareAndSwapNode support is broken. > I'm trying to understand how to get it working again. > > In the particular test I'm looking at the java code calls atomicInt.getAndAdd(constant) Do you mean getAndAddInt? If you are talking about the Unsafe guys these exist since 1.8. So compiling (and running) with 7 or 8 definitely makes a difference. > > First I noticed that we were getting Invoke nodes for things like getIntVolatile and compareAndSwapInt. > So I assumed the UnsafeSubstitutions needed to be enabled for our backend. > > When I enabled these, I got the following error which doesn't mean anything to me... > > java.lang.AssertionError: has unexpected usage 20|LoadField#value of checkcast 19|GuardingPi at > at com.oracle.graal.replacements.NodeIntrinsificationPhase.checkCheckCastUsage(NodeIntrinsificationPhase.java:387) > at com.oracle.graal.replacements.NodeIntrinsificationPhase.checkCheckCastUsage(NodeIntrinsificationPhase.java:382) > at com.oracle.graal.replacements.NodeIntrinsificationPhase.cleanUpReturnCheckCast(NodeIntrinsificationPhase.java:328) > at com.oracle.graal.replacements.NodeIntrinsificationPhase.run(NodeIntrinsificationPhase.java:67) > > Any suggestions? > > -- Tom > From doug.simon at oracle.com Fri Oct 25 01:32:02 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 25 Oct 2013 10:32:02 +0200 Subject: Graal on Mavericks In-Reply-To: <56D9F6F1-6200-4155-8902-C4CCFE82A20E@oracle.com> References: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> <56D9F6F1-6200-4155-8902-C4CCFE82A20E@oracle.com> Message-ID: On Oct 25, 2013, at 2:50 AM, Christian Thalinger wrote: > > On Oct 23, 2013, at 7:36 AM, Lukas Stadler wrote: > >> In case someone is trying to get Graal to compile on OS X Mavericks - I had to add the following to mx/env to make it run: >> >> COMPILER_WARNINGS_FATAL=false >> USE_CLANG=true >> LFLAGS=-Xlinker -lstdc++ >> >> If it doesn?t take too long, I suggest we wait for the relevant changes from hotspot before we implement them ourselves. > > I?m also on Mavericks and I have a fix. Unfortunately it is unlikely that I can push it to hsx25 given we are so late in the 8 cycle. Might have to wait until we open the 9 repositories. > > Here is the fix. It also adds the missing optimization-level downgrade for loopTransform.o. I can push this to the Graal repository if you want. Yes, please push it through. -Doug > diff -r f7d928a3181c make/bsd/makefiles/gcc.make > --- a/make/bsd/makefiles/gcc.make Thu Oct 24 19:32:34 2013 +0200 > +++ b/make/bsd/makefiles/gcc.make Thu Oct 24 17:49:39 2013 -0700 > @@ -314,10 +314,16 @@ OPT_CFLAGS/NOOPT=-O0 > > # Work around some compiler bugs. > ifeq ($(USE_CLANG), true) > + # Clang 4.2 > ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 2), 1) > OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) > OPT_CFLAGS/unsafe.o += -O1 > endif > + # Clang 5.0 > + ifeq ($(shell expr $(CC_VER_MAJOR) = 5 \& $(CC_VER_MINOR) = 0), 1) > + OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) > + OPT_CFLAGS/unsafe.o += -O1 > + endif > else > # 6835796. Problem in GCC 4.3.0 with mulnode.o optimized compilation. > ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 3), 1) > @@ -325,6 +331,14 @@ else > endif > endif > > +# We want to use libc++ on Clang 5.0 > +ifeq ($(USE_CLANG), true) > + # Clang 5.0 > + ifeq ($(shell expr $(CC_VER_MAJOR) = 5 \& $(CC_VER_MINOR) = 0), 1) > + CFLAGS += -stdlib=libc++ > + endif > +endif > + > # Flags for generating make dependency flags. > DEPFLAGS = -MMD -MP -MF $(DEP_DIR)/$(@:%=%.d) > ifeq ($(USE_CLANG),) > >> >> - Lukas > From doug.simon at oracle.com Fri Oct 25 04:45:45 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 25 Oct 2013 11:45:45 +0000 Subject: hg: graal/graal: 31 new changesets Message-ID: <20131025114919.CE8D26273F@hg.openjdk.java.net> Changeset: 5de6526474bb Author: twisti Date: 2013-10-22 23:16 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5de6526474bb added missing @Override's ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: ae412befde21 Author: twisti Date: 2013-10-23 19:50 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ae412befde21 read HotSpotVMConfig fields from HotSpot's vmStructs via annotations ! 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/AMD64HotSpotSafepointOp.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.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotSafepointOp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConstant.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMField.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMFlag.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMType.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/Stable.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/HotSpotConstantPool.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostForeignCallsProvider.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/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/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.truffle.hotspot.amd64/src/com/oracle/graal/truffle/hotspot/amd64/AMD64HotSpotTruffleBackend.java ! src/cpu/x86/vm/vmStructs_x86.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 0f34a60d0bc6 Author: twisti Date: 2013-10-24 08:51 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0f34a60d0bc6 Merge ! graal/com.oracle.graal.truffle.hotspot.amd64/src/com/oracle/graal/truffle/hotspot/amd64/AMD64HotSpotTruffleBackend.java Changeset: d1f8d0538b79 Author: Gilles Duboscq Date: 2013-10-24 11:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d1f8d0538b79 Only print "Graal: no installed code" in deopt if nmethod is compiled by Graal ! src/share/vm/runtime/deoptimization.cpp Changeset: 035474349265 Author: Gilles Duboscq Date: 2013-10-24 20:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/035474349265 Serveral fixes to StampTool.add and some tests ! graal/com.oracle.graal.nodes.test/src/com/oracle/graal/nodes/test/IntegerStampTest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampTool.java Changeset: 6264d434aca2 Author: Gilles Duboscq Date: 2013-10-24 19:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6264d434aca2 Fix warning ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java Changeset: 935dcd8ad8eb Author: Christian Humer Date: 2013-10-21 11:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/935dcd8ad8eb Truffle-DSL: fixed wrong type simple name references with ECJ in generated code. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/Utils.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/codewriter/OrganizedImports.java Changeset: e47f373499ec Author: Christian Humer Date: 2013-10-21 11:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e47f373499ec Merge. - graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXBackend.java - graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotGraalRuntime.java - graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotGraalRuntimeFactory.java - graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotGraalRuntime.java - graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotGraalRuntime.java - graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotGraalRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntimeFactory.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotForeignCallsProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotLoweringProvider.java - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/EliminatePartiallyRedundantGuardsPhase.java Changeset: c17bfad2fa98 Author: Christian Humer Date: 2013-10-24 15:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c17bfad2fa98 Merge. Changeset: 0d3e4d940925 Author: Christian Humer Date: 2013-10-24 16:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0d3e4d940925 Truffle-DSL: fixed recursive rewrite problem for transitions from monomorphic to polymorphic. (GRAAL-560 #resolve) ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: 30810338dfa9 Author: Christian Humer Date: 2013-10-24 22:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/30810338dfa9 Merge. Changeset: 1c8d5a0891b5 Author: Doug Simon Date: 2013-10-24 12:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1c8d5a0891b5 improved error reporting in LSRA ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: af39ea2dc39d Author: Doug Simon Date: 2013-10-24 14:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/af39ea2dc39d made ConstantNodes (optionally) not record their usages (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.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConstantNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MergeNode.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/CanonicalizerPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinterObserver.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.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 ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeVerificationPhase.java Changeset: 693622f11dc3 Author: Doug Simon Date: 2013-10-24 14:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/693622f11dc3 applied auto-format ! mxtool/mx.py Changeset: 388bb7650808 Author: Doug Simon Date: 2013-10-24 16:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/388bb7650808 Merge. Changeset: 6332050441eb Author: Doug Simon Date: 2013-10-24 23:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6332050441eb fixed tests that need to take into account ConstantNodes not recording their usages (GRAAL-508) ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ConditionalEliminationTest.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/TypeSystemTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/deopt/CompiledMethodTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/AheadOfTimeVerificationPhase.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/LoadJavaMirrorWithKlassPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConstantNode.java Changeset: 04e51b3026c0 Author: Doug Simon Date: 2013-10-24 23:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/04e51b3026c0 Merge. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 3c6e94cbce25 Author: Doug Simon Date: 2013-10-24 21:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3c6e94cbce25 fixed Java warnings ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java Changeset: 847819feb98e Author: Doug Simon Date: 2013-10-24 21:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/847819feb98e moved registration of HotSpot method substitutions out of HotSpotLoweringProvider into separate HotSpotSubstitutions class ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostLoweringProvider.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotSubstitutions.java Changeset: 32d08d88c881 Author: Doug Simon Date: 2013-10-25 00:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/32d08d88c881 restricted initialization of ForeignCallProvider during VM startup to only be for the ForeignCallProvider of the host backend. ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotForeignCallsProvider.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotForeignCallsProvider.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/HotSpotForeignCallsProvider.java Changeset: 7315fb9b0679 Author: Doug Simon Date: 2013-10-25 00:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7315fb9b0679 separated registration of (host) intrinsics from initialization of lowerers ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: 1d369998229a Author: Doug Simon Date: 2013-10-25 00:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1d369998229a restricted initialization of LoweringProvider during VM startup to only be for the LoweringProvider of the host backend; removed unnecessary HotSpotLoweringProvider interface ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackendFactory.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/HotSpotHostLoweringProvider.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java Changeset: 7876c59a7a2f Author: Doug Simon Date: 2013-10-25 01:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7876c59a7a2f refactored all deferred initialization of backends into HotSpotBackend ! 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/AMD64HotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILCompilationResult.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/HotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotForeignCallLinkage.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotHostBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: 8fde330c11cd Author: Doug Simon Date: 2013-10-25 01:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8fde330c11cd Merge. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotForeignCallsProvider.java Changeset: a5a4a0bcd863 Author: twisti Date: 2013-10-24 19:21 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a5a4a0bcd863 Adds support to the HSAIL backend for three of the bitwise logical operators, bitwise AND, bitwise OR and bitwise XOR. Contributed-by: Vasanth Venkatachalam ! graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BooleanBitwiseAndTestFF.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BooleanBitwiseAndTestFT.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BooleanBitwiseAndTestTF.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BooleanBitwiseAndTestTT.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BooleanBitwiseOrTestFF.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BooleanBitwiseOrTestFT.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BooleanBitwiseOrTestTF.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BooleanBitwiseOrTestTT.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BooleanBitwiseXorTestFF.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BooleanBitwiseXorTestFT.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BooleanBitwiseXorTestTF.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BooleanBitwiseXorTestTT.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ByteBitwiseAndCastTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ByteBitwiseAndTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ByteBitwiseOrCastTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ByteBitwiseOrTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ByteBitwiseXorCastTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ByteBitwiseXorTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/CharBitwiseAndCastTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/CharBitwiseAndTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/CharBitwiseOrCastTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/CharBitwiseOrTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/CharBitwiseXorCastTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/CharBitwiseXorTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/DoubleLongConvertTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/FloatConvertTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/FloatDoubleConvertTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/FloatLongConvertTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntBitwiseAndTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntBitwiseOrTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntBitwiseXorTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntByteConvertTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntCharConvertTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntDoubleConvertTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntFloatConvertTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntLongConvertTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntShortConvertTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/LongBitwiseAndTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/LongBitwiseOrTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/LongBitwiseXorTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ShortBitwiseAndCastTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ShortBitwiseAndTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ShortBitwiseOrCastTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ShortBitwiseOrTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ShortBitwiseXorCastTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ShortBitwiseXorTest.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILArithmetic.java Changeset: 110c3faa57e9 Author: Bernhard Urban Date: 2013-10-24 18:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/110c3faa57e9 mx: print warning if encounter a non-parsable line in jvm.cfg ! mx/commands.py Changeset: bc0ed539018f Author: Bernhard Urban Date: 2013-10-24 18:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bc0ed539018f UnsafeArrayCopySnippets: use DirectObjectStoreNode again for kind object. add location identity to DirectObjectStoreNode. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopySnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetCounter.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/DirectObjectStoreNode.java Changeset: 968fedf712dd Author: Bernhard Urban Date: 2013-10-24 18:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/968fedf712dd UnsafeArrayCopySnippets: use right kind for boolean case ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopySnippets.java Changeset: 68e8834ad888 Author: Bernhard Urban Date: 2013-10-24 18:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/68e8834ad888 UnsafeArrayCopySnippets: minor refactoring ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/UnsafeArrayCopySnippets.java Changeset: e0634d52796f Author: Bernhard Urban Date: 2013-10-25 11:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e0634d52796f HotSpotHostLowering: use location identity from CAS node to create location ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostLoweringProvider.java Changeset: 3b178baf3edb Author: Doug Simon Date: 2013-10-25 12:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3b178baf3edb fleshed out HSAIL backend a little to demonstrate changes needed after recent API/infrastructure updates ! 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/StaticNBodySpillTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticNBodyTest.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotForeignCallsProvider.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotReplacementsImpl.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 ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRegisters.java From doug.simon at oracle.com Fri Oct 25 05:12:49 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 25 Oct 2013 14:12:49 +0200 Subject: hsail test case failures in the latest tip, mathSubstitutions In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A7553A93EB@SATLEXDAG02.amd.com> <5DD1503F815BD14889DC81D28643E3A7553A957C@SATLEXDAG02.amd.com> Message-ID: Sorry for the delay in responding. I've pushed some changes that should answer your questions: http://hg.openjdk.java.net/graal/graal/rev/3b178baf3edb The tests still don't completely work since the thread register for HSAIL is not yet defined: $ mx --vm server unittest -G:+InlineEverything -G:+RemoveNeverExecutedCode StaticNBodyCallTest StringContainsAcceptTest executing junit tests now... (2 test classes) JUnit version 4.8 Time: 0.686 There were 2 failures: 1) test(com.oracle.graal.compiler.hsail.test.StaticNBodyCallTest) com.oracle.graal.graph.GraalInternalError: java.lang.AssertionError: thread register is not defined at node: 195|ForeignCall#createOutOfBoundsException(int)Object at com.oracle.graal.compiler.gen.LIRGenerator.doBlock(LIRGenerator.java:374) at com.oracle.graal.compiler.GraalCompiler$6.emitBlock(GraalCompiler.java:271) at com.oracle.graal.compiler.GraalCompiler$6.run(GraalCompiler.java:258) at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:258) at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:245) at com.oracle.graal.debug.Debug.scope(Debug.java:164) at com.oracle.graal.debug.Debug.scope(Debug.java:159) at com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:254) at com.oracle.graal.compiler.GraalCompiler$3.call(GraalCompiler.java:168) at com.oracle.graal.compiler.GraalCompiler$3.call(GraalCompiler.java:1) at com.oracle.graal.debug.internal.DebugScope.call(DebugScope.java:383) at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:261) at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:245) at com.oracle.graal.debug.Debug.scope(Debug.java:184) at com.oracle.graal.debug.Debug.scope(Debug.java:179) at com.oracle.graal.compiler.GraalCompiler.compileGraphNoScope(GraalCompiler.java:165) at com.oracle.graal.compiler.GraalCompiler$1.run(GraalCompiler.java:141) at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:258) at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:245) at com.oracle.graal.debug.Debug.scope(Debug.java:164) at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:138) at com.oracle.graal.hotspot.hsail.HSAILCompilationResult.getHSAILCompilationResult(HSAILCompilationResult.java:146) at com.oracle.graal.hotspot.hsail.HSAILCompilationResult.getHSAILCompilationResult(HSAILCompilationResult.java:104) at com.oracle.graal.hotspot.hsail.HSAILCompilationResult.getHSAILCompilationResult(HSAILCompilationResult.java:96) at com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.getCompiledHSAILSource(GraalKernelTester.java:46) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.getHSAILSource(KernelTester.java:486) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.createOkraKernel(KernelTester.java:507) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchKernelOkra(KernelTester.java:534) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchMethodKernelOkra(KernelTester.java:586) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchMethodKernel(KernelTester.java:364) at com.oracle.graal.compiler.hsail.test.StaticNBodyTest.runTest(StaticNBodyTest.java:96) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.compareOkraToSeq(KernelTester.java:711) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.compareOkraToSeq(KernelTester.java:696) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.testGeneratedHsail(KernelTester.java:717) at com.oracle.graal.compiler.hsail.test.StaticNBodyCallTest.test(StaticNBodyCallTest.java:44) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.junit.runner.JUnitCore.run(JUnitCore.java:157) at org.junit.runner.JUnitCore.run(JUnitCore.java:136) at org.junit.runner.JUnitCore.run(JUnitCore.java:117) at org.junit.runner.JUnitCore.runMain(JUnitCore.java:98) at org.junit.runner.JUnitCore.runMainAndExit(JUnitCore.java:53) at org.junit.runner.JUnitCore.main(JUnitCore.java:45) at JUnitWrapper.main(JUnitWrapper.java:75) Caused by: java.lang.AssertionError: thread register is not defined at com.oracle.graal.hotspot.meta.HotSpotRegisters.getThreadRegister(HotSpotRegisters.java:40) at com.oracle.graal.hotspot.stubs.ForeignCallStub.getGraph(ForeignCallStub.java:229) at com.oracle.graal.hotspot.stubs.Stub$1.run(Stub.java:143) at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:258) at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:245) at com.oracle.graal.debug.Debug.sandbox(Debug.java:127) at com.oracle.graal.hotspot.stubs.Stub.getCode(Stub.java:138) at com.oracle.graal.hotspot.HotSpotForeignCallLinkage.finalizeAddress(HotSpotForeignCallLinkage.java:231) at com.oracle.graal.hotspot.meta.HotSpotForeignCallsProviderImpl.lookupForeignCall(HotSpotForeignCallsProviderImpl.java:139) at com.oracle.graal.hotspot.hsail.HSAILHotSpotForeignCallsProvider.lookupForeignCall(HSAILHotSpotForeignCallsProvider.java:42) at com.oracle.graal.hotspot.hsail.HSAILHotSpotForeignCallsProvider.lookupForeignCall(HSAILHotSpotForeignCallsProvider.java:1) at com.oracle.graal.nodes.extended.ForeignCallNode.generate(ForeignCallNode.java:82) at com.oracle.graal.compiler.gen.LIRGenerator.emitNode(LIRGenerator.java:436) at com.oracle.graal.compiler.gen.LIRGenerator.doRoot(LIRGenerator.java:425) at com.oracle.graal.compiler.gen.LIRGenerator.doBlock(LIRGenerator.java:370) ... 65 more 2) test(com.oracle.graal.compiler.hsail.test.StringContainsAcceptTest) com.oracle.graal.graph.GraalInternalError: java.lang.AssertionError: thread register is not defined at node: 312|ForeignCall#createOutOfBoundsException(int)Object at com.oracle.graal.compiler.gen.LIRGenerator.doBlock(LIRGenerator.java:374) at com.oracle.graal.compiler.GraalCompiler$6.emitBlock(GraalCompiler.java:271) at com.oracle.graal.compiler.GraalCompiler$6.run(GraalCompiler.java:258) at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:258) at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:245) at com.oracle.graal.debug.Debug.scope(Debug.java:164) at com.oracle.graal.debug.Debug.scope(Debug.java:159) at com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:254) at com.oracle.graal.compiler.GraalCompiler$3.call(GraalCompiler.java:168) at com.oracle.graal.compiler.GraalCompiler$3.call(GraalCompiler.java:1) at com.oracle.graal.debug.internal.DebugScope.call(DebugScope.java:383) at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:261) at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:245) at com.oracle.graal.debug.Debug.scope(Debug.java:184) at com.oracle.graal.debug.Debug.scope(Debug.java:179) at com.oracle.graal.compiler.GraalCompiler.compileGraphNoScope(GraalCompiler.java:165) at com.oracle.graal.compiler.GraalCompiler$1.run(GraalCompiler.java:141) at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:258) at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:245) at com.oracle.graal.debug.Debug.scope(Debug.java:164) at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:138) at com.oracle.graal.hotspot.hsail.HSAILCompilationResult.getHSAILCompilationResult(HSAILCompilationResult.java:146) at com.oracle.graal.hotspot.hsail.HSAILCompilationResult.getHSAILCompilationResult(HSAILCompilationResult.java:104) at com.oracle.graal.hotspot.hsail.HSAILCompilationResult.getHSAILCompilationResult(HSAILCompilationResult.java:96) at com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.getCompiledHSAILSource(GraalKernelTester.java:46) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.getHSAILSource(KernelTester.java:486) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.createOkraKernel(KernelTester.java:507) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchKernelOkra(KernelTester.java:534) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchMethodKernelOkra(KernelTester.java:592) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchMethodKernel(KernelTester.java:364) at com.oracle.graal.compiler.hsail.test.StringContainsAcceptTest.runTest(StringContainsAcceptTest.java:46) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.compareOkraToSeq(KernelTester.java:711) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.compareOkraToSeq(KernelTester.java:696) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.testGeneratedHsail(KernelTester.java:717) at com.oracle.graal.compiler.hsail.test.StringContainsAcceptTest.test(StringContainsAcceptTest.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.junit.runner.JUnitCore.run(JUnitCore.java:157) at org.junit.runner.JUnitCore.run(JUnitCore.java:136) at org.junit.runner.JUnitCore.run(JUnitCore.java:117) at org.junit.runner.JUnitCore.runMain(JUnitCore.java:98) at org.junit.runner.JUnitCore.runMainAndExit(JUnitCore.java:53) at org.junit.runner.JUnitCore.main(JUnitCore.java:45) at JUnitWrapper.main(JUnitWrapper.java:75) Caused by: java.lang.AssertionError: thread register is not defined at com.oracle.graal.hotspot.meta.HotSpotRegisters.getThreadRegister(HotSpotRegisters.java:40) at com.oracle.graal.hotspot.stubs.ForeignCallStub.getGraph(ForeignCallStub.java:229) at com.oracle.graal.hotspot.stubs.Stub$1.run(Stub.java:143) at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:258) at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:245) at com.oracle.graal.debug.Debug.sandbox(Debug.java:127) at com.oracle.graal.hotspot.stubs.Stub.getCode(Stub.java:138) at com.oracle.graal.hotspot.HotSpotForeignCallLinkage.finalizeAddress(HotSpotForeignCallLinkage.java:231) at com.oracle.graal.hotspot.meta.HotSpotForeignCallsProviderImpl.lookupForeignCall(HotSpotForeignCallsProviderImpl.java:139) at com.oracle.graal.hotspot.hsail.HSAILHotSpotForeignCallsProvider.lookupForeignCall(HSAILHotSpotForeignCallsProvider.java:42) at com.oracle.graal.hotspot.hsail.HSAILHotSpotForeignCallsProvider.lookupForeignCall(HSAILHotSpotForeignCallsProvider.java:1) at com.oracle.graal.nodes.extended.ForeignCallNode.generate(ForeignCallNode.java:82) at com.oracle.graal.compiler.gen.LIRGenerator.emitNode(LIRGenerator.java:436) at com.oracle.graal.compiler.gen.LIRGenerator.doRoot(LIRGenerator.java:425) at com.oracle.graal.compiler.gen.LIRGenerator.doBlock(LIRGenerator.java:370) ... 65 more FAILURES!!! Tests run: 2, Failures: 2 -Doug On Oct 23, 2013, at 7:06 PM, "Deneau, Tom" wrote: > Doug or others -- > > Vasanth is out this week so I am trying to get the HSAIL backend working with this new infrastructure. > > A specific problem we are having, previously we had a replacement for Math.sqrt(double) to MathSubstitutionsX86.sqrt(double) which was I think just inherited from AMD64HotSpotRuntime. (In the HSAIL LIR and assembler then, we emitted the HSAIL instruction from the MathIntrinsicNode). > > What is the right way to get just that one substitution working in the new framework? (Once we get that working, we can then add additional substitutions as needed). > > I can see that HSAILHotSpotReplacementsUtil needs some methods to be implemented (perhaps deferring to its parent), but for the substitution class itself, am not sure of whether new files should be created, or we should reuse existing MathSubstitutions. > > -- Tom > > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon > Sent: Tuesday, October 22, 2013 4:36 AM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: hsail test case failures in the latest tip > > As indicated by the exceptions raised by these tests (e.g., below), you need to fix the incomplete/incorrect HSAILLIRGenerator and HSAILHotSpotForeignCallsProvider classes. > > -Doug > > 1) test(com.oracle.graal.compiler.hsail.test.StaticNBodyCallTest) > com.oracle.graal.graph.GraalInternalError: unimplemented > at node: 504|Invoke#Direct#sqrt > at com.oracle.graal.graph.GraalInternalError.unimplemented(GraalInternalError.java:38) > at com.oracle.graal.compiler.hsail.HSAILLIRGenerator.emitDirectCall(HSAILLIRGenerator.java:553) > at com.oracle.graal.compiler.gen.LIRGenerator.emitInvoke(LIRGenerator.java:579) > at com.oracle.graal.nodes.InvokeWithExceptionNode.generate(InvokeWithExceptionNode.java:137) > at com.oracle.graal.compiler.gen.LIRGenerator.emitNode(LIRGenerator.java:387) > at com.oracle.graal.compiler.gen.LIRGenerator.doRoot(LIRGenerator.java:376) > at com.oracle.graal.compiler.gen.LIRGenerator.doBlock(LIRGenerator.java:327) > at com.oracle.graal.compiler.GraalCompiler$3.emitBlock(GraalCompiler.java:259) > at com.oracle.graal.compiler.GraalCompiler$3.run(GraalCompiler.java:246) > at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:258) > at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:245) > at com.oracle.graal.debug.Debug.scope(Debug.java:164) > at com.oracle.graal.debug.Debug.scope(Debug.java:159) > at com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:242) > at com.oracle.graal.compiler.GraalCompiler$1$2.call(GraalCompiler.java:154) > at com.oracle.graal.compiler.GraalCompiler$1$2.call(GraalCompiler.java:1) > at com.oracle.graal.debug.internal.DebugScope.call(DebugScope.java:383) > ... > 2) test(com.oracle.graal.compiler.hsail.test.StringContainsAcceptTest) > com.oracle.graal.graph.GraalInternalError: unimplemented: createOutOfBoundsException(int)Object > at node: 312|ForeignCall#createOutOfBoundsException(int)Object > at com.oracle.graal.graph.GraalInternalError.unimplemented(GraalInternalError.java:42) > at com.oracle.graal.hotspot.hsail.HSAILHotSpotForeignCallsProvider.lookupForeignCall(HSAILHotSpotForeignCallsProvider.java:52) > at com.oracle.graal.nodes.extended.ForeignCallNode.generate(ForeignCallNode.java:82) > at com.oracle.graal.compiler.gen.LIRGenerator.emitNode(LIRGenerator.java:387) > at com.oracle.graal.compiler.gen.LIRGenerator.doRoot(LIRGenerator.java:376) > at com.oracle.graal.compiler.gen.LIRGenerator.doBlock(LIRGenerator.java:327) > at com.oracle.graal.compiler.GraalCompiler$3.emitBlock(GraalCompiler.java:259) > at com.oracle.graal.compiler.GraalCompiler$3.run(GraalCompiler.java:246) > ... > > On Oct 22, 2013, at 5:02 AM, "Venkatachalam, Vasanth" wrote: > >> Doug, >> >> Please try running with -G:+InlineEverything -G:-RemoveNeverExecutedCode >> >> Vasanth >> >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Monday, October 21, 2013 1:16 PM >> To: Venkatachalam, Vasanth >> Cc: graal-dev at openjdk.java.net >> Subject: Re: hsail test case failures in the latest tip >> >> Can you please tell me how to reproduce the failures. They passed the gate as seem to pass when I run them locally: >> >> $ mx --vm server unittest StaticNBodyCallTest StringContainsAcceptTest executing junit tests now... (2 test classes) JUnit version 4.8 .. >> Time: 0.009 >> >> OK (2 tests) >> >> -Doug >> >> On Oct 21, 2013, at 7:21 PM, "Venkatachalam, Vasanth" wrote: >> >>> Doug- >>> >>> There are a couple of HSAIL test cases that are failing on the latest tip, namely hsail.test.StaticNBodyCallTest and hsail.test.StringContainsAcceptTest. >>> These test cases were passing as of rev 12895, which was uploaded around a week before the refactoring changes that you checked in. >>> >>> Can you examine which got checked in that's causing these tests to fail? >>> >>> Vasanth >>> >>> >>> >> >> >> > > > From tom.deneau at amd.com Fri Oct 25 05:59:34 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 25 Oct 2013 12:59:34 +0000 Subject: another java 8 strangeness In-Reply-To: References: , Message-ID: Doug -- Are these internal JIRA issues viewable by folks outside Oracle? Is this JDK8 issue something recent and does it go beyond just igv? We have been using JDK8 with graal for at least 6 months now with no problems (except of course not being able to use Eclipse). -- Tom ________________________________________ From: Doug Simon [doug.simon at oracle.com] Sent: Thursday, October 24, 2013 5:42 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: another java 8 strangeness On Oct 25, 2013, at 12:28 AM, "Deneau, Tom" wrote: > I had built all of graal with java 8 and except for the aforementioned CompareAndSwap tests, all our other tests were passing. > > I wanted to use igv. But the GUI would not start. > > But when I went back and built graal with java 7, mx igv seemed to work fine. > Is this a known problem? Yes. We have an internal JIRA issue for migrating to JDK8 but we are not there yet. Until it's officially supported, I recommend staying with JDK7 for Graal development. -Doug From tom.deneau at amd.com Fri Oct 25 06:07:43 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 25 Oct 2013 13:07:43 +0000 Subject: CompareAndSwapNode support In-Reply-To: <08621896-62DF-466A-958D-9B781B51C0EB@oracle.com> References: , <08621896-62DF-466A-958D-9B781B51C0EB@oracle.com> Message-ID: Just to further clarify... We had a HSAIL junit test that called AtomicInteger.getAndAddInt from a lambda. This made it java 8 specific. This test worked fine (building and running graal with java 8) up until we started doing this merge with the new infrastructure changes. We now have a version of this test that does the same thing but does not use lambdas. So this new version can be invoked from java 7. This new java7-style junit test still fails when we build our newly merged graal (newly merged with the new infrastructure) with java 8-b109 and try to run the test. The top of the stack trace is shown below. But if I build our merged graal with java7 b21 this new junit test succeeds. -- Toim ________________________________________ From: Christian Thalinger [christian.thalinger at oracle.com] Sent: Thursday, October 24, 2013 8:00 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: CompareAndSwapNode support On Oct 24, 2013, at 3:24 PM, Deneau, Tom wrote: > Some additional information on this... > > The original junit test was written using lambdas and so could not be run under java 7. Since our junit framework also supports java7 style tests, I rewrote the test to be java 7, and rebuilt graal with java 7. And with no other changes to graal, the test now passes. > > Does this make any sense? > > -- Tom > > From: Deneau, Tom > Sent: Thursday, October 24, 2013 3:21 PM > To: graal-dev at openjdk.java.net > Subject: CompareAndSwapNode support > > In the HSAIL backend, we had support for CompareAndSwapNode. (we had not pushed this out to the trunk yet). > > As part of the merge with the new runtime infrastructure changes, I see that our CompareAndSwapNode support is broken. > I'm trying to understand how to get it working again. > > In the particular test I'm looking at the java code calls atomicInt.getAndAdd(constant) Do you mean getAndAddInt? If you are talking about the Unsafe guys these exist since 1.8. So compiling (and running) with 7 or 8 definitely makes a difference. > > First I noticed that we were getting Invoke nodes for things like getIntVolatile and compareAndSwapInt. > So I assumed the UnsafeSubstitutions needed to be enabled for our backend. > > When I enabled these, I got the following error which doesn't mean anything to me... > > java.lang.AssertionError: has unexpected usage 20|LoadField#value of checkcast 19|GuardingPi at > at com.oracle.graal.replacements.NodeIntrinsificationPhase.checkCheckCastUsage(NodeIntrinsificationPhase.java:387) > at com.oracle.graal.replacements.NodeIntrinsificationPhase.checkCheckCastUsage(NodeIntrinsificationPhase.java:382) > at com.oracle.graal.replacements.NodeIntrinsificationPhase.cleanUpReturnCheckCast(NodeIntrinsificationPhase.java:328) > at com.oracle.graal.replacements.NodeIntrinsificationPhase.run(NodeIntrinsificationPhase.java:67) > > Any suggestions? > > -- Tom > From thomas.wuerthinger at oracle.com Fri Oct 25 06:10:58 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Fri, 25 Oct 2013 15:10:58 +0200 Subject: another java 8 strangeness In-Reply-To: References: , Message-ID: <7F89AA51-C5A4-4A56-9472-E121D9FF81EC@oracle.com> Tom, We've sent a request for the Graal project to be included in the publicly visible OpenJDK bug tracking system according to [1]. After a positive response, we will create public JIRA issues for Graal-related bugs and feature enhancements. - thomas [1] https://wiki.openjdk.java.net/display/general/JBS+Overview On Oct 25, 2013, at 2:59 PM, "Deneau, Tom" wrote: > Doug -- > > Are these internal JIRA issues viewable by folks outside Oracle? > > Is this JDK8 issue something recent and does it go beyond just igv? We have been using JDK8 with graal for at least 6 months now with no problems (except of course not being able to use Eclipse). > > -- Tom > > ________________________________________ > From: Doug Simon [doug.simon at oracle.com] > Sent: Thursday, October 24, 2013 5:42 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: another java 8 strangeness > > On Oct 25, 2013, at 12:28 AM, "Deneau, Tom" wrote: > >> I had built all of graal with java 8 and except for the aforementioned CompareAndSwap tests, all our other tests were passing. >> >> I wanted to use igv. But the GUI would not start. >> >> But when I went back and built graal with java 7, mx igv seemed to work fine. >> Is this a known problem? > > Yes. We have an internal JIRA issue for migrating to JDK8 but we are not there yet. Until it's officially supported, I recommend staying with JDK7 for Graal development. > > -Doug > From tom.deneau at amd.com Fri Oct 25 06:14:10 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 25 Oct 2013 13:14:10 +0000 Subject: CompareAndSwapNode support In-Reply-To: References: , <08621896-62DF-466A-958D-9B781B51C0EB@oracle.com>, Message-ID: Should also add that the java 8 build of the newly merged graal is able to successfully run all of our other junit tests, just not the ones dealing with CompareAndSwapNode subsitutions. -- Tom ________________________________________ From: graal-dev-bounces at openjdk.java.net [graal-dev-bounces at openjdk.java.net] on behalf of Deneau, Tom Sent: Friday, October 25, 2013 8:07 AM To: Christian Thalinger Cc: graal-dev at openjdk.java.net Subject: RE: CompareAndSwapNode support Just to further clarify... We had a HSAIL junit test that called AtomicInteger.getAndAddInt from a lambda. This made it java 8 specific. This test worked fine (building and running graal with java 8) up until we started doing this merge with the new infrastructure changes. We now have a version of this test that does the same thing but does not use lambdas. So this new version can be invoked from java 7. This new java7-style junit test still fails when we build our newly merged graal (newly merged with the new infrastructure) with java 8-b109 and try to run the test. The top of the stack trace is shown below. But if I build our merged graal with java7 b21 this new junit test succeeds. -- Toim ________________________________________ From: Christian Thalinger [christian.thalinger at oracle.com] Sent: Thursday, October 24, 2013 8:00 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: CompareAndSwapNode support On Oct 24, 2013, at 3:24 PM, Deneau, Tom wrote: > Some additional information on this... > > The original junit test was written using lambdas and so could not be run under java 7. Since our junit framework also supports java7 style tests, I rewrote the test to be java 7, and rebuilt graal with java 7. And with no other changes to graal, the test now passes. > > Does this make any sense? > > -- Tom > > From: Deneau, Tom > Sent: Thursday, October 24, 2013 3:21 PM > To: graal-dev at openjdk.java.net > Subject: CompareAndSwapNode support > > In the HSAIL backend, we had support for CompareAndSwapNode. (we had not pushed this out to the trunk yet). > > As part of the merge with the new runtime infrastructure changes, I see that our CompareAndSwapNode support is broken. > I'm trying to understand how to get it working again. > > In the particular test I'm looking at the java code calls atomicInt.getAndAdd(constant) Do you mean getAndAddInt? If you are talking about the Unsafe guys these exist since 1.8. So compiling (and running) with 7 or 8 definitely makes a difference. > > First I noticed that we were getting Invoke nodes for things like getIntVolatile and compareAndSwapInt. > So I assumed the UnsafeSubstitutions needed to be enabled for our backend. > > When I enabled these, I got the following error which doesn't mean anything to me... > > java.lang.AssertionError: has unexpected usage 20|LoadField#value of checkcast 19|GuardingPi at > at com.oracle.graal.replacements.NodeIntrinsificationPhase.checkCheckCastUsage(NodeIntrinsificationPhase.java:387) > at com.oracle.graal.replacements.NodeIntrinsificationPhase.checkCheckCastUsage(NodeIntrinsificationPhase.java:382) > at com.oracle.graal.replacements.NodeIntrinsificationPhase.cleanUpReturnCheckCast(NodeIntrinsificationPhase.java:328) > at com.oracle.graal.replacements.NodeIntrinsificationPhase.run(NodeIntrinsificationPhase.java:67) > > Any suggestions? > > -- Tom > From doug.simon at oracle.com Fri Oct 25 06:23:24 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 25 Oct 2013 15:23:24 +0200 Subject: another java 8 strangeness In-Reply-To: <7F89AA51-C5A4-4A56-9472-E121D9FF81EC@oracle.com> References: , <7F89AA51-C5A4-4A56-9472-E121D9FF81EC@oracle.com> Message-ID: In the meantime, here's a snapshot of the internal JIRA issue: https://www.dropbox.com/s/4mflnqf3k919blk/GRAAL-420.pdf -Doug On Oct 25, 2013, at 3:10 PM, Thomas Wuerthinger wrote: > Tom, > > We've sent a request for the Graal project to be included in the publicly visible OpenJDK bug tracking system according to [1]. After a positive response, we will create public JIRA issues for Graal-related bugs and feature enhancements. > > - thomas > > [1] https://wiki.openjdk.java.net/display/general/JBS+Overview > > On Oct 25, 2013, at 2:59 PM, "Deneau, Tom" wrote: > >> Doug -- >> >> Are these internal JIRA issues viewable by folks outside Oracle? >> >> Is this JDK8 issue something recent and does it go beyond just igv? We have been using JDK8 with graal for at least 6 months now with no problems (except of course not being able to use Eclipse). >> >> -- Tom >> >> ________________________________________ >> From: Doug Simon [doug.simon at oracle.com] >> Sent: Thursday, October 24, 2013 5:42 PM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: another java 8 strangeness >> >> On Oct 25, 2013, at 12:28 AM, "Deneau, Tom" wrote: >> >>> I had built all of graal with java 8 and except for the aforementioned CompareAndSwap tests, all our other tests were passing. >>> >>> I wanted to use igv. But the GUI would not start. >>> >>> But when I went back and built graal with java 7, mx igv seemed to work fine. >>> Is this a known problem? >> >> Yes. We have an internal JIRA issue for migrating to JDK8 but we are not there yet. Until it's officially supported, I recommend staying with JDK7 for Graal development. >> >> -Doug >> > From jjfumero at gmail.com Fri Oct 25 08:37:07 2013 From: jjfumero at gmail.com (=?ISO-8859-1?Q?Juan_Jos=E9_Fumero_Alfonso?=) Date: Fri, 25 Oct 2013 16:37:07 +0100 Subject: Inlining methods Message-ID: Hello, I am working with the OpenCL Component of Graal (com.edinburgh.parallel.opencl). This version is not public yet but It uses Graal to get the user code and generates OpenCL kernels. I have to create an Inlining optimization for my own code using Graal. Now I have something like that: GraalCodeCacheProvider runtime = Graal.getRequiredCapability(GraalCodeCacheProvider.class); ResolvedJavaMethod javaMethod = runtime.lookupJavaMethod(method); * OptimisticOptimizations oo = new OptimisticOptimizations(javaMethod);* oo.add(OptimisticOptimizations.Optimization.UseTypeCheckedInlining); The package is com.oracle.graal.phases; How can I ensure that the method is inline at the end? I am using the -XX:+PrintCompilation options but there is not much information. Also I tried with the -XX:+PrintInlining but it seems this options does not exist. Is this the proper way to get it? Thank you Juan Jos? Fumero From Gary.Frost at amd.com Fri Oct 25 08:55:08 2013 From: Gary.Frost at amd.com (Frost, Gary) Date: Fri, 25 Oct 2013 15:55:08 +0000 Subject: Inlining methods In-Reply-To: References: Message-ID: An OpenCL backend for Graal. That sounds like a fun project. You might also consider tracking the Sumatra project discussions. For the Sumatra HSAIL generation we turn inline everything using :- -G:+InlineEverything -G:Log=InliningDecisions Gary -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Juan Jos? Fumero Alfonso Sent: Friday, October 25, 2013 10:37 AM To: graal-dev at openjdk.java.net Subject: Inlining methods Hello, I am working with the OpenCL Component of Graal (com.edinburgh.parallel.opencl). This version is not public yet but It uses Graal to get the user code and generates OpenCL kernels. I have to create an Inlining optimization for my own code using Graal. Now I have something like that: GraalCodeCacheProvider runtime = Graal.getRequiredCapability(GraalCodeCacheProvider.class); ResolvedJavaMethod javaMethod = runtime.lookupJavaMethod(method); * OptimisticOptimizations oo = new OptimisticOptimizations(javaMethod);* oo.add(OptimisticOptimizations.Optimization.UseTypeCheckedInlining); The package is com.oracle.graal.phases; How can I ensure that the method is inline at the end? I am using the -XX:+PrintCompilation options but there is not much information. Also I tried with the -XX:+PrintInlining but it seems this options does not exist. Is this the proper way to get it? Thank you Juan Jos? Fumero From Gary.Frost at amd.com Fri Oct 25 09:21:20 2013 From: Gary.Frost at amd.com (Frost, Gary) Date: Fri, 25 Oct 2013 16:21:20 +0000 Subject: Inlining methods In-Reply-To: References: Message-ID: WRT -XX:+PrintInlining I think you may also need -XX:+UnlockDiagnosticVMOptions if you are using a product JVM build. Gary -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Juan Jos? Fumero Alfonso Sent: Friday, October 25, 2013 10:37 AM To: graal-dev at openjdk.java.net Subject: Inlining methods Hello, I am working with the OpenCL Component of Graal (com.edinburgh.parallel.opencl). This version is not public yet but It uses Graal to get the user code and generates OpenCL kernels. I have to create an Inlining optimization for my own code using Graal. Now I have something like that: GraalCodeCacheProvider runtime = Graal.getRequiredCapability(GraalCodeCacheProvider.class); ResolvedJavaMethod javaMethod = runtime.lookupJavaMethod(method); * OptimisticOptimizations oo = new OptimisticOptimizations(javaMethod);* oo.add(OptimisticOptimizations.Optimization.UseTypeCheckedInlining); The package is com.oracle.graal.phases; How can I ensure that the method is inline at the end? I am using the -XX:+PrintCompilation options but there is not much information. Also I tried with the -XX:+PrintInlining but it seems this options does not exist. Is this the proper way to get it? Thank you Juan Jos? Fumero From jjfumero at gmail.com Fri Oct 25 09:37:38 2013 From: jjfumero at gmail.com (=?ISO-8859-1?Q?Juan_Jos=E9_Fumero_Alfonso?=) Date: Fri, 25 Oct 2013 17:37:38 +0100 Subject: Inlining methods In-Reply-To: References: Message-ID: Hi Gary, I get the same output with the -XX:+UnlockDiagnosticVMOptions, only this: 62 1 n com.oracle.graal.hotspot.bridge.CompilerToVMImpl::executeCompiledMethodIntrinsic (native) (static) 168 2 n java.lang.System::arraycopy (native) (static) The option -G:+InlineEverything does not exist in my version. Thanks Juan Jos? Fumero 2013/10/25 Frost, Gary > WRT -XX:+PrintInlining I think you may also need > -XX:+UnlockDiagnosticVMOptions if you are using a product JVM > build. > > Gary > > > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto: > graal-dev-bounces at openjdk.java.net] On Behalf Of Juan Jos? Fumero Alfonso > Sent: Friday, October 25, 2013 10:37 AM > To: graal-dev at openjdk.java.net > Subject: Inlining methods > > Hello, > I am working with the OpenCL Component of Graal > (com.edinburgh.parallel.opencl). This version is not public yet but It uses > Graal to get the user code and generates OpenCL kernels. I have to create > an Inlining optimization for my own code using Graal. Now I have something > like that: > > GraalCodeCacheProvider runtime = > Graal.getRequiredCapability(GraalCodeCacheProvider.class); > ResolvedJavaMethod javaMethod = runtime.lookupJavaMethod(method); > > * OptimisticOptimizations oo = new > OptimisticOptimizations(javaMethod);* > > > oo.add(OptimisticOptimizations.Optimization.UseTypeCheckedInlining); > > The package is com.oracle.graal.phases; > > How can I ensure that the method is inline at the end? I am using the > -XX:+PrintCompilation options but there is not much information. Also I > tried with the -XX:+PrintInlining but it seems this options does not exist. > Is this the proper way to get it? > > > Thank you > Juan Jos? Fumero > > > From mick.jordan at oracle.com Fri Oct 25 09:47:42 2013 From: mick.jordan at oracle.com (Mick Jordan) Date: Fri, 25 Oct 2013 09:47:42 -0700 Subject: mx documentation Message-ID: <526AA0AE.3060808@oracle.com> There is some fledgling documentation on the mx tool available at https://wiki.openjdk.java.net/display/Graal/The+mx+Tool. It is also linked from the main Graal page. I wrote this initially to spec the multiple suite support and the new commands that drive hg. However, my intention is that it is eventually complete and accurate for all commands, including those in the extension suites such as graal. So far I have documented all the built-in commands, to varying degrees. Feedback is welcome. On the multiple suite support: If you are developing code that either extends Graal, e.g. a new backend, or uses Graal, that you would prefer to keep separate, then this is now possible. The mx suite support essentially makes the separation transparent when it comes to development, including in an IDE. If you have questions that the documentation does not address, please contact me via the list of directly. Mick From tom.deneau at amd.com Fri Oct 25 11:27:04 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 25 Oct 2013 18:27:04 +0000 Subject: another java 8 strangeness In-Reply-To: References: Message-ID: Doug or others -- Just wanted to clarify this recommendation. Are you saying don't use java 8 if you're trying to use igv, or are you saying don't use java 8 for any graal-related development? (As mentioned, up until now we haven't had any problems with java 8 except using it with eclipse). I was not able to open https://www.dropbox.com/s/4mflnqf3k919blk/GRAAL-420.pdf -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Thursday, October 24, 2013 5:42 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: another java 8 strangeness On Oct 25, 2013, at 12:28 AM, "Deneau, Tom" wrote: > I had built all of graal with java 8 and except for the aforementioned CompareAndSwap tests, all our other tests were passing. > > I wanted to use igv. But the GUI would not start. > > But when I went back and built graal with java 7, mx igv seemed to work fine. > Is this a known problem? Yes. We have an internal JIRA issue for migrating to JDK8 but we are not there yet. Until it's officially supported, I recommend staying with JDK7 for Graal development. -Doug From Gary.Frost at amd.com Fri Oct 25 11:39:45 2013 From: Gary.Frost at amd.com (Frost, Gary) Date: Fri, 25 Oct 2013 18:39:45 +0000 Subject: Inlining methods In-Reply-To: References: Message-ID: I think -G:+InlineEverything was pushed to main line a few months back - July maybe? When was your dev branch made? Gary From: Juan Jos? Fumero Alfonso [mailto:jjfumero at gmail.com] Sent: Friday, October 25, 2013 11:38 AM To: Frost, Gary Cc: graal-dev at openjdk.java.net Subject: Re: Inlining methods Hi Gary, I get the same output with the -XX:+UnlockDiagnosticVMOptions, only this: 62 1 n com.oracle.graal.hotspot.bridge.CompilerToVMImpl::executeCompiledMethodIntrinsic (native) (static) 168 2 n java.lang.System::arraycopy (native) (static) The option -G:+InlineEverything does not exist in my version. Thanks Juan Jos? Fumero 2013/10/25 Frost, Gary > WRT -XX:+PrintInlining I think you may also need -XX:+UnlockDiagnosticVMOptions if you are using a product JVM build. Gary -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Juan Jos? Fumero Alfonso Sent: Friday, October 25, 2013 10:37 AM To: graal-dev at openjdk.java.net Subject: Inlining methods Hello, I am working with the OpenCL Component of Graal (com.edinburgh.parallel.opencl). This version is not public yet but It uses Graal to get the user code and generates OpenCL kernels. I have to create an Inlining optimization for my own code using Graal. Now I have something like that: GraalCodeCacheProvider runtime = Graal.getRequiredCapability(GraalCodeCacheProvider.class); ResolvedJavaMethod javaMethod = runtime.lookupJavaMethod(method); * OptimisticOptimizations oo = new OptimisticOptimizations(javaMethod);* oo.add(OptimisticOptimizations.Optimization.UseTypeCheckedInlining); The package is com.oracle.graal.phases; How can I ensure that the method is inline at the end? I am using the -XX:+PrintCompilation options but there is not much information. Also I tried with the -XX:+PrintInlining but it seems this options does not exist. Is this the proper way to get it? Thank you Juan Jos? Fumero From doug.simon at oracle.com Fri Oct 25 12:33:23 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 25 Oct 2013 21:33:23 +0200 Subject: another java 8 strangeness In-Reply-To: References: Message-ID: On Oct 25, 2013, at 8:27 PM, "Deneau, Tom" wrote: > Doug or others -- > > Just wanted to clarify this recommendation. > Are you saying don't use java 8 if you're trying to use igv, or are you saying don't use java 8 for any graal-related development? (As mentioned, up until now we haven't had any problems with java 8 except using it with eclipse). Until all issues with JDK 8 have been resolved, most of us are working with JDK 7. If you don't run into any issue with 8, that's great. However, if you do, you may be on your own until the project has officially moved to 8. That said, feel free to inform us of further issues you encounter with 8 so that we can track them. > > I was not able to open > https://www.dropbox.com/s/4mflnqf3k919blk/GRAAL-420.pdf I removed it as we'd rather push for getting an OpenJDK JIRA instance up and running to share the details of such issues. -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Thursday, October 24, 2013 5:42 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: another java 8 strangeness > > > On Oct 25, 2013, at 12:28 AM, "Deneau, Tom" wrote: > >> I had built all of graal with java 8 and except for the aforementioned CompareAndSwap tests, all our other tests were passing. >> >> I wanted to use igv. But the GUI would not start. >> >> But when I went back and built graal with java 7, mx igv seemed to work fine. >> Is this a known problem? > > Yes. We have an internal JIRA issue for migrating to JDK8 but we are not there yet. Until it's officially supported, I recommend staying with JDK7 for Graal development. > > -Doug > From tom.deneau at amd.com Fri Oct 25 13:16:31 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 25 Oct 2013 20:16:31 +0000 Subject: another java 8 strangeness In-Reply-To: References: Message-ID: Doug -- OK, I just wanted to remind people that our main reason for using graal is as part of a Sumatra prototype project, which uses Stream API offloading and thus requires Java 8. So for that we don't have the luxury of staying at Java 7. A smaller issue is that many of our junit test cases were written in java 8 lambda style, although it's possible to rewrite these as Java 7 style. Up until this issue, I don't think we ever hit any graal compilation issue that worked on 7 and didn't work on 8. For this particular issue with Unsafe.CompareAndSwap substitution, we can probably just avoid using that from Java 8 but I was hoping someone with more graal knowledge than we have could root cause it. -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Friday, October 25, 2013 2:33 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: another java 8 strangeness On Oct 25, 2013, at 8:27 PM, "Deneau, Tom" wrote: > Doug or others -- > > Just wanted to clarify this recommendation. > Are you saying don't use java 8 if you're trying to use igv, or are you saying don't use java 8 for any graal-related development? (As mentioned, up until now we haven't had any problems with java 8 except using it with eclipse). Until all issues with JDK 8 have been resolved, most of us are working with JDK 7. If you don't run into any issue with 8, that's great. However, if you do, you may be on your own until the project has officially moved to 8. That said, feel free to inform us of further issues you encounter with 8 so that we can track them. > > I was not able to open > https://www.dropbox.com/s/4mflnqf3k919blk/GRAAL-420.pdf I removed it as we'd rather push for getting an OpenJDK JIRA instance up and running to share the details of such issues. -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Thursday, October 24, 2013 5:42 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: another java 8 strangeness > > > On Oct 25, 2013, at 12:28 AM, "Deneau, Tom" wrote: > >> I had built all of graal with java 8 and except for the aforementioned CompareAndSwap tests, all our other tests were passing. >> >> I wanted to use igv. But the GUI would not start. >> >> But when I went back and built graal with java 7, mx igv seemed to work fine. >> Is this a known problem? > > Yes. We have an internal JIRA issue for migrating to JDK8 but we are not there yet. Until it's officially supported, I recommend staying with JDK7 for Graal development. > > -Doug > From doug.simon at oracle.com Fri Oct 25 14:39:18 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 25 Oct 2013 23:39:18 +0200 Subject: another java 8 strangeness In-Reply-To: References: Message-ID: <348908F7-F725-40A2-AC88-CAB121FEF596@oracle.com> Believe me - we want to move to jdk8 as soon as it is practical as well. -Doug On Oct 25, 2013, at 10:16 PM, "Deneau, Tom" wrote: > Doug -- > > OK, I just wanted to remind people that our main reason for using graal is as part of a Sumatra prototype project, which uses Stream API offloading and thus requires Java 8. So for that we don't have the luxury of staying at Java 7. > > A smaller issue is that many of our junit test cases were written in java 8 lambda style, although it's possible to rewrite these as Java 7 style. > > Up until this issue, I don't think we ever hit any graal compilation issue that worked on 7 and didn't work on 8. > > For this particular issue with Unsafe.CompareAndSwap substitution, we can probably just avoid using that from Java 8 but I was hoping someone with more graal knowledge than we have could root cause it. > > -- Tom > > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Friday, October 25, 2013 2:33 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: another java 8 strangeness > > > On Oct 25, 2013, at 8:27 PM, "Deneau, Tom" wrote: > >> Doug or others -- >> >> Just wanted to clarify this recommendation. >> Are you saying don't use java 8 if you're trying to use igv, or are you saying don't use java 8 for any graal-related development? (As mentioned, up until now we haven't had any problems with java 8 except using it with eclipse). > > Until all issues with JDK 8 have been resolved, most of us are working with JDK 7. If you don't run into any issue with 8, that's great. However, if you do, you may be on your own until the project has officially moved to 8. That said, feel free to inform us of further issues you encounter with 8 so that we can track them. > >> >> I was not able to open >> https://www.dropbox.com/s/4mflnqf3k919blk/GRAAL-420.pdf > > I removed it as we'd rather push for getting an OpenJDK JIRA instance up and running to share the details of such issues. > > -Doug > >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Thursday, October 24, 2013 5:42 PM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: another java 8 strangeness >> >> >> On Oct 25, 2013, at 12:28 AM, "Deneau, Tom" wrote: >> >>> I had built all of graal with java 8 and except for the aforementioned CompareAndSwap tests, all our other tests were passing. >>> >>> I wanted to use igv. But the GUI would not start. >>> >>> But when I went back and built graal with java 7, mx igv seemed to work fine. >>> Is this a known problem? >> >> Yes. We have an internal JIRA issue for migrating to JDK8 but we are not there yet. Until it's officially supported, I recommend staying with JDK7 for Graal development. >> >> -Doug >> > > > From doug.simon at oracle.com Sat Oct 26 19:00:54 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 27 Oct 2013 02:00:54 +0000 Subject: hg: graal/graal: 23 new changesets Message-ID: <20131027020243.0845462783@hg.openjdk.java.net> Changeset: f1b7b7d2dad5 Author: Thomas Wuerthinger Date: 2013-10-16 17:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f1b7b7d2dad5 Avoid null checks on frame array accesses. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/FrameWithoutBoxing.java Changeset: ce82cdbffe47 Author: Thomas Wuerthinger Date: 2013-10-16 21:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ce82cdbffe47 Merge. Changeset: 33fe56e68abd Author: Thomas Wuerthinger Date: 2013-10-17 14:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/33fe56e68abd Simplifications of OptimizedCallTarget. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: 42c8f76a98bf Author: Thomas Wuerthinger Date: 2013-10-17 15:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/42c8f76a98bf Move Truffle compilations to background compilation thread. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompiler.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java Changeset: 561217cf2ac5 Author: Thomas Wuerthinger Date: 2013-10-17 15:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/561217cf2ac5 Fix unused import. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: 890bea7925fd Author: Thomas Wuerthinger Date: 2013-10-17 16:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/890bea7925fd Merge. - graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXBackend.java - graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotGraalRuntime.java - graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotGraalRuntimeFactory.java - graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotGraalRuntime.java - graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotGraalRuntime.java - graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotGraalRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntimeFactory.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotForeignCallsProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotLoweringProvider.java Changeset: 36f39d0c9875 Author: Thomas Wuerthinger Date: 2013-10-17 17:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/36f39d0c9875 Fix checkstyle errors. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java Changeset: 3ee8ae69d676 Author: Thomas Wuerthinger Date: 2013-10-22 11:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3ee8ae69d676 Introduce TraceTruffleInliningTree option. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java Changeset: ce8dd5fa8d54 Author: Thomas Wuerthinger Date: 2013-10-22 11:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ce8dd5fa8d54 Merge. - graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/EliminatePartiallyRedundantGuardsPhase.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! 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/TruffleCompilerOptions.java Changeset: cf6cfa79593d Author: Thomas Wuerthinger Date: 2013-10-22 15:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cf6cfa79593d Merge. Changeset: faded4a83d63 Author: Thomas Wuerthinger Date: 2013-10-25 01:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/faded4a83d63 Merge. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: 80bbaf87fc89 Author: Thomas Wuerthinger Date: 2013-10-25 11:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/80bbaf87fc89 Merge. - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotLoweringProvider.java Changeset: 48bc171026d1 Author: Thomas Wuerthinger Date: 2013-10-25 12:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/48bc171026d1 Merge fixes. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java Changeset: 5310cc81f7e4 Author: Thomas Wuerthinger Date: 2013-10-25 13:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5310cc81f7e4 Merge. Changeset: 2520c78e4c28 Author: Thomas Wuerthinger Date: 2013-10-25 14:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2520c78e4c28 Merge fix. ! graal/com.oracle.graal.truffle.hotspot.amd64/src/com/oracle/graal/truffle/hotspot/amd64/util/OptimizedCallTargetFieldInfo.java Changeset: 7328f7def427 Author: Roland Schatz Date: 2013-10-25 15:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7328f7def427 Support more convert operations. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConvertNode.java Changeset: 868dba721f1e Author: Christos Kotselidis Date: 2013-10-25 19:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/868dba721f1e Remove UseNewCode from gate G1 verification run ! mx/commands.py Changeset: 86e5fc5ba6bd Author: Christos Kotselidis Date: 2013-10-25 19:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/86e5fc5ba6bd Reorder commit allocation's node writes to account for deferred barriers ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostLoweringProvider.java Changeset: 4995bb251e3a Author: Christos Kotselidis Date: 2013-10-25 19:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4995bb251e3a Fix unit tests ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java Changeset: a2340324fc79 Author: Christos Kotselidis Date: 2013-10-25 19:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a2340324fc79 Enable deferred init barriers ! src/share/vm/graal/graalGlobals.hpp Changeset: b81405d42861 Author: Christos Kotselidis Date: 2013-10-25 19:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b81405d42861 Merge Changeset: 62fb4919edc9 Author: Doug Simon Date: 2013-10-25 23:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/62fb4919edc9 cleaned up mechanism for saving registers and updating the callee save maps in stubs ! 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/AMD64HotSpotLIRGenerator.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/HotSpotBackend.java - graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64RegistersPreservationOp.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/AMD64ZapRegistersOp.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/StandardOp.java Changeset: 63c378b7c1c3 Author: Doug Simon Date: 2013-10-26 01:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/63c378b7c1c3 made Truffle compiler threads be named and have a debug configuration ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilerThread.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/DebugEnvironment.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerThread.java From christian.thalinger at oracle.com Sun Oct 27 11:18:06 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Sun, 27 Oct 2013 11:18:06 -0700 Subject: CompareAndSwapNode support In-Reply-To: References: , <08621896-62DF-466A-958D-9B781B51C0EB@oracle.com> Message-ID: On Oct 25, 2013, at 6:07 AM, Deneau, Tom wrote: > Just to further clarify... > > We had a HSAIL junit test that called AtomicInteger.getAndAddInt from a lambda. This made it java 8 specific. This test worked fine (building and running graal with java 8) up until we started doing this merge with the new infrastructure changes. > > We now have a version of this test that does the same thing but does not use lambdas. By ?does the same thing? you mean calling AtomicInteger.getAndAdd? The code for AtomicInteger.getAndAdd is different on 7 and 8: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/raw-file/tip/src/share/classes/java/util/concurrent/atomic/AtomicInteger.java public final int getAndAdd(int delta) { for (;;) { int current = get(); int next = current + delta; if (compareAndSet(current, next)) return current; } } http://hg.openjdk.java.net/jdk8/jdk8/jdk/raw-file/tip/src/share/classes/java/util/concurrent/atomic/AtomicInteger.java public final int getAndAdd(int delta) { return unsafe.getAndAddInt(this, valueOffset, delta); } That's why you get different code in the compiler. > So this new version can be invoked from java 7. This new java7-style junit test still fails when we build our newly merged graal (newly merged with the new infrastructure) with java 8-b109 and try to run the test. The top of the stack trace is shown below. > > But if I build our merged graal with java7 b21 this new junit test succeeds. > > -- Toim > > ________________________________________ > From: Christian Thalinger [christian.thalinger at oracle.com] > Sent: Thursday, October 24, 2013 8:00 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: CompareAndSwapNode support > > On Oct 24, 2013, at 3:24 PM, Deneau, Tom wrote: > >> Some additional information on this... >> >> The original junit test was written using lambdas and so could not be run under java 7. Since our junit framework also supports java7 style tests, I rewrote the test to be java 7, and rebuilt graal with java 7. And with no other changes to graal, the test now passes. >> >> Does this make any sense? >> >> -- Tom >> >> From: Deneau, Tom >> Sent: Thursday, October 24, 2013 3:21 PM >> To: graal-dev at openjdk.java.net >> Subject: CompareAndSwapNode support >> >> In the HSAIL backend, we had support for CompareAndSwapNode. (we had not pushed this out to the trunk yet). >> >> As part of the merge with the new runtime infrastructure changes, I see that our CompareAndSwapNode support is broken. >> I'm trying to understand how to get it working again. >> >> In the particular test I'm looking at the java code calls atomicInt.getAndAdd(constant) > > Do you mean getAndAddInt? If you are talking about the Unsafe guys these exist since 1.8. So compiling (and running) with 7 or 8 definitely makes a difference. > >> >> First I noticed that we were getting Invoke nodes for things like getIntVolatile and compareAndSwapInt. >> So I assumed the UnsafeSubstitutions needed to be enabled for our backend. >> >> When I enabled these, I got the following error which doesn't mean anything to me... >> >> java.lang.AssertionError: has unexpected usage 20|LoadField#value of checkcast 19|GuardingPi at >> at com.oracle.graal.replacements.NodeIntrinsificationPhase.checkCheckCastUsage(NodeIntrinsificationPhase.java:387) >> at com.oracle.graal.replacements.NodeIntrinsificationPhase.checkCheckCastUsage(NodeIntrinsificationPhase.java:382) >> at com.oracle.graal.replacements.NodeIntrinsificationPhase.cleanUpReturnCheckCast(NodeIntrinsificationPhase.java:328) >> at com.oracle.graal.replacements.NodeIntrinsificationPhase.run(NodeIntrinsificationPhase.java:67) >> >> Any suggestions? >> >> -- Tom >> > > > From christian.thalinger at oracle.com Sun Oct 27 11:26:55 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Sun, 27 Oct 2013 11:26:55 -0700 Subject: Inlining methods In-Reply-To: References: Message-ID: On Oct 25, 2013, at 9:37 AM, Juan Jos? Fumero Alfonso wrote: > Hi Gary, > I get the same output with the -XX:+UnlockDiagnosticVMOptions, only > this: > > 62 1 n > com.oracle.graal.hotspot.bridge.CompilerToVMImpl::executeCompiledMethodIntrinsic > (native) (static) > 168 2 n java.lang.System::arraycopy (native) (static) This is all the output you get? How are you running your test? > > The option -G:+InlineEverything does not exist in my version. > > Thanks > Juan Jos? Fumero > > > > > 2013/10/25 Frost, Gary > >> WRT -XX:+PrintInlining I think you may also need >> -XX:+UnlockDiagnosticVMOptions if you are using a product JVM >> build. >> >> Gary >> >> >> >> -----Original Message----- >> From: graal-dev-bounces at openjdk.java.net [mailto: >> graal-dev-bounces at openjdk.java.net] On Behalf Of Juan Jos? Fumero Alfonso >> Sent: Friday, October 25, 2013 10:37 AM >> To: graal-dev at openjdk.java.net >> Subject: Inlining methods >> >> Hello, >> I am working with the OpenCL Component of Graal >> (com.edinburgh.parallel.opencl). This version is not public yet but It uses >> Graal to get the user code and generates OpenCL kernels. I have to create >> an Inlining optimization for my own code using Graal. Now I have something >> like that: >> >> GraalCodeCacheProvider runtime = >> Graal.getRequiredCapability(GraalCodeCacheProvider.class); >> ResolvedJavaMethod javaMethod = runtime.lookupJavaMethod(method); >> >> * OptimisticOptimizations oo = new >> OptimisticOptimizations(javaMethod);* >> >> >> oo.add(OptimisticOptimizations.Optimization.UseTypeCheckedInlining); >> >> The package is com.oracle.graal.phases; >> >> How can I ensure that the method is inline at the end? I am using the >> -XX:+PrintCompilation options but there is not much information. Also I >> tried with the -XX:+PrintInlining but it seems this options does not exist. >> Is this the proper way to get it? >> >> >> Thank you >> Juan Jos? Fumero >> >> >> From jjfumero at gmail.com Mon Oct 28 02:24:50 2013 From: jjfumero at gmail.com (=?UTF-8?B?SnVhbiBKb3PDqSBGdW1lcm8=?=) Date: Mon, 28 Oct 2013 09:24:50 +0000 Subject: Inlining methods In-Reply-To: References: Message-ID: <526E2D62.6070705@gmail.com> Hello, Ok, I have just realized that I had -XX:-BootstrapGraal enabled. The output now is very verbose. .... Testing Phase.OptimisticInline [thread:11] scope: Compiling.GraalCompiler.FrontEnd.HighTier.Inlining.Inlining [thread:11] scope: Compiling.GraalCompiler.FrontEnd.HighTier.Inlining.Inlining.InliningDecisions inlining BitSet.initWords at 4: exact java.util.BitSet.wordIndex(int):int: trivial (relevance=1.000000, probability=1.000000, bonus=1.000000, nodes=6) 55835 -1 java.util.RegularEnumSet::add (9 bytes) made not entrant [thread:11] scope: Compiling.GraalCompiler.FrontEnd.HighTier.Inlining.Inlining [thread:11] scope: Compiling.GraalCompiler.FrontEnd.HighTier.Inlining.Inlining.InliningDecisions 55835 -1 java.util.RegularEnumSet::add (40 bytes) made not entrant inlining BitSet.@47: exact java.util.BitSet.initWords(int):void: relevance-based (relevance=1.000000, probability=1.000000, bonus=1.000000, nodes=13 <= 300.000000) true|| .... Thanks Juan Jos? Fumero 2013/10/27 Christian Thalinger > On Oct 25, 2013, at 9:37 AM, Juan Jos? Fumero Alfonso > wrote: > Hi Gary, > I get the same output with the -XX:+UnlockDiagnosticVMOptions, only > this: > > 62 1 n > com.oracle.graal.hotspot.bridge.CompilerToVMImpl::executeCompiledMethodIntrinsic > (native) (static) > 168 2 n java.lang.System::arraycopy (native) (static) This is all the output you get? How are you running your test? > > The option -G:+InlineEverything does not exist in my version. > > Thanks > Juan Jos? Fumero > > > > > 2013/10/25 Frost, Gary > > >> WRT -XX:+PrintInlining I think you may also need >> -XX:+UnlockDiagnosticVMOptions if you are using a product JVM >> build. >> >> Gary >> >> >> >> -----Original Message----- >> From: graal-dev-bounces at openjdk.java.net [mailto: >> graal-dev-bounces at openjdk.java.net ] On Behalf Of Juan Jos? Fumero Alfonso >> Sent: Friday, October 25, 2013 10:37 AM >> To: graal-dev at openjdk.java.net >> Subject: Inlining methods >> >> Hello, >> I am working with the OpenCL Component of Graal >> (com.edinburgh.parallel.opencl). This version is not public yet but It uses >> Graal to get the user code and generates OpenCL kernels. I have to create >> an Inlining optimization for my own code using Graal. Now I have something >> like that: >> >> GraalCodeCacheProvider runtime = >> Graal.getRequiredCapability(GraalCodeCacheProvider.class); >> ResolvedJavaMethod javaMethod = runtime.lookupJavaMethod(method); >> >> * OptimisticOptimizations oo = new >> OptimisticOptimizations(javaMethod);* >> >> >> oo.add(OptimisticOptimizations.Optimization.UseTypeCheckedInlining); >> >> The package is com.oracle.graal.phases; >> >> How can I ensure that the method is inline at the end? I am using the >> -XX:+PrintCompilation options but there is not much information. Also I >> tried with the -XX:+PrintInlining but it seems this options does not exist. >> Is this the proper way to get it? >> >> >> Thank you >> Juan Jos? Fumero >> >> >> From tom.deneau at amd.com Mon Oct 28 06:11:49 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 28 Oct 2013 13:11:49 +0000 Subject: CompareAndSwapNode support In-Reply-To: References: , <08621896-62DF-466A-958D-9B781B51C0EB@oracle.com> Message-ID: And Unsafe.getAndAddInt in is the following in 8: public final int getAndAddInt(Object o, long offset, int delta) { int v; do { v = getIntVolatile(o, offset); } while (!compareAndSwapInt(o, offset, v, v + delta)); return v; } So I guess the volatile read is the difference. As further information on this, at the time I was getting this error on 8, I was only enabling Math and Unsafe substitutions in the HSAIL backend. When I enabled the fuller set of substitutions from GraalMethodSubstitutions, etc, the error on 8 went away. -- Tom -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Sunday, October 27, 2013 1:18 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: CompareAndSwapNode support On Oct 25, 2013, at 6:07 AM, Deneau, Tom wrote: > Just to further clarify... > > We had a HSAIL junit test that called AtomicInteger.getAndAddInt from a lambda. This made it java 8 specific. This test worked fine (building and running graal with java 8) up until we started doing this merge with the new infrastructure changes. > > We now have a version of this test that does the same thing but does not use lambdas. By "does the same thing" you mean calling AtomicInteger.getAndAdd? The code for AtomicInteger.getAndAdd is different on 7 and 8: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/raw-file/tip/src/share/classes/java/util/concurrent/atomic/AtomicInteger.java public final int getAndAdd(int delta) { for (;;) { int current = get(); int next = current + delta; if (compareAndSet(current, next)) return current; } } http://hg.openjdk.java.net/jdk8/jdk8/jdk/raw-file/tip/src/share/classes/java/util/concurrent/atomic/AtomicInteger.java public final int getAndAdd(int delta) { return unsafe.getAndAddInt(this, valueOffset, delta); } That's why you get different code in the compiler. > So this new version can be invoked from java 7. This new java7-style junit test still fails when we build our newly merged graal (newly merged with the new infrastructure) with java 8-b109 and try to run the test. The top of the stack trace is shown below. > > But if I build our merged graal with java7 b21 this new junit test succeeds. > > -- Toim > > ________________________________________ > From: Christian Thalinger [christian.thalinger at oracle.com] > Sent: Thursday, October 24, 2013 8:00 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: CompareAndSwapNode support > > On Oct 24, 2013, at 3:24 PM, Deneau, Tom wrote: > >> Some additional information on this... >> >> The original junit test was written using lambdas and so could not be run under java 7. Since our junit framework also supports java7 style tests, I rewrote the test to be java 7, and rebuilt graal with java 7. And with no other changes to graal, the test now passes. >> >> Does this make any sense? >> >> -- Tom >> >> From: Deneau, Tom >> Sent: Thursday, October 24, 2013 3:21 PM >> To: graal-dev at openjdk.java.net >> Subject: CompareAndSwapNode support >> >> In the HSAIL backend, we had support for CompareAndSwapNode. (we had not pushed this out to the trunk yet). >> >> As part of the merge with the new runtime infrastructure changes, I see that our CompareAndSwapNode support is broken. >> I'm trying to understand how to get it working again. >> >> In the particular test I'm looking at the java code calls atomicInt.getAndAdd(constant) > > Do you mean getAndAddInt? If you are talking about the Unsafe guys these exist since 1.8. So compiling (and running) with 7 or 8 definitely makes a difference. > >> >> First I noticed that we were getting Invoke nodes for things like getIntVolatile and compareAndSwapInt. >> So I assumed the UnsafeSubstitutions needed to be enabled for our backend. >> >> When I enabled these, I got the following error which doesn't mean anything to me... >> >> java.lang.AssertionError: has unexpected usage 20|LoadField#value of checkcast 19|GuardingPi at >> at com.oracle.graal.replacements.NodeIntrinsificationPhase.checkCheckCastUsage(NodeIntrinsificationPhase.java:387) >> at com.oracle.graal.replacements.NodeIntrinsificationPhase.checkCheckCastUsage(NodeIntrinsificationPhase.java:382) >> at com.oracle.graal.replacements.NodeIntrinsificationPhase.cleanUpReturnCheckCast(NodeIntrinsificationPhase.java:328) >> at com.oracle.graal.replacements.NodeIntrinsificationPhase.run(NodeIntrinsificationPhase.java:67) >> >> Any suggestions? >> >> -- Tom >> > > > From volker.simonis at gmail.com Mon Oct 28 09:54:27 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 28 Oct 2013 17:54:27 +0100 Subject: How to specify the build output directory? Message-ID: Hi, I've just started to play around with Graal but I couldn't find a way to specify a build output directory to the mx tool. While I personally don't like to clobber my source directory with unknown build artifacts (and I think it is good practice not to do so), not having the possibility to specify an arbitrary output directory also implies practical problems. The most important is that it seems to me that it is not possible to build Graal for two platforms from the same repository because the output will be mixed (and the settings in mx/env will be shared). For me, building the same repository on different platforms seems an essential feature. Otherwise I'll always have to mess with transplanting changesets back and forth to ensure the changes for one platform don't break another one. So to cut a long story short - is there a possibility with the current Graal build tools to redirect all the build output to a configurable directory? And if not, are there any plans to provide such a feature? Or am I missing something here? Thank you and best regards, Volker From doug.simon at oracle.com Mon Oct 28 10:17:05 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 28 Oct 2013 18:17:05 +0100 Subject: How to specify the build output directory? In-Reply-To: References: Message-ID: <4A303A16-2031-443C-BFEC-595610837D64@oracle.com> I think this should help: $ mx buildvars HotSpot build variables that can be set by the -D option to "mx build": ALT_BOOTDIR The location of the bootstrap JDK installation (default: /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home) ALT_OUTPUTDIR Build directory HOTSPOT_BUILD_JOBS Number of CPUs used by make (default: 4) INSTALL Install the built VM into the JDK? (default: y) ZIP_DEBUGINFO_FILES Install zipped debug symbols file? (default: 0) Note that these variables can be given persistent values in the file /Users/dsimon/linz/basic-graal/mx/env (see 'mx about'). You then use this in combination with the --installed-jdks option. For example: $ mx --installed-jdks /tmp/alt-jdks build -DALT_OUTPUTDIR=/tmp/alt-jdks/build Christian Thalinger has some experience using --installed-jdks for (re)using a current JDK workspace so he can provide further help if the 'mx help' info for the --installed-jdks option is not clear enough. -Doug On Oct 28, 2013, at 5:54 PM, Volker Simonis wrote: > Hi, > > I've just started to play around with Graal but I couldn't find a way > to specify a build output directory to the mx tool. > > While I personally don't like to clobber my source directory with > unknown build artifacts (and I think it is good practice not to do > so), not having the possibility to specify an arbitrary output > directory also implies practical problems. The most important is that > it seems to me that it is not possible to build Graal for two > platforms from the same repository because the output will be mixed > (and the settings in mx/env will be shared). > > For me, building the same repository on different platforms seems an > essential feature. Otherwise I'll always have to mess with > transplanting changesets back and forth to ensure the changes for one > platform don't break another one. > > So to cut a long story short - is there a possibility with the current > Graal build tools to redirect all the build output to a configurable > directory? And if not, are there any plans to provide such a feature? > Or am I missing something here? > > Thank you and best regards, > Volker From mick.jordan at oracle.com Mon Oct 28 10:43:31 2013 From: mick.jordan at oracle.com (Mick Jordan) Date: Mon, 28 Oct 2013 10:43:31 -0700 Subject: How to specify the build output directory? In-Reply-To: References: Message-ID: <526EA243.1030105@oracle.com> On 10/28/13 9:54 AM, Volker Simonis wrote: > Hi, > > I've just started to play around with Graal but I couldn't find a way > to specify a build output directory to the mx tool. > > While I personally don't like to clobber my source directory with > unknown build artifacts (and I think it is good practice not to do > so), not having the possibility to specify an arbitrary output > directory also implies practical problems. The most important is that > it seems to me that it is not possible to build Graal for two > platforms from the same repository because the output will be mixed > (and the settings in mx/env will be shared). > > For me, building the same repository on different platforms seems an > essential feature. Otherwise I'll always have to mess with > transplanting changesets back and forth to ensure the changes for one > platform don't break another one. > > So to cut a long story short - is there a possibility with the current > Graal build tools to redirect all the build output to a configurable > directory? And if not, are there any plans to provide such a feature? > Or am I missing something here? > > T Doug has answered the Hotspot side of this, which may be all you need. If mx has a philosophy (cf mvn), it is to focus on the source and hide the details of the binary files (derived) files. There has never been any support for cross-compilation to a different architecture in the same workspace, which is in a sense the degenerate form of multiple platform support. The problem is complicated by the myriad forms of derived output, which is not all conveniently located in one place. This became even more complicated when mx became responsible for building Hotspot (indirectly via gmake). In the past we have 'solved' this with target-specific clones of the repo. If you can do the majority of your development in one workspace and just test the other platforms, this works ok. In a sense then, the way you specify the output directory is to clone the workspace. If you are going to be jumping around actually developing platform-specific code on different platforms concurrently, then not so. Mick From volker.simonis at gmail.com Mon Oct 28 10:52:21 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 28 Oct 2013 18:52:21 +0100 Subject: How to specify the build output directory? In-Reply-To: <4A303A16-2031-443C-BFEC-595610837D64@oracle.com> References: <4A303A16-2031-443C-BFEC-595610837D64@oracle.com> Message-ID: Hi Doug, thanks for the hints. It seems to most important thing in my setup is to not persist JAVA_HOME in mx/env but instead use --java-home for every mx invocation. Otherwise mx won't work at all on all but the platform for which JAVA_HOME was set in mx/env. If I understand you right, I'll have to manually clone JAVA_HOME to my favorite --installed-jdks directory and use that in further invocations of mx build/run. I'll give it a try and let you know if it worked. Thanks, Volker On Mon, Oct 28, 2013 at 6:17 PM, Doug Simon wrote: > I think this should help: > > $ mx buildvars > HotSpot build variables that can be set by the -D option to "mx build": > > ALT_BOOTDIR > The location of the bootstrap JDK installation (default: /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home) > ALT_OUTPUTDIR > Build directory > HOTSPOT_BUILD_JOBS > Number of CPUs used by make (default: 4) > INSTALL > Install the built VM into the JDK? (default: y) > ZIP_DEBUGINFO_FILES > Install zipped debug symbols file? (default: 0) > > Note that these variables can be given persistent values in the file /Users/dsimon/linz/basic-graal/mx/env (see 'mx about'). > > You then use this in combination with the --installed-jdks option. For example: > > $ mx --installed-jdks /tmp/alt-jdks build -DALT_OUTPUTDIR=/tmp/alt-jdks/build > > Christian Thalinger has some experience using --installed-jdks for (re)using a current JDK workspace so he can provide further help if the 'mx help' info for the --installed-jdks option is not clear enough. > > -Doug > > On Oct 28, 2013, at 5:54 PM, Volker Simonis wrote: > >> Hi, >> >> I've just started to play around with Graal but I couldn't find a way >> to specify a build output directory to the mx tool. >> >> While I personally don't like to clobber my source directory with >> unknown build artifacts (and I think it is good practice not to do >> so), not having the possibility to specify an arbitrary output >> directory also implies practical problems. The most important is that >> it seems to me that it is not possible to build Graal for two >> platforms from the same repository because the output will be mixed >> (and the settings in mx/env will be shared). >> >> For me, building the same repository on different platforms seems an >> essential feature. Otherwise I'll always have to mess with >> transplanting changesets back and forth to ensure the changes for one >> platform don't break another one. >> >> So to cut a long story short - is there a possibility with the current >> Graal build tools to redirect all the build output to a configurable >> directory? And if not, are there any plans to provide such a feature? >> Or am I missing something here? >> >> Thank you and best regards, >> Volker > From volker.simonis at gmail.com Mon Oct 28 11:03:35 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 28 Oct 2013 19:03:35 +0100 Subject: How to specify the build output directory? In-Reply-To: <526EA243.1030105@oracle.com> References: <526EA243.1030105@oracle.com> Message-ID: Hi Mick, OpenJDK always had the ability to specify an alternative output direcory (ALT_OUTPUTDIR in the old build system or just the directory from which you call configure in the new build system). The same holds true for all GNU and autoconf configured software which actually strongly recommends not to build into the source directory. It may be that this is different for Maven which I'm not familiar at all with and which always seemed a little obscure to me. But anyway that only seems to work for Java-only code which is not the case here. Nevertheless thank you for pointing out the background of mx. I'll try and see how far I can get with you and Doug's hints. Regards, Volker PS: the big and ugly .hgignore file already seemed suspicious to me right after I cloned Graal for the first time:) Now I know why it is needed... On Mon, Oct 28, 2013 at 6:43 PM, Mick Jordan wrote: > On 10/28/13 9:54 AM, Volker Simonis wrote: >> >> Hi, >> >> I've just started to play around with Graal but I couldn't find a way >> to specify a build output directory to the mx tool. >> >> While I personally don't like to clobber my source directory with >> unknown build artifacts (and I think it is good practice not to do >> so), not having the possibility to specify an arbitrary output >> directory also implies practical problems. The most important is that >> it seems to me that it is not possible to build Graal for two >> platforms from the same repository because the output will be mixed >> (and the settings in mx/env will be shared). >> >> For me, building the same repository on different platforms seems an >> essential feature. Otherwise I'll always have to mess with >> transplanting changesets back and forth to ensure the changes for one >> platform don't break another one. >> >> So to cut a long story short - is there a possibility with the current >> Graal build tools to redirect all the build output to a configurable >> directory? And if not, are there any plans to provide such a feature? >> Or am I missing something here? >> >> T > > Doug has answered the Hotspot side of this, which may be all you need. If mx > has a philosophy (cf mvn), it is to focus on the source and hide the details > of the binary files (derived) files. There has never been any support for > cross-compilation to a different architecture in the same workspace, which > is in a sense the degenerate form of multiple platform support. The problem > is complicated by the myriad forms of derived output, which is not all > conveniently located in one place. This became even more complicated when mx > became responsible for building Hotspot (indirectly via gmake). > > In the past we have 'solved' this with target-specific clones of the repo. > If you can do the majority of your development in one workspace and just > test the other platforms, this works ok. In a sense then, the way you > specify the output directory is to clone the workspace. If you are going to > be jumping around actually developing platform-specific code on different > platforms concurrently, then not so. > > Mick > From mick.jordan at oracle.com Mon Oct 28 11:23:35 2013 From: mick.jordan at oracle.com (Mick Jordan) Date: Mon, 28 Oct 2013 11:23:35 -0700 Subject: How to specify the build output directory? In-Reply-To: References: <526EA243.1030105@oracle.com> Message-ID: <526EABA7.5040008@oracle.com> On 10/28/13 11:03 AM, Volker Simonis wrote: > Hi Mick, > > OpenJDK always had the ability to specify an alternative output > direcory (ALT_OUTPUTDIR in the old build system or just the directory > from which you call configure in the new build system). The same holds > true for all GNU and autoconf configured software which actually > strongly recommends not to build into the source directory. > > It may be that this is different for Maven which I'm not familiar at > all with and which always seemed a little obscure to me. But anyway > that only seems to work for Java-only code which is not the case here. > > Nevertheless thank you for pointing out the background of mx. I'll try > and see how far I can get with you and Doug's hints. > > Regards, > Volker > > PS: the big and ugly .hgignore file already seemed suspicious to me > right after I cloned Graal for the first time:) Now I know why it is > needed... > > Generally, I would absolutely agree with you that build directories should be completely separate from the source. In some sense that happens in the Java-only side of the mx world in that the 'bin' directory is separate from the 'src' directory and can be freely deleted with 'rm -r' without consequence. As you surmise mx started off supporting primarily Java in the Maxine VM research project. That system had almost no native code, just one project. Even though we supported, for a while, SPARC and x86 and Linux,MacOS and Solaris, we never put in the support to build those from the same workspace, because the gain didn't seem worthwhile. Developers typically worked on one architecture and one OS. Our testing infrastructure did all the multi-platform tests, all in separately cloned workspaces. Now, in addition to adding Hotspot into the mix, we also have 'derived' source created by annotation processors. In practice that code is platform-independent, but it's really an 'output'. Mick From christian.thalinger at oracle.com Mon Oct 28 20:26:41 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 28 Oct 2013 20:26:41 -0700 Subject: CompareAndSwapNode support In-Reply-To: References: , <08621896-62DF-466A-958D-9B781B51C0EB@oracle.com> Message-ID: On Oct 28, 2013, at 6:11 AM, Deneau, Tom wrote: > And Unsafe.getAndAddInt in is the following in 8: > > public final int getAndAddInt(Object o, long offset, int delta) { > int v; > do { > v = getIntVolatile(o, offset); > } while (!compareAndSwapInt(o, offset, v, v + delta)); > return v; > } > > > So I guess the volatile read is the difference. > > As further information on this, at the time I was getting this error on 8, I was only enabling Math and Unsafe substitutions in the HSAIL backend. When I enabled the fuller set of substitutions from GraalMethodSubstitutions, etc, the error on 8 went away. ?that makes it even more mysterious. Anyway, good for you :-) > > -- Tom > > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Sunday, October 27, 2013 1:18 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: CompareAndSwapNode support > > > On Oct 25, 2013, at 6:07 AM, Deneau, Tom wrote: > >> Just to further clarify... >> >> We had a HSAIL junit test that called AtomicInteger.getAndAddInt from a lambda. This made it java 8 specific. This test worked fine (building and running graal with java 8) up until we started doing this merge with the new infrastructure changes. >> >> We now have a version of this test that does the same thing but does not use lambdas. > > By "does the same thing" you mean calling AtomicInteger.getAndAdd? The code for AtomicInteger.getAndAdd is different on 7 and 8: > > http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/raw-file/tip/src/share/classes/java/util/concurrent/atomic/AtomicInteger.java > > public final int getAndAdd(int delta) { > for (;;) { > int current = get(); > int next = current + delta; > if (compareAndSet(current, next)) > return current; > } > } > > http://hg.openjdk.java.net/jdk8/jdk8/jdk/raw-file/tip/src/share/classes/java/util/concurrent/atomic/AtomicInteger.java > > public final int getAndAdd(int delta) { > return unsafe.getAndAddInt(this, valueOffset, delta); > } > > That's why you get different code in the compiler. > >> So this new version can be invoked from java 7. This new java7-style junit test still fails when we build our newly merged graal (newly merged with the new infrastructure) with java 8-b109 and try to run the test. The top of the stack trace is shown below. >> >> But if I build our merged graal with java7 b21 this new junit test succeeds. >> >> -- Toim >> >> ________________________________________ >> From: Christian Thalinger [christian.thalinger at oracle.com] >> Sent: Thursday, October 24, 2013 8:00 PM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: CompareAndSwapNode support >> >> On Oct 24, 2013, at 3:24 PM, Deneau, Tom wrote: >> >>> Some additional information on this... >>> >>> The original junit test was written using lambdas and so could not be run under java 7. Since our junit framework also supports java7 style tests, I rewrote the test to be java 7, and rebuilt graal with java 7. And with no other changes to graal, the test now passes. >>> >>> Does this make any sense? >>> >>> -- Tom >>> >>> From: Deneau, Tom >>> Sent: Thursday, October 24, 2013 3:21 PM >>> To: graal-dev at openjdk.java.net >>> Subject: CompareAndSwapNode support >>> >>> In the HSAIL backend, we had support for CompareAndSwapNode. (we had not pushed this out to the trunk yet). >>> >>> As part of the merge with the new runtime infrastructure changes, I see that our CompareAndSwapNode support is broken. >>> I'm trying to understand how to get it working again. >>> >>> In the particular test I'm looking at the java code calls atomicInt.getAndAdd(constant) >> >> Do you mean getAndAddInt? If you are talking about the Unsafe guys these exist since 1.8. So compiling (and running) with 7 or 8 definitely makes a difference. >> >>> >>> First I noticed that we were getting Invoke nodes for things like getIntVolatile and compareAndSwapInt. >>> So I assumed the UnsafeSubstitutions needed to be enabled for our backend. >>> >>> When I enabled these, I got the following error which doesn't mean anything to me... >>> >>> java.lang.AssertionError: has unexpected usage 20|LoadField#value of checkcast 19|GuardingPi at >>> at com.oracle.graal.replacements.NodeIntrinsificationPhase.checkCheckCastUsage(NodeIntrinsificationPhase.java:387) >>> at com.oracle.graal.replacements.NodeIntrinsificationPhase.checkCheckCastUsage(NodeIntrinsificationPhase.java:382) >>> at com.oracle.graal.replacements.NodeIntrinsificationPhase.cleanUpReturnCheckCast(NodeIntrinsificationPhase.java:328) >>> at com.oracle.graal.replacements.NodeIntrinsificationPhase.run(NodeIntrinsificationPhase.java:67) >>> >>> Any suggestions? >>> >>> -- Tom >>> >> >> >> > > > From christian.thalinger at oracle.com Mon Oct 28 20:49:07 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 28 Oct 2013 20:49:07 -0700 Subject: How to specify the build output directory? In-Reply-To: <4A303A16-2031-443C-BFEC-595610837D64@oracle.com> References: <4A303A16-2031-443C-BFEC-595610837D64@oracle.com> Message-ID: On Oct 28, 2013, at 10:17 AM, Doug Simon wrote: > I think this should help: > > $ mx buildvars > HotSpot build variables that can be set by the -D option to "mx build": > > ALT_BOOTDIR > The location of the bootstrap JDK installation (default: /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home) > ALT_OUTPUTDIR > Build directory > HOTSPOT_BUILD_JOBS > Number of CPUs used by make (default: 4) > INSTALL > Install the built VM into the JDK? (default: y) > ZIP_DEBUGINFO_FILES > Install zipped debug symbols file? (default: 0) > > Note that these variables can be given persistent values in the file /Users/dsimon/linz/basic-graal/mx/env (see 'mx about'). > > You then use this in combination with the --installed-jdks option. For example: > > $ mx --installed-jdks /tmp/alt-jdks build -DALT_OUTPUTDIR=/tmp/alt-jdks/build > > Christian Thalinger has some experience using --installed-jdks for (re)using a current JDK workspace so he can provide further help if the 'mx help' info for the --installed-jdks option is not clear enough. Since Volker is a long-term HotSpot guy like me :-) he probably also likes to build Graal directly. Essentially I never use mx to build or run stuff; just to set up Eclipse. To build a Graal-only VM just set your environment variables as you would do for a regular HotSpot build and do: $ make productgraal If you want to build hosted-Graal do: $ make product INCLUDE_GRAAL=true For my SPARC work I only built the C++ part, disabled the compilation of graal.jar: diff -r 7f55cdeec6af make/Makefile --- a/make/Makefile Mon Oct 28 17:03:59 2013 +0100 +++ b/make/Makefile Mon Oct 28 20:33:42 2013 -0700 @@ -282,7 +281,7 @@ generic_buildgraal: $(HOTSPOT_SCRIPT) bu # Builds code that can be shared among different build flavors buildshared: - python2.7 -u $(GAMMADIR)/mxtool/mx.py build --no-native --export-dir $(SHARED_DIR) +# python2.7 -u $(GAMMADIR)/mxtool/mx.py build --no-native --export-dir $(SHARED_DIR) and sym-linked graal.jar into my JDK copy (in my case over NFS, but that?s just a detail). Works like a charm. For running unit tests I created a sym-link to my JDK: $ ls -l jdk1.8.0-ea/ total 8 lrwxr-xr-x 1 cthaling staff 41 Oct 24 11:12 product@ -> /Users/cthaling/build/graal/jdk-universal and then you can run the test with: $ ./mx.sh --installed-jdks . --vm server unittest > > -Doug > > On Oct 28, 2013, at 5:54 PM, Volker Simonis wrote: > >> Hi, >> >> I've just started to play around with Graal but I couldn't find a way >> to specify a build output directory to the mx tool. >> >> While I personally don't like to clobber my source directory with >> unknown build artifacts (and I think it is good practice not to do >> so), not having the possibility to specify an arbitrary output >> directory also implies practical problems. The most important is that >> it seems to me that it is not possible to build Graal for two >> platforms from the same repository because the output will be mixed >> (and the settings in mx/env will be shared). >> >> For me, building the same repository on different platforms seems an >> essential feature. Otherwise I'll always have to mess with >> transplanting changesets back and forth to ensure the changes for one >> platform don't break another one. >> >> So to cut a long story short - is there a possibility with the current >> Graal build tools to redirect all the build output to a configurable >> directory? And if not, are there any plans to provide such a feature? >> Or am I missing something here? >> >> Thank you and best regards, >> Volker > From andreas.woess at jku.at Tue Oct 29 10:32:42 2013 From: andreas.woess at jku.at (Andreas Woess) Date: Tue, 29 Oct 2013 18:32:42 +0100 Subject: Truffle Node replacement problem caused by recursion In-Reply-To: References: Message-ID: <526FF13A.90401@jku.at> Hi Wei, Stefan, et al, I've pushed a fix about a week ago that solves this problem including an assertion that should trigger if you do anything wrong. Please update and let me know whether everything works as expected now. - andreas On 19.10.2013 01:44, Wei Zhang wrote: > Hi guys, > > I came across a problem with Truffle node replacement when I was > trying to apply Python level inlining to binarytrees.py (one of the > shootout benchmarks). I thought it is worth sharing it with all of you > that are using Truffle. > > Basically, recursion might cause inconsistencies in a Truffle AST. > That is a node's parent's children don't include itself. > > We all know binarytrees. This is the simplified AST that is enough to > show the problem: > > RootNodeOfFoo > Statement0 > Statement1 > BinaryOp > Call(foo) > Constant(1) > > When the function foo starts execution, BinaryOp node is specializing > itself from the Uninitialized state by executing its two operands > before it replaces itself with a specialized version. Because one of > its operand is a recursive call, the deepest recursive invocation will > specialized BinaryOp first. When it returns to an earlier active > BinaryOp.executeAndSpecialize0(), the node replacement will fail. At > that point, the children of BinaryOp have already adopted by the > lastly created BinaryOpSpecialized. We end up with a situation where > Call(foo)'s parent is not a child of RootNodeOfFoo. > > So when I try to replace the recursive call(foo) node with a inlined > version, I cannot do a simple node replacement. I have to lookup the > real parent that is reachable from the RootNodeOfFoo. > > Maybe it's not a bad idea to have some kind of failure detection of > node replacement... > Thanks, > -------------------------- > Wei Zhang > Personal: NdrZmansN at Gmail.com > From volker.simonis at gmail.com Tue Oct 29 11:57:06 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 29 Oct 2013 19:57:06 +0100 Subject: How do I get my PPC64HotSpotBackendFactory registered? Message-ID: Hi, if I pull the additional changes from hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot, merge them and add some minor changes to the Graal files I can now successfully build the Graal VM with the C++ interpreter like so: CC_INTERP=true ./mx.sh --java-home /usr/work/openjdk/output-jdk7u/j2sdk-image --vm graal --vmbuild debug build If I run it I get the following: ./jdk1.7.0-internal/debug/bin/java -graal -XX:-BootstrapGraal -XX:+CIPrintRequests -XX:+PrintCompilation -version 1789 1 n java.lang.invoke.MethodHandle::linkToStatic(LL)L (native) (static) 1905 2 n java.lang.invoke.MethodHandle::linkToStatic(LLL)L (native) (static) request: java.lang.String::indexOf comment: count count: 470 hot: yes 2087 3 n java.lang.invoke.MethodHandle::linkToStatic(LL)V (native) (static) 2108 4 n java.lang.invoke.MethodHandle::linkToStatic(LL)J (native) (static) 2138 5 n java.lang.invoke.MethodHandle::linkToStatic(LIL)V (native) (static) 2175 6 n com.oracle.graal.hotspot.bridge.CompilerToVMImpl::executeCompiledMethodIntrinsic (native) (static) request: java.lang.String::hashCode comment: count count: 722 hot: yes request: java.lang.String::indexOf comment: count count: 504 hot: yes request: java.lang.String::charAt comment: count count: 10000 hot: yes request: java.lang.String::hashCode comment: count count: 606 hot: yes request: java.lang.String::indexOf comment: count count: 386 hot: yes java.lang.ExceptionInInitializerError Caused by: java.lang.NullPointerException at com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime.java:223) at com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime.java:50) which is clear because there's no PPC64 support in Graal until now. I've then added a basic PPC64HotSpotBackendFactory/PPC64HotSpotBackend in the same way as this is done for the other architectures and recompiled but for some reason, still with the same result (i.e. no HotSpotBackendFactory can be found for PPC64). I've then printed the available factories in HotSpotGraalRuntime.findFactory (with printf debugging) and found that the following factories are available: ----------AMD64----------- ----------PTX----------- ----------HSAIL----------- Notice that SPARC is not listed here as well! I've then added the following lines: # graal.hotspot.ppc64 project at com.oracle.graal.hotspot.ppc64@subDir=graal project at com.oracle.graal.hotspot.ppc64@sourceDirs=src project at com.oracle.graal.hotspot.ppc64@dependencies=com.oracle.graal.hotspot,com.oracle.graal.ppc64 project at com.oracle.graal.hotspot.ppc64@checkstyle=com.oracle.graal.graph project at com.oracle.graal.hotspot.ppc64@annotationProcessors=com.oracle.graal.service.processor project at com.oracle.graal.hotspot.ppc64@javaCompliance=1.7 project at com.oracle.graal.hotspot.ppc64@workingSets=Graal,HotSpot,PPC64 to mx/projects and expected that the 'annotationProcessors' line will do the job - unfortunately without any success. I've then finally manually added the line: com.oracle.graal.hotspot.ppc64.PPC64HotSpotBackendFactory to the file META-INF/services/com.oracle.graal.hotspot.HotSpotBackendFactory in graal.jar and that finally did the job! I now get the following output when running the Graal VM: ./jdk1.7.0-internal/debug/bin/java -graal -XX:-BootstrapGraal -XX:+CIPrintRequests -XX:+PrintCompilation -version 3720 1 n java.lang.invoke.MethodHandle::linkToStatic(LL)L (native) (static) 3921 2 n java.lang.invoke.MethodHandle::linkToStatic(LLL)L (native) (static) request: java.lang.String::indexOf comment: count count: 470 hot: yes 4253 3 n java.lang.invoke.MethodHandle::linkToStatic(LL)V (native) (static) 4287 4 n java.lang.invoke.MethodHandle::linkToStatic(LL)J (native) (static) 4340 5 n java.lang.invoke.MethodHandle::linkToStatic(LIL)V (native) (static) 4406 6 n com.oracle.graal.hotspot.bridge.CompilerToVMImpl::executeCompiledMethodIntrinsic (native) (static) request: java.lang.String::hashCode comment: count count: 722 hot: yes request: java.lang.String::indexOf comment: count count: 504 hot: yes request: java.lang.String::charAt comment: count count: 10000 hot: yes request: java.lang.String::hashCode comment: count count: 606 hot: yes request: java.lang.String::indexOf comment: count count: 386 hot: yes com.oracle.graal.graph.GraalInternalError: unimplemented at com.oracle.graal.graph.GraalInternalError.unimplemented(GraalInternalError.java:38) at com.oracle.graal.hotspot.ppc64.PPC64HotSpotCodeCacheProvider.createRegisterConfig(PPC64HotSpotCodeCacheProvider.java:38) at com.oracle.graal.hotspot.meta.HotSpotCodeCacheProvider.(HotSpotCodeCacheProvider.java:54) at com.oracle.graal.hotspot.ppc64.PPC64HotSpotCodeCacheProvider.(PPC64HotSpotCodeCacheProvider.java:33) at com.oracle.graal.hotspot.ppc64.PPC64HotSpotBackendFactory.createBackend(PPC64HotSpotBackendFactory.java:53) at com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime.java:224) at com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime.java:50) which is OK, because PPC64HotSpotCodeCacheProvider.createRegisterConfig() currently throws an GraalInternalError. So now back to my initial question: how do I manage to get my PPC64HotSpotBackendFactory registered automatically without the need to manually edit the META_INF files? Thank you and best regards, Volker From D.Sturm42 at gmail.com Tue Oct 29 12:50:53 2013 From: D.Sturm42 at gmail.com (D.Sturm) Date: Tue, 29 Oct 2013 20:50:53 +0100 Subject: How do I get my PPC64HotSpotBackendFactory registered? In-Reply-To: References: Message-ID: I looked into that myself for the Aarch64 port, so I can give some insight: Basically it's not enough to just specify the annotationProcessor for your project. You also have to add the folder that contains your project to the "distribution at GRAAL@dependencies=\" list in the projects file. There are already several entries for amd64, etc. there. One important thing to consider: You have to list the *folder* and not the package name there (basically give it the path relative from graal/ to the directory containing the bin folder). mx will then automatically generate the correct META-INF entries for the annotationProcessors you specify. regards, Daniel. On 29 October 2013 19:57, Volker Simonis wrote: > Hi, > > if I pull the additional changes from > hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot, merge them and add some > minor changes to the Graal files I can now successfully build the > Graal VM with the C++ interpreter like so: > > CC_INTERP=true ./mx.sh --java-home > /usr/work/openjdk/output-jdk7u/j2sdk-image --vm graal --vmbuild debug > build > > If I run it I get the following: > > ./jdk1.7.0-internal/debug/bin/java -graal -XX:-BootstrapGraal > -XX:+CIPrintRequests -XX:+PrintCompilation -version > 1789 1 n > java.lang.invoke.MethodHandle::linkToStatic(LL)L (native) (static) > 1905 2 n > java.lang.invoke.MethodHandle::linkToStatic(LLL)L (native) (static) > request: java.lang.String::indexOf comment: count count: 470 hot: yes > 2087 3 n > java.lang.invoke.MethodHandle::linkToStatic(LL)V (native) (static) > 2108 4 n > java.lang.invoke.MethodHandle::linkToStatic(LL)J (native) (static) > 2138 5 n > java.lang.invoke.MethodHandle::linkToStatic(LIL)V (native) (static) > 2175 6 n > > com.oracle.graal.hotspot.bridge.CompilerToVMImpl::executeCompiledMethodIntrinsic > (native) (static) > request: java.lang.String::hashCode comment: count count: 722 hot: yes > request: java.lang.String::indexOf comment: count count: 504 hot: yes > request: java.lang.String::charAt comment: count count: 10000 hot: yes > request: java.lang.String::hashCode comment: count count: 606 hot: yes > request: java.lang.String::indexOf comment: count count: 386 hot: yes > java.lang.ExceptionInInitializerError > Caused by: java.lang.NullPointerException > at > com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime.java:223) > at > com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime.java:50) > > which is clear because there's no PPC64 support in Graal until now. > > I've then added a basic PPC64HotSpotBackendFactory/PPC64HotSpotBackend > in the same way as this is done for the other architectures and > recompiled but for some reason, still with the same result (i.e. no > HotSpotBackendFactory can be found for PPC64). I've then printed the > available factories in HotSpotGraalRuntime.findFactory (with printf > debugging) and found that the following factories are available: > > ----------AMD64----------- > ----------PTX----------- > ----------HSAIL----------- > > Notice that SPARC is not listed here as well! I've then added the > following lines: > > # graal.hotspot.ppc64 > project at com.oracle.graal.hotspot.ppc64@subDir=graal > project at com.oracle.graal.hotspot.ppc64@sourceDirs=src > project at com.oracle.graal.hotspot.ppc64 > @dependencies=com.oracle.graal.hotspot,com.oracle.graal.ppc64 > project at com.oracle.graal.hotspot.ppc64@checkstyle=com.oracle.graal.graph > project at com.oracle.graal.hotspot.ppc64 > @annotationProcessors=com.oracle.graal.service.processor > project at com.oracle.graal.hotspot.ppc64@javaCompliance=1.7 > project at com.oracle.graal.hotspot.ppc64@workingSets=Graal,HotSpot,PPC64 > > to mx/projects and expected that the 'annotationProcessors' line will > do the job - unfortunately without any success. > > I've then finally manually added the line: > > com.oracle.graal.hotspot.ppc64.PPC64HotSpotBackendFactory > > to the file > META-INF/services/com.oracle.graal.hotspot.HotSpotBackendFactory > in graal.jar and that finally did the job! I now get the following > output when running the Graal VM: > > ./jdk1.7.0-internal/debug/bin/java -graal -XX:-BootstrapGraal > -XX:+CIPrintRequests -XX:+PrintCompilation -version > 3720 1 n > java.lang.invoke.MethodHandle::linkToStatic(LL)L (native) (static) > 3921 2 n > java.lang.invoke.MethodHandle::linkToStatic(LLL)L (native) (static) > request: java.lang.String::indexOf comment: count count: 470 hot: yes > 4253 3 n > java.lang.invoke.MethodHandle::linkToStatic(LL)V (native) (static) > 4287 4 n > java.lang.invoke.MethodHandle::linkToStatic(LL)J (native) (static) > 4340 5 n > java.lang.invoke.MethodHandle::linkToStatic(LIL)V (native) (static) > 4406 6 n > > com.oracle.graal.hotspot.bridge.CompilerToVMImpl::executeCompiledMethodIntrinsic > (native) (static) > request: java.lang.String::hashCode comment: count count: 722 hot: yes > request: java.lang.String::indexOf comment: count count: 504 hot: yes > request: java.lang.String::charAt comment: count count: 10000 hot: yes > request: java.lang.String::hashCode comment: count count: 606 hot: yes > request: java.lang.String::indexOf comment: count count: 386 hot: yes > com.oracle.graal.graph.GraalInternalError: unimplemented > at > com.oracle.graal.graph.GraalInternalError.unimplemented(GraalInternalError.java:38) > at > com.oracle.graal.hotspot.ppc64.PPC64HotSpotCodeCacheProvider.createRegisterConfig(PPC64HotSpotCodeCacheProvider.java:38) > at > com.oracle.graal.hotspot.meta.HotSpotCodeCacheProvider.(HotSpotCodeCacheProvider.java:54) > at > com.oracle.graal.hotspot.ppc64.PPC64HotSpotCodeCacheProvider.(PPC64HotSpotCodeCacheProvider.java:33) > at > com.oracle.graal.hotspot.ppc64.PPC64HotSpotBackendFactory.createBackend(PPC64HotSpotBackendFactory.java:53) > at > com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime.java:224) > at > com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime.java:50) > > which is OK, because > PPC64HotSpotCodeCacheProvider.createRegisterConfig() currently throws > an GraalInternalError. > > So now back to my initial question: how do I manage to get my > PPC64HotSpotBackendFactory registered automatically without the need > to manually edit the META_INF files? > > Thank you and best regards, > Volker > From doug.simon at oracle.com Tue Oct 29 13:12:27 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 29 Oct 2013 21:12:27 +0100 Subject: How do I get my PPC64HotSpotBackendFactory registered? In-Reply-To: References: Message-ID: One extra thing you have to do after editing mx/projects is to clean the Java classes and rebuild them: % mx clean --no-native % mx build This is because currently, the simple out-of-date check used for a project's Java sources is only to look at the corresponding class files. I'll look into beefing up this check such that a change in a project's configuration makes the sources (conservatively) out-of-date. -Doug On Oct 29, 2013, at 8:50 PM, "D.Sturm" wrote: > I looked into that myself for the Aarch64 port, so I can give some insight: > > Basically it's not enough to just specify the annotationProcessor for your > project. You also have to add the folder that contains your project to the > "distribution at GRAAL@dependencies=\" list in the projects file. There are > already several entries for amd64, etc. there. One important thing to > consider: You have to list the *folder* and not the package name there > (basically give it the path relative from graal/ to the directory > containing the bin folder). mx will then automatically generate the correct > META-INF entries for the annotationProcessors you specify. > > regards, > Daniel. > > On 29 October 2013 19:57, Volker Simonis wrote: > >> Hi, >> >> if I pull the additional changes from >> hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot, merge them and add some >> minor changes to the Graal files I can now successfully build the >> Graal VM with the C++ interpreter like so: >> >> CC_INTERP=true ./mx.sh --java-home >> /usr/work/openjdk/output-jdk7u/j2sdk-image --vm graal --vmbuild debug >> build >> >> If I run it I get the following: >> >> ./jdk1.7.0-internal/debug/bin/java -graal -XX:-BootstrapGraal >> -XX:+CIPrintRequests -XX:+PrintCompilation -version >> 1789 1 n >> java.lang.invoke.MethodHandle::linkToStatic(LL)L (native) (static) >> 1905 2 n >> java.lang.invoke.MethodHandle::linkToStatic(LLL)L (native) (static) >> request: java.lang.String::indexOf comment: count count: 470 hot: yes >> 2087 3 n >> java.lang.invoke.MethodHandle::linkToStatic(LL)V (native) (static) >> 2108 4 n >> java.lang.invoke.MethodHandle::linkToStatic(LL)J (native) (static) >> 2138 5 n >> java.lang.invoke.MethodHandle::linkToStatic(LIL)V (native) (static) >> 2175 6 n >> >> com.oracle.graal.hotspot.bridge.CompilerToVMImpl::executeCompiledMethodIntrinsic >> (native) (static) >> request: java.lang.String::hashCode comment: count count: 722 hot: yes >> request: java.lang.String::indexOf comment: count count: 504 hot: yes >> request: java.lang.String::charAt comment: count count: 10000 hot: yes >> request: java.lang.String::hashCode comment: count count: 606 hot: yes >> request: java.lang.String::indexOf comment: count count: 386 hot: yes >> java.lang.ExceptionInInitializerError >> Caused by: java.lang.NullPointerException >> at >> com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime.java:223) >> at >> com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime.java:50) >> >> which is clear because there's no PPC64 support in Graal until now. >> >> I've then added a basic PPC64HotSpotBackendFactory/PPC64HotSpotBackend >> in the same way as this is done for the other architectures and >> recompiled but for some reason, still with the same result (i.e. no >> HotSpotBackendFactory can be found for PPC64). I've then printed the >> available factories in HotSpotGraalRuntime.findFactory (with printf >> debugging) and found that the following factories are available: >> >> ----------AMD64----------- >> ----------PTX----------- >> ----------HSAIL----------- >> >> Notice that SPARC is not listed here as well! I've then added the >> following lines: >> >> # graal.hotspot.ppc64 >> project at com.oracle.graal.hotspot.ppc64@subDir=graal >> project at com.oracle.graal.hotspot.ppc64@sourceDirs=src >> project at com.oracle.graal.hotspot.ppc64 >> @dependencies=com.oracle.graal.hotspot,com.oracle.graal.ppc64 >> project at com.oracle.graal.hotspot.ppc64@checkstyle=com.oracle.graal.graph >> project at com.oracle.graal.hotspot.ppc64 >> @annotationProcessors=com.oracle.graal.service.processor >> project at com.oracle.graal.hotspot.ppc64@javaCompliance=1.7 >> project at com.oracle.graal.hotspot.ppc64@workingSets=Graal,HotSpot,PPC64 >> >> to mx/projects and expected that the 'annotationProcessors' line will >> do the job - unfortunately without any success. >> >> I've then finally manually added the line: >> >> com.oracle.graal.hotspot.ppc64.PPC64HotSpotBackendFactory >> >> to the file >> META-INF/services/com.oracle.graal.hotspot.HotSpotBackendFactory >> in graal.jar and that finally did the job! I now get the following >> output when running the Graal VM: >> >> ./jdk1.7.0-internal/debug/bin/java -graal -XX:-BootstrapGraal >> -XX:+CIPrintRequests -XX:+PrintCompilation -version >> 3720 1 n >> java.lang.invoke.MethodHandle::linkToStatic(LL)L (native) (static) >> 3921 2 n >> java.lang.invoke.MethodHandle::linkToStatic(LLL)L (native) (static) >> request: java.lang.String::indexOf comment: count count: 470 hot: yes >> 4253 3 n >> java.lang.invoke.MethodHandle::linkToStatic(LL)V (native) (static) >> 4287 4 n >> java.lang.invoke.MethodHandle::linkToStatic(LL)J (native) (static) >> 4340 5 n >> java.lang.invoke.MethodHandle::linkToStatic(LIL)V (native) (static) >> 4406 6 n >> >> com.oracle.graal.hotspot.bridge.CompilerToVMImpl::executeCompiledMethodIntrinsic >> (native) (static) >> request: java.lang.String::hashCode comment: count count: 722 hot: yes >> request: java.lang.String::indexOf comment: count count: 504 hot: yes >> request: java.lang.String::charAt comment: count count: 10000 hot: yes >> request: java.lang.String::hashCode comment: count count: 606 hot: yes >> request: java.lang.String::indexOf comment: count count: 386 hot: yes >> com.oracle.graal.graph.GraalInternalError: unimplemented >> at >> com.oracle.graal.graph.GraalInternalError.unimplemented(GraalInternalError.java:38) >> at >> com.oracle.graal.hotspot.ppc64.PPC64HotSpotCodeCacheProvider.createRegisterConfig(PPC64HotSpotCodeCacheProvider.java:38) >> at >> com.oracle.graal.hotspot.meta.HotSpotCodeCacheProvider.(HotSpotCodeCacheProvider.java:54) >> at >> com.oracle.graal.hotspot.ppc64.PPC64HotSpotCodeCacheProvider.(PPC64HotSpotCodeCacheProvider.java:33) >> at >> com.oracle.graal.hotspot.ppc64.PPC64HotSpotBackendFactory.createBackend(PPC64HotSpotBackendFactory.java:53) >> at >> com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime.java:224) >> at >> com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime.java:50) >> >> which is OK, because >> PPC64HotSpotCodeCacheProvider.createRegisterConfig() currently throws >> an GraalInternalError. >> >> So now back to my initial question: how do I manage to get my >> PPC64HotSpotBackendFactory registered automatically without the need >> to manually edit the META_INF files? >> >> Thank you and best regards, >> Volker >> From tom.deneau at amd.com Tue Oct 29 15:56:20 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 29 Oct 2013 22:56:20 +0000 Subject: Code must (soon) comply with Eclipse formatting command In-Reply-To: <3BAD7365-0CCB-4143-8395-7D90E707C3C2@oracle.com> References: <3BAD7365-0CCB-4143-8395-7D90E707C3C2@oracle.com> Message-ID: Doug -- I noticed that graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetCounter.java from the trunk gets slightly modified by the command below. -- Tom -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon Sent: Monday, October 21, 2013 1:27 PM To: graal-dev at openjdk.java.net Subject: Code must (soon) comply with Eclipse formatting command The bugs preventing the Eclipse formatter from being used from the command line seem to have been fixed as of Eclipse 4.3[1]. As such, we will soon add a check in the gate that all incoming code is formatted according to this tool. If you are using Eclipse for development, this should not be a problem. If not, you should run the following before trying to push or submit a webrev: $ mx eclipseformat -e /path/to/eclipse4.3installation If this command reports that 0 files were modified, your changes should get through (this part of) the gate. -Doug [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=405338 From doug.simon at oracle.com Wed Oct 30 02:02:39 2013 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 30 Oct 2013 10:02:39 +0100 Subject: Code must (soon) comply with Eclipse formatting command In-Reply-To: References: <3BAD7365-0CCB-4143-8395-7D90E707C3C2@oracle.com> Message-ID: Oops, thanks! Obviously we haven't added this to the gate yet ;-) -Doug On Oct 29, 2013, at 11:56 PM, "Deneau, Tom" wrote: > Doug -- > > I noticed that > > graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetCounter.java > > from the trunk gets slightly modified by the command below. > > -- Tom > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon > Sent: Monday, October 21, 2013 1:27 PM > To: graal-dev at openjdk.java.net > Subject: Code must (soon) comply with Eclipse formatting command > > The bugs preventing the Eclipse formatter from being used from the command line seem to have been fixed as of Eclipse 4.3[1]. As such, we will soon add a check in the gate that all incoming code is formatted according to this tool. If you are using Eclipse for development, this should not be a problem. If not, you should run the following before trying to push or submit a webrev: > > $ mx eclipseformat -e /path/to/eclipse4.3installation > > If this command reports that 0 files were modified, your changes should get through (this part of) the gate. > > -Doug > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=405338 > > From bernhard.urban at jku.at Wed Oct 30 02:11:00 2013 From: bernhard.urban at jku.at (Bernhard Urban) Date: Wed, 30 Oct 2013 10:11:00 +0100 Subject: Code must (soon) comply with Eclipse formatting command In-Reply-To: References: <3BAD7365-0CCB-4143-8395-7D90E707C3C2@oracle.com> Message-ID: <5270CD24.5000502@jku.at> Tom, thanks for your notice. We do not enforce the eclipse formatter in our gate yet, so this was able to sneak through it. -Bernhard On 10/29/2013 11:56 PM, Deneau, Tom wrote: > Doug -- > > I noticed that > > graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetCounter.java > > from the trunk gets slightly modified by the command below. > > -- Tom > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon > Sent: Monday, October 21, 2013 1:27 PM > To: graal-dev at openjdk.java.net > Subject: Code must (soon) comply with Eclipse formatting command > > The bugs preventing the Eclipse formatter from being used from the command line seem to have been fixed as of Eclipse 4.3[1]. As such, we will soon add a check in the gate that all incoming code is formatted according to this tool. If you are using Eclipse for development, this should not be a problem. If not, you should run the following before trying to push or submit a webrev: > > $ mx eclipseformat -e /path/to/eclipse4.3installation > > If this command reports that 0 files were modified, your changes should get through (this part of) the gate. > > -Doug > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=405338 > > From volker.simonis at gmail.com Wed Oct 30 02:37:10 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 30 Oct 2013 10:37:10 +0100 Subject: How do I get my PPC64HotSpotBackendFactory registered? In-Reply-To: References: Message-ID: I've done that. I had even deleted the graal.jar file. What finally helped was 'mx clean --no-native' and a rebuild. Thanks everybody, Volker On Tue, Oct 29, 2013 at 8:50 PM, D.Sturm wrote: > I looked into that myself for the Aarch64 port, so I can give some insight: > > Basically it's not enough to just specify the annotationProcessor for your > project. You also have to add the folder that contains your project to the > "distribution at GRAAL@dependencies=\" list in the projects file. There are > already several entries for amd64, etc. there. One important thing to > consider: You have to list the *folder* and not the package name there > (basically give it the path relative from graal/ to the directory containing > the bin folder). mx will then automatically generate the correct META-INF > entries for the annotationProcessors you specify. > > regards, > Daniel. > > > On 29 October 2013 19:57, Volker Simonis wrote: >> >> Hi, >> >> if I pull the additional changes from >> hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot, merge them and add some >> minor changes to the Graal files I can now successfully build the >> Graal VM with the C++ interpreter like so: >> >> CC_INTERP=true ./mx.sh --java-home >> /usr/work/openjdk/output-jdk7u/j2sdk-image --vm graal --vmbuild debug >> build >> >> If I run it I get the following: >> >> ./jdk1.7.0-internal/debug/bin/java -graal -XX:-BootstrapGraal >> -XX:+CIPrintRequests -XX:+PrintCompilation -version >> 1789 1 n >> java.lang.invoke.MethodHandle::linkToStatic(LL)L (native) (static) >> 1905 2 n >> java.lang.invoke.MethodHandle::linkToStatic(LLL)L (native) (static) >> request: java.lang.String::indexOf comment: count count: 470 hot: yes >> 2087 3 n >> java.lang.invoke.MethodHandle::linkToStatic(LL)V (native) (static) >> 2108 4 n >> java.lang.invoke.MethodHandle::linkToStatic(LL)J (native) (static) >> 2138 5 n >> java.lang.invoke.MethodHandle::linkToStatic(LIL)V (native) (static) >> 2175 6 n >> >> com.oracle.graal.hotspot.bridge.CompilerToVMImpl::executeCompiledMethodIntrinsic >> (native) (static) >> request: java.lang.String::hashCode comment: count count: 722 hot: yes >> request: java.lang.String::indexOf comment: count count: 504 hot: yes >> request: java.lang.String::charAt comment: count count: 10000 hot: yes >> request: java.lang.String::hashCode comment: count count: 606 hot: yes >> request: java.lang.String::indexOf comment: count count: 386 hot: yes >> java.lang.ExceptionInInitializerError >> Caused by: java.lang.NullPointerException >> at >> com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime.java:223) >> at >> com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime.java:50) >> >> which is clear because there's no PPC64 support in Graal until now. >> >> I've then added a basic PPC64HotSpotBackendFactory/PPC64HotSpotBackend >> in the same way as this is done for the other architectures and >> recompiled but for some reason, still with the same result (i.e. no >> HotSpotBackendFactory can be found for PPC64). I've then printed the >> available factories in HotSpotGraalRuntime.findFactory (with printf >> debugging) and found that the following factories are available: >> >> ----------AMD64----------- >> ----------PTX----------- >> ----------HSAIL----------- >> >> Notice that SPARC is not listed here as well! I've then added the >> following lines: >> >> # graal.hotspot.ppc64 >> project at com.oracle.graal.hotspot.ppc64@subDir=graal >> project at com.oracle.graal.hotspot.ppc64@sourceDirs=src >> >> project at com.oracle.graal.hotspot.ppc64@dependencies=com.oracle.graal.hotspot,com.oracle.graal.ppc64 >> project at com.oracle.graal.hotspot.ppc64@checkstyle=com.oracle.graal.graph >> >> project at com.oracle.graal.hotspot.ppc64@annotationProcessors=com.oracle.graal.service.processor >> project at com.oracle.graal.hotspot.ppc64@javaCompliance=1.7 >> project at com.oracle.graal.hotspot.ppc64@workingSets=Graal,HotSpot,PPC64 >> >> to mx/projects and expected that the 'annotationProcessors' line will >> do the job - unfortunately without any success. >> >> I've then finally manually added the line: >> >> com.oracle.graal.hotspot.ppc64.PPC64HotSpotBackendFactory >> >> to the file >> META-INF/services/com.oracle.graal.hotspot.HotSpotBackendFactory >> in graal.jar and that finally did the job! I now get the following >> output when running the Graal VM: >> >> ./jdk1.7.0-internal/debug/bin/java -graal -XX:-BootstrapGraal >> -XX:+CIPrintRequests -XX:+PrintCompilation -version >> 3720 1 n >> java.lang.invoke.MethodHandle::linkToStatic(LL)L (native) (static) >> 3921 2 n >> java.lang.invoke.MethodHandle::linkToStatic(LLL)L (native) (static) >> request: java.lang.String::indexOf comment: count count: 470 hot: yes >> 4253 3 n >> java.lang.invoke.MethodHandle::linkToStatic(LL)V (native) (static) >> 4287 4 n >> java.lang.invoke.MethodHandle::linkToStatic(LL)J (native) (static) >> 4340 5 n >> java.lang.invoke.MethodHandle::linkToStatic(LIL)V (native) (static) >> 4406 6 n >> >> com.oracle.graal.hotspot.bridge.CompilerToVMImpl::executeCompiledMethodIntrinsic >> (native) (static) >> request: java.lang.String::hashCode comment: count count: 722 hot: yes >> request: java.lang.String::indexOf comment: count count: 504 hot: yes >> request: java.lang.String::charAt comment: count count: 10000 hot: yes >> request: java.lang.String::hashCode comment: count count: 606 hot: yes >> request: java.lang.String::indexOf comment: count count: 386 hot: yes >> com.oracle.graal.graph.GraalInternalError: unimplemented >> at >> com.oracle.graal.graph.GraalInternalError.unimplemented(GraalInternalError.java:38) >> at >> com.oracle.graal.hotspot.ppc64.PPC64HotSpotCodeCacheProvider.createRegisterConfig(PPC64HotSpotCodeCacheProvider.java:38) >> at >> com.oracle.graal.hotspot.meta.HotSpotCodeCacheProvider.(HotSpotCodeCacheProvider.java:54) >> at >> com.oracle.graal.hotspot.ppc64.PPC64HotSpotCodeCacheProvider.(PPC64HotSpotCodeCacheProvider.java:33) >> at >> com.oracle.graal.hotspot.ppc64.PPC64HotSpotBackendFactory.createBackend(PPC64HotSpotBackendFactory.java:53) >> at >> com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime.java:224) >> at >> com.oracle.graal.hotspot.HotSpotGraalRuntime.(HotSpotGraalRuntime.java:50) >> >> which is OK, because >> PPC64HotSpotCodeCacheProvider.createRegisterConfig() currently throws >> an GraalInternalError. >> >> So now back to my initial question: how do I manage to get my >> PPC64HotSpotBackendFactory registered automatically without the need >> to manually edit the META_INF files? >> >> Thank you and best regards, >> Volker > > From Vasanth.Venkatachalam at amd.com Thu Oct 31 15:24:52 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Thu, 31 Oct 2013 22:24:52 +0000 Subject: webrev for remaining bitwise operators and arithmetic negation Message-ID: <5DD1503F815BD14889DC81D28643E3A7553AB5BE@SATLEXDAG02.amd.com> Hi, I've uploaded a webrev that extends the HSAIL backend to generate code for bitwise right shift (>>), bitwise NOT (~), and arithmetic negation. http://cr.openjdk.java.net/~tdeneau/webrev-bitwiseopsupport-parttwo.01/webrev/ Please review and provide feedback. Summary of main changes. * In HSAILLIRGenerator. Java I extended the implementation of the emitNegate, emitNot and emitShr routines to handle cases that weren't previously being covered. I then made supporting changes to HSAILArithmetic.java and HSAILAssembler.java. * I added unit test cases in compiler/hsail/test for left shift (<<), right shift (>>), unsigned right shift(>>>) and integer negation. * I refactored the emit routines in HSAILAssembler which were calling emitString. We previously had multiple of these routines taking different number of source operands. I was able to coalesce these into a single routine (renamed emitTextFormattedInstruction) taking variable number of source operands. This makes the code more readable but doesn't impact functionality. * A stylistic change. I rearranged the opcode values in the HSAILArithmetic enum to appear in alphabetical order for easier readability. * I've run this code through the eclipse 4.3 formatter and didn't see any changes in files that are part of this webrev. I've also tested the webrev against the latest OpenJDK version of the trunk. Vasanth From christian.thalinger at oracle.com Thu Oct 31 16:15:52 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 31 Oct 2013 16:15:52 -0700 Subject: webrev for remaining bitwise operators and arithmetic negation In-Reply-To: <5DD1503F815BD14889DC81D28643E3A7553AB5BE@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A7553AB5BE@SATLEXDAG02.amd.com> Message-ID: graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILArithmetic.java: I don?t think you need the comments explaining what instruction you emit, like: case LSHL: + /** + * Emit the HSAIL instruction for a left shift. + */ masm.emit("shl", dst, src1, src2); It?s pretty clear from the enum value. Otherwise this looks good. On Oct 31, 2013, at 3:24 PM, Venkatachalam, Vasanth wrote: > Hi, > > I've uploaded a webrev that extends the HSAIL backend to generate code for bitwise right shift (>>), bitwise NOT (~), and arithmetic negation. > > http://cr.openjdk.java.net/~tdeneau/webrev-bitwiseopsupport-parttwo.01/webrev/ > > Please review and provide feedback. > > Summary of main changes. > > > * In HSAILLIRGenerator. Java I extended the implementation of the emitNegate, emitNot and emitShr routines to handle cases that weren't previously being covered. I then made supporting changes to HSAILArithmetic.java and HSAILAssembler.java. > > * I added unit test cases in compiler/hsail/test for left shift (<<), right shift (>>), unsigned right shift(>>>) and integer negation. > > * I refactored the emit routines in HSAILAssembler which were calling emitString. We previously had multiple of these routines taking different number of source operands. I was able to coalesce these into a single routine (renamed emitTextFormattedInstruction) taking variable number of source operands. This makes the code more readable but doesn't impact functionality. > > * A stylistic change. I rearranged the opcode values in the HSAILArithmetic enum to appear in alphabetical order for easier readability. > > * I've run this code through the eclipse 4.3 formatter and didn't see any changes in files that are part of this webrev. I've also tested the webrev against the latest OpenJDK version of the trunk. > > Vasanth