From duboscq at ssw.jku.at Mon Mar 3 03:12:56 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Mon, 3 Mar 2014 12:12:56 +0100 Subject: javaCalls::call and pending_exception In-Reply-To: References: Message-ID: Everything should be in the openjdk graal repository. -Gilles On Thu, Feb 27, 2014 at 5:59 PM, Tom Deneau wrote: > Gilles -- > > That's good news. Are those HSAIL-independent changes in the trunk now, > or on some private branch of yours waiting to get into trunk? > I confess I have not been following closely the trunk changesets lately. > > If your HSAIL-independent changes are not in trunk yet, are your changes > something you can send to me and I can then merge our latest HSAIL-specific changes > with that and send as a webrev from that base? > > Otherwise I'm not clear about the contents of the webrev you are asking > for below. > > -- Tom > > >> -----Original Message----- >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of >> Gilles Duboscq >> Sent: Thursday, February 27, 2014 9:46 AM >> To: Deneau, Tom >> Subject: Re: javaCalls::call and pending_exception >> >> Hello Tom, >> >> I think i have most of the HSAIL independent changes that i want in. >> I still would like to remove ExternalCompilationResult and the fact that >> HSAIL and PTX rely on installing an nmethod to execute their kernels (we >> would still use a nmethod for deopts but only for this purpose, not for >> referencing the kernels). >> But i would probably rather do those changes while integrating your >> changes. >> >> Maybe you can send me a webrev of the things you want to push and I can >> work with that. >> >> -Gilles >> >> On Mon, Feb 24, 2014 at 2:16 PM, Deneau, Tom wrote: >> > Gilles -- >> > >> > Status update: >> > >> > * I put in the DeoptAction=Action_none workaround mentioned below >> and >> > confirmed that multiple depots from one kernel call all happen >> correctly. >> > >> > * In addition to the workitems that deopt, we can have workitems >> that did >> > not run at all (we need this to limit the amount of space we >> would need >> > to allocate for saving deopt information). I have been making >> changes >> > to the logic which saves the never-ran information and determines >> which >> > workitems did not run, but it is looking better now. >> > >> > * We would like to push a webrev that adds the above level of >> functionality, >> > incorporating your hsail-independent infrastructure changes and >> our hsail-specific changes. >> > (I've started calling your alternative compilation the >> "trampoline deopt" code). >> > How should we go about this? I'm assuming you would like to >> check your infrastructure >> > changes in first. >> > >> > -- Tom >> > >> >> -----Original Message----- >> >> From: Gilles Duboscq [mailto:gilwooden at gmail.com] >> >> Sent: Monday, February 24, 2014 4:40 AM >> >> To: Deneau, Tom >> >> Cc: graal-dev at openjdk.java.net >> >> Subject: Re: javaCalls::call and pending_exception >> >> >> >> Yes, that should work. >> >> >> >> On Tue, Feb 18, 2014 at 6:54 AM, Tom Deneau >> wrote: >> >> > Gilles -- >> >> > >> >> > Interesting, yes I do see the alternative method being made non- >> >> reentrant after the first call. >> >> > So until this gets corrected, would a workaround be for the hsail >> >> > side to always just use DeoptAction = Action_none? // just >> >> > interpret, do not invalidate nmethod >> >> > >> >> > -- Tom >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf >> >> >> Of Gilles Duboscq >> >> >> Sent: Friday, February 14, 2014 9:13 AM >> >> >> To: Deneau, Tom >> >> >> Cc: graal-dev at openjdk.java.net >> >> >> Subject: Re: javaCalls::call and pending_exception >> >> >> >> >> >> Hello Tom, >> >> >> >> >> >> One thing i did not do in the webrev I sent you is correctly >> >> >> handle the code invalidation and I think this is what you are >> hitting now: >> >> >> - Any action that would invalidate the code needs to be re-written >> >> >> on one that does not invalidate the code and the code then needs >> >> >> to be invalidated once all workitems have been processed. >> >> >> - The nmethod should never but made non-entrant externally while >> >> >> the kernel is running (maybe this one can be worked around just by >> >> >> having an offset on the entrypoint) >> >> >> - The nmethod sweeper should see that this nmethod is "on the >> stack" >> >> >> when a thread is executing the corresponding kernel. >> >> >> >> >> >> I think you are seeing the 1st problem. After the first >> >> >> invalidating deopt, the entry point will be patched and then the >> >> >> next call will land in the handle_wrong_method_stub but the >> >> >> arguments and probably land in the interpreter but with completely >> unexpected arguments. >> >> >> >> >> >> -Gilles >> >> >> >> >> >> On Fri, Feb 14, 2014 at 4:56 AM, Tom Deneau >> >> wrote: >> >> >> > Gilles -- >> >> >> > >> >> >> > Question about the special javaCalls::call we are using to help >> >> >> > with >> >> >> deoptimization. >> >> >> > We are trying to test a case where more than one workitem will >> >> deopt. >> >> >> > >> >> >> > I have a test case which basically looks like >> >> >> > >> >> >> > try { >> >> >> > int index = (gid % N == 0 ? num+1 : gid); // num + >> >> >> > 1 >> >> >> forces an arrayOutOfBounds deopt >> >> >> > outArray[index] = outval; >> >> >> > } catch (ArrayIndexOutOfBoundsException e) { >> >> >> > // do some activities in catch block >> >> >> > } >> >> >> > >> >> >> > So every Nth workitem will deopt. And we catch the exceptions >> >> >> > in the >> >> >> same method. >> >> >> > >> >> >> > When we run our range of workitems, we end up with several >> >> >> > deopting >> >> >> and several others that are unable to run because the deopt save >> >> >> slots have been used up. >> >> >> > >> >> >> > On return from the kernel dispatch, we are trying to do the >> >> >> > following to handle the workitems that were unable to run: >> >> >> > >> >> >> > a) for the ones that deopted, use the javaCalls::call to call >> >> >> > the >> >> >> special alternative >> >> >> > method to help with the deopt. >> >> >> > >> >> >> > b) for the ones that didn't run at all use a normal >> >> >> javaCalls:call_virtual to >> >> >> > start at the beginning of the method like this >> >> >> > >> >> >> > JavaCalls::call_virtual(&result, methKlass, mh->name(), >> >> >> > mh->signature(), &javaArgs, THREAD); >> >> >> > >> >> >> > >> >> >> > As we process these workitems that didn't finish running on the >> >> >> > gpu, we see that all of the workitems in case a and some of the >> >> >> > workitems in case b will generate an >> >> >> > ArrayIndexOutOfBoundsException which should >> >> >> get immediately caught. >> >> >> > >> >> >> > For the javacalls of type b) above, we can see that all the >> >> >> > workitems that generate an ArrayIndexOutOfBoundsException did >> >> >> > indeed execute the >> >> >> catch block. >> >> >> > >> >> >> > However, for the special javacalls of type a) above, only the >> >> >> > first such workitem executes the catch block. After the second >> >> >> > deopting workitem executes, we see the thread- >> >_pending_exception is set. >> >> >> > >> >> >> > It seems like the type b) behavior is more correct since the >> >> >> > exceptions are not really pending but are being handled in the >> >> >> > catch block. Why would the two javaCalls cases behave >> differently? >> >> >> > >> >> >> > -- Tom >> >> >> > >> >> > >> > > From tom.deneau at amd.com Mon Mar 3 06:16:00 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 3 Mar 2014 14:16:00 +0000 Subject: javaCalls::call and pending_exception In-Reply-To: References: Message-ID: Gilles -- OK, great. I wasn't aware of that. I will put together a webrev of our latest hsail deoptimization code which will be using your infrastructure then. We have been working here on a branch starting with the patch you sent us at the beginning of February. Most of this work has been handling test cases that contain more than one deopting workitem as well as figuring out which workitems never ran at all and running them, etc. I have been occasionally merging the latest trunk into that branch. When I today diff that branch against trunk, I do see some diffs on files that are not HSAIL-specific, but I will attempt in such cases to just revert that file to trunk and will let you know if there are any problems. If there are any changes I should know about in the interface to the trampoline generating code, let me know. -- Tom > -----Original Message----- > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > Gilles Duboscq > Sent: Monday, March 03, 2014 5:13 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: javaCalls::call and pending_exception > > Everything should be in the openjdk graal repository. > > -Gilles > > On Thu, Feb 27, 2014 at 5:59 PM, Tom Deneau wrote: > > Gilles -- > > > > That's good news. Are those HSAIL-independent changes in the trunk > now, > > or on some private branch of yours waiting to get into trunk? > > I confess I have not been following closely the trunk changesets > lately. > > > > If your HSAIL-independent changes are not in trunk yet, are your > changes > > something you can send to me and I can then merge our latest HSAIL- > specific changes > > with that and send as a webrev from that base? > > > > Otherwise I'm not clear about the contents of the webrev you are > asking > > for below. > > > > -- Tom > > > > > >> -----Original Message----- > >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > >> Gilles Duboscq > >> Sent: Thursday, February 27, 2014 9:46 AM > >> To: Deneau, Tom > >> Subject: Re: javaCalls::call and pending_exception > >> > >> Hello Tom, > >> > >> I think i have most of the HSAIL independent changes that i want in. > >> I still would like to remove ExternalCompilationResult and the fact > that > >> HSAIL and PTX rely on installing an nmethod to execute their kernels > (we > >> would still use a nmethod for deopts but only for this purpose, not > for > >> referencing the kernels). > >> But i would probably rather do those changes while integrating your > >> changes. > >> > >> Maybe you can send me a webrev of the things you want to push and I > can > >> work with that. > >> > >> -Gilles > >> > >> On Mon, Feb 24, 2014 at 2:16 PM, Deneau, Tom > wrote: > >> > Gilles -- > >> > > >> > Status update: > >> > > >> > * I put in the DeoptAction=Action_none workaround mentioned > below > >> and > >> > confirmed that multiple depots from one kernel call all happen > >> correctly. > >> > > >> > * In addition to the workitems that deopt, we can have workitems > >> that did > >> > not run at all (we need this to limit the amount of space we > >> would need > >> > to allocate for saving deopt information). I have been making > >> changes > >> > to the logic which saves the never-ran information and > determines > >> which > >> > workitems did not run, but it is looking better now. > >> > > >> > * We would like to push a webrev that adds the above level of > >> functionality, > >> > incorporating your hsail-independent infrastructure changes > and > >> our hsail-specific changes. > >> > (I've started calling your alternative compilation the > >> "trampoline deopt" code). > >> > How should we go about this? I'm assuming you would like to > >> check your infrastructure > >> > changes in first. > >> > > >> > -- Tom > >> > > >> >> -----Original Message----- > >> >> From: Gilles Duboscq [mailto:gilwooden at gmail.com] > >> >> Sent: Monday, February 24, 2014 4:40 AM > >> >> To: Deneau, Tom > >> >> Cc: graal-dev at openjdk.java.net > >> >> Subject: Re: javaCalls::call and pending_exception > >> >> > >> >> Yes, that should work. > >> >> > >> >> On Tue, Feb 18, 2014 at 6:54 AM, Tom Deneau > >> wrote: > >> >> > Gilles -- > >> >> > > >> >> > Interesting, yes I do see the alternative method being made non- > >> >> reentrant after the first call. > >> >> > So until this gets corrected, would a workaround be for the > hsail > >> >> > side to always just use DeoptAction = Action_none? // just > >> >> > interpret, do not invalidate nmethod > >> >> > > >> >> > -- Tom > >> >> > > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On > Behalf > >> >> >> Of Gilles Duboscq > >> >> >> Sent: Friday, February 14, 2014 9:13 AM > >> >> >> To: Deneau, Tom > >> >> >> Cc: graal-dev at openjdk.java.net > >> >> >> Subject: Re: javaCalls::call and pending_exception > >> >> >> > >> >> >> Hello Tom, > >> >> >> > >> >> >> One thing i did not do in the webrev I sent you is correctly > >> >> >> handle the code invalidation and I think this is what you are > >> hitting now: > >> >> >> - Any action that would invalidate the code needs to be re- > written > >> >> >> on one that does not invalidate the code and the code then > needs > >> >> >> to be invalidated once all workitems have been processed. > >> >> >> - The nmethod should never but made non-entrant externally > while > >> >> >> the kernel is running (maybe this one can be worked around just > by > >> >> >> having an offset on the entrypoint) > >> >> >> - The nmethod sweeper should see that this nmethod is "on the > >> stack" > >> >> >> when a thread is executing the corresponding kernel. > >> >> >> > >> >> >> I think you are seeing the 1st problem. After the first > >> >> >> invalidating deopt, the entry point will be patched and then > the > >> >> >> next call will land in the handle_wrong_method_stub but the > >> >> >> arguments and probably land in the interpreter but with > completely > >> unexpected arguments. > >> >> >> > >> >> >> -Gilles > >> >> >> > >> >> >> On Fri, Feb 14, 2014 at 4:56 AM, Tom Deneau > > >> >> wrote: > >> >> >> > Gilles -- > >> >> >> > > >> >> >> > Question about the special javaCalls::call we are using to > help > >> >> >> > with > >> >> >> deoptimization. > >> >> >> > We are trying to test a case where more than one workitem > will > >> >> deopt. > >> >> >> > > >> >> >> > I have a test case which basically looks like > >> >> >> > > >> >> >> > try { > >> >> >> > int index = (gid % N == 0 ? num+1 : gid); // num > + > >> >> >> > 1 > >> >> >> forces an arrayOutOfBounds deopt > >> >> >> > outArray[index] = outval; > >> >> >> > } catch (ArrayIndexOutOfBoundsException e) { > >> >> >> > // do some activities in catch block > >> >> >> > } > >> >> >> > > >> >> >> > So every Nth workitem will deopt. And we catch the > exceptions > >> >> >> > in the > >> >> >> same method. > >> >> >> > > >> >> >> > When we run our range of workitems, we end up with several > >> >> >> > deopting > >> >> >> and several others that are unable to run because the deopt > save > >> >> >> slots have been used up. > >> >> >> > > >> >> >> > On return from the kernel dispatch, we are trying to do the > >> >> >> > following to handle the workitems that were unable to run: > >> >> >> > > >> >> >> > a) for the ones that deopted, use the javaCalls::call to > call > >> >> >> > the > >> >> >> special alternative > >> >> >> > method to help with the deopt. > >> >> >> > > >> >> >> > b) for the ones that didn't run at all use a normal > >> >> >> javaCalls:call_virtual to > >> >> >> > start at the beginning of the method like this > >> >> >> > > >> >> >> > JavaCalls::call_virtual(&result, methKlass, mh->name(), > >> >> >> > mh->signature(), &javaArgs, THREAD); > >> >> >> > > >> >> >> > > >> >> >> > As we process these workitems that didn't finish running on > the > >> >> >> > gpu, we see that all of the workitems in case a and some of > the > >> >> >> > workitems in case b will generate an > >> >> >> > ArrayIndexOutOfBoundsException which should > >> >> >> get immediately caught. > >> >> >> > > >> >> >> > For the javacalls of type b) above, we can see that all the > >> >> >> > workitems that generate an ArrayIndexOutOfBoundsException did > >> >> >> > indeed execute the > >> >> >> catch block. > >> >> >> > > >> >> >> > However, for the special javacalls of type a) above, only the > >> >> >> > first such workitem executes the catch block. After the > second > >> >> >> > deopting workitem executes, we see the thread- > >> >_pending_exception is set. > >> >> >> > > >> >> >> > It seems like the type b) behavior is more correct since the > >> >> >> > exceptions are not really pending but are being handled in > the > >> >> >> > catch block. Why would the two javaCalls cases behave > >> differently? > >> >> >> > > >> >> >> > -- Tom > >> >> >> > > >> >> > > >> > > > From tom.deneau at amd.com Mon Mar 3 13:20:38 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 3 Mar 2014 21:20:38 +0000 Subject: javaCalls::call and pending_exception In-Reply-To: References: Message-ID: Gilles -- Just clarifying the use of ExternalCompilationResult.java In the original patch you gave me at the beginning of February it had moved into com.oracle.graal.gpu. In the current trunk it is in its original com.oracle.graal.api.code, but in that location it does not have the setHostGraph, getHostGraph, etc. Since I recall you saying you want to get rid of it eventually, I plan to leave it in com.oracle.graal.api.code and just add the setHostGraph, getHostGraph methods there. -- Tom > -----Original Message----- > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > Gilles Duboscq > Sent: Monday, March 03, 2014 5:13 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: javaCalls::call and pending_exception > > Everything should be in the openjdk graal repository. > > -Gilles > > On Thu, Feb 27, 2014 at 5:59 PM, Tom Deneau wrote: > > Gilles -- > > > > That's good news. Are those HSAIL-independent changes in the trunk > now, > > or on some private branch of yours waiting to get into trunk? > > I confess I have not been following closely the trunk changesets > lately. > > > > If your HSAIL-independent changes are not in trunk yet, are your > changes > > something you can send to me and I can then merge our latest HSAIL- > specific changes > > with that and send as a webrev from that base? > > > > Otherwise I'm not clear about the contents of the webrev you are > asking > > for below. > > > > -- Tom > > > > > >> -----Original Message----- > >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > >> Gilles Duboscq > >> Sent: Thursday, February 27, 2014 9:46 AM > >> To: Deneau, Tom > >> Subject: Re: javaCalls::call and pending_exception > >> > >> Hello Tom, > >> > >> I think i have most of the HSAIL independent changes that i want in. > >> I still would like to remove ExternalCompilationResult and the fact > that > >> HSAIL and PTX rely on installing an nmethod to execute their kernels > (we > >> would still use a nmethod for deopts but only for this purpose, not > for > >> referencing the kernels). > >> But i would probably rather do those changes while integrating your > >> changes. > >> > >> Maybe you can send me a webrev of the things you want to push and I > can > >> work with that. > >> > >> -Gilles > >> > >> On Mon, Feb 24, 2014 at 2:16 PM, Deneau, Tom > wrote: > >> > Gilles -- > >> > > >> > Status update: > >> > > >> > * I put in the DeoptAction=Action_none workaround mentioned > below > >> and > >> > confirmed that multiple depots from one kernel call all happen > >> correctly. > >> > > >> > * In addition to the workitems that deopt, we can have workitems > >> that did > >> > not run at all (we need this to limit the amount of space we > >> would need > >> > to allocate for saving deopt information). I have been making > >> changes > >> > to the logic which saves the never-ran information and > determines > >> which > >> > workitems did not run, but it is looking better now. > >> > > >> > * We would like to push a webrev that adds the above level of > >> functionality, > >> > incorporating your hsail-independent infrastructure changes > and > >> our hsail-specific changes. > >> > (I've started calling your alternative compilation the > >> "trampoline deopt" code). > >> > How should we go about this? I'm assuming you would like to > >> check your infrastructure > >> > changes in first. > >> > > >> > -- Tom > >> > > >> >> -----Original Message----- > >> >> From: Gilles Duboscq [mailto:gilwooden at gmail.com] > >> >> Sent: Monday, February 24, 2014 4:40 AM > >> >> To: Deneau, Tom > >> >> Cc: graal-dev at openjdk.java.net > >> >> Subject: Re: javaCalls::call and pending_exception > >> >> > >> >> Yes, that should work. > >> >> > >> >> On Tue, Feb 18, 2014 at 6:54 AM, Tom Deneau > >> wrote: > >> >> > Gilles -- > >> >> > > >> >> > Interesting, yes I do see the alternative method being made non- > >> >> reentrant after the first call. > >> >> > So until this gets corrected, would a workaround be for the > hsail > >> >> > side to always just use DeoptAction = Action_none? // just > >> >> > interpret, do not invalidate nmethod > >> >> > > >> >> > -- Tom > >> >> > > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On > Behalf > >> >> >> Of Gilles Duboscq > >> >> >> Sent: Friday, February 14, 2014 9:13 AM > >> >> >> To: Deneau, Tom > >> >> >> Cc: graal-dev at openjdk.java.net > >> >> >> Subject: Re: javaCalls::call and pending_exception > >> >> >> > >> >> >> Hello Tom, > >> >> >> > >> >> >> One thing i did not do in the webrev I sent you is correctly > >> >> >> handle the code invalidation and I think this is what you are > >> hitting now: > >> >> >> - Any action that would invalidate the code needs to be re- > written > >> >> >> on one that does not invalidate the code and the code then > needs > >> >> >> to be invalidated once all workitems have been processed. > >> >> >> - The nmethod should never but made non-entrant externally > while > >> >> >> the kernel is running (maybe this one can be worked around just > by > >> >> >> having an offset on the entrypoint) > >> >> >> - The nmethod sweeper should see that this nmethod is "on the > >> stack" > >> >> >> when a thread is executing the corresponding kernel. > >> >> >> > >> >> >> I think you are seeing the 1st problem. After the first > >> >> >> invalidating deopt, the entry point will be patched and then > the > >> >> >> next call will land in the handle_wrong_method_stub but the > >> >> >> arguments and probably land in the interpreter but with > completely > >> unexpected arguments. > >> >> >> > >> >> >> -Gilles > >> >> >> > >> >> >> On Fri, Feb 14, 2014 at 4:56 AM, Tom Deneau > > >> >> wrote: > >> >> >> > Gilles -- > >> >> >> > > >> >> >> > Question about the special javaCalls::call we are using to > help > >> >> >> > with > >> >> >> deoptimization. > >> >> >> > We are trying to test a case where more than one workitem > will > >> >> deopt. > >> >> >> > > >> >> >> > I have a test case which basically looks like > >> >> >> > > >> >> >> > try { > >> >> >> > int index = (gid % N == 0 ? num+1 : gid); // num > + > >> >> >> > 1 > >> >> >> forces an arrayOutOfBounds deopt > >> >> >> > outArray[index] = outval; > >> >> >> > } catch (ArrayIndexOutOfBoundsException e) { > >> >> >> > // do some activities in catch block > >> >> >> > } > >> >> >> > > >> >> >> > So every Nth workitem will deopt. And we catch the > exceptions > >> >> >> > in the > >> >> >> same method. > >> >> >> > > >> >> >> > When we run our range of workitems, we end up with several > >> >> >> > deopting > >> >> >> and several others that are unable to run because the deopt > save > >> >> >> slots have been used up. > >> >> >> > > >> >> >> > On return from the kernel dispatch, we are trying to do the > >> >> >> > following to handle the workitems that were unable to run: > >> >> >> > > >> >> >> > a) for the ones that deopted, use the javaCalls::call to > call > >> >> >> > the > >> >> >> special alternative > >> >> >> > method to help with the deopt. > >> >> >> > > >> >> >> > b) for the ones that didn't run at all use a normal > >> >> >> javaCalls:call_virtual to > >> >> >> > start at the beginning of the method like this > >> >> >> > > >> >> >> > JavaCalls::call_virtual(&result, methKlass, mh->name(), > >> >> >> > mh->signature(), &javaArgs, THREAD); > >> >> >> > > >> >> >> > > >> >> >> > As we process these workitems that didn't finish running on > the > >> >> >> > gpu, we see that all of the workitems in case a and some of > the > >> >> >> > workitems in case b will generate an > >> >> >> > ArrayIndexOutOfBoundsException which should > >> >> >> get immediately caught. > >> >> >> > > >> >> >> > For the javacalls of type b) above, we can see that all the > >> >> >> > workitems that generate an ArrayIndexOutOfBoundsException did > >> >> >> > indeed execute the > >> >> >> catch block. > >> >> >> > > >> >> >> > However, for the special javacalls of type a) above, only the > >> >> >> > first such workitem executes the catch block. After the > second > >> >> >> > deopting workitem executes, we see the thread- > >> >_pending_exception is set. > >> >> >> > > >> >> >> > It seems like the type b) behavior is more correct since the > >> >> >> > exceptions are not really pending but are being handled in > the > >> >> >> > catch block. Why would the two javaCalls cases behave > >> differently? > >> >> >> > > >> >> >> > -- Tom > >> >> >> > > >> >> > > >> > > > From duboscq at ssw.jku.at Mon Mar 3 13:39:15 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Mon, 3 Mar 2014 22:39:15 +0100 Subject: javaCalls::call and pending_exception In-Reply-To: References: Message-ID: Yes that sounds good. On 3 Mar 2014 22:21, "Tom Deneau" wrote: > Gilles -- > > Just clarifying the use of ExternalCompilationResult.java > > In the original patch you gave me at the beginning of February it had > moved into com.oracle.graal.gpu. > In the current trunk it is in its original com.oracle.graal.api.code, but > in that location > it does not have the setHostGraph, getHostGraph, etc. > > Since I recall you saying you want to get rid of it eventually, I plan to > leave > it in com.oracle.graal.api.code and just add the setHostGraph, > getHostGraph methods there. > > -- Tom > > > > -----Original Message----- > > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > > Gilles Duboscq > > Sent: Monday, March 03, 2014 5:13 AM > > To: Deneau, Tom > > Cc: graal-dev at openjdk.java.net > > Subject: Re: javaCalls::call and pending_exception > > > > Everything should be in the openjdk graal repository. > > > > -Gilles > > > > On Thu, Feb 27, 2014 at 5:59 PM, Tom Deneau wrote: > > > Gilles -- > > > > > > That's good news. Are those HSAIL-independent changes in the trunk > > now, > > > or on some private branch of yours waiting to get into trunk? > > > I confess I have not been following closely the trunk changesets > > lately. > > > > > > If your HSAIL-independent changes are not in trunk yet, are your > > changes > > > something you can send to me and I can then merge our latest HSAIL- > > specific changes > > > with that and send as a webrev from that base? > > > > > > Otherwise I'm not clear about the contents of the webrev you are > > asking > > > for below. > > > > > > -- Tom > > > > > > > > >> -----Original Message----- > > >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > > >> Gilles Duboscq > > >> Sent: Thursday, February 27, 2014 9:46 AM > > >> To: Deneau, Tom > > >> Subject: Re: javaCalls::call and pending_exception > > >> > > >> Hello Tom, > > >> > > >> I think i have most of the HSAIL independent changes that i want in. > > >> I still would like to remove ExternalCompilationResult and the fact > > that > > >> HSAIL and PTX rely on installing an nmethod to execute their kernels > > (we > > >> would still use a nmethod for deopts but only for this purpose, not > > for > > >> referencing the kernels). > > >> But i would probably rather do those changes while integrating your > > >> changes. > > >> > > >> Maybe you can send me a webrev of the things you want to push and I > > can > > >> work with that. > > >> > > >> -Gilles > > >> > > >> On Mon, Feb 24, 2014 at 2:16 PM, Deneau, Tom > > wrote: > > >> > Gilles -- > > >> > > > >> > Status update: > > >> > > > >> > * I put in the DeoptAction=Action_none workaround mentioned > > below > > >> and > > >> > confirmed that multiple depots from one kernel call all happen > > >> correctly. > > >> > > > >> > * In addition to the workitems that deopt, we can have workitems > > >> that did > > >> > not run at all (we need this to limit the amount of space we > > >> would need > > >> > to allocate for saving deopt information). I have been making > > >> changes > > >> > to the logic which saves the never-ran information and > > determines > > >> which > > >> > workitems did not run, but it is looking better now. > > >> > > > >> > * We would like to push a webrev that adds the above level of > > >> functionality, > > >> > incorporating your hsail-independent infrastructure changes > > and > > >> our hsail-specific changes. > > >> > (I've started calling your alternative compilation the > > >> "trampoline deopt" code). > > >> > How should we go about this? I'm assuming you would like to > > >> check your infrastructure > > >> > changes in first. > > >> > > > >> > -- Tom > > >> > > > >> >> -----Original Message----- > > >> >> From: Gilles Duboscq [mailto:gilwooden at gmail.com] > > >> >> Sent: Monday, February 24, 2014 4:40 AM > > >> >> To: Deneau, Tom > > >> >> Cc: graal-dev at openjdk.java.net > > >> >> Subject: Re: javaCalls::call and pending_exception > > >> >> > > >> >> Yes, that should work. > > >> >> > > >> >> On Tue, Feb 18, 2014 at 6:54 AM, Tom Deneau > > >> wrote: > > >> >> > Gilles -- > > >> >> > > > >> >> > Interesting, yes I do see the alternative method being made non- > > >> >> reentrant after the first call. > > >> >> > So until this gets corrected, would a workaround be for the > > hsail > > >> >> > side to always just use DeoptAction = Action_none? // just > > >> >> > interpret, do not invalidate nmethod > > >> >> > > > >> >> > -- Tom > > >> >> > > > >> >> > > > >> >> >> -----Original Message----- > > >> >> >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On > > Behalf > > >> >> >> Of Gilles Duboscq > > >> >> >> Sent: Friday, February 14, 2014 9:13 AM > > >> >> >> To: Deneau, Tom > > >> >> >> Cc: graal-dev at openjdk.java.net > > >> >> >> Subject: Re: javaCalls::call and pending_exception > > >> >> >> > > >> >> >> Hello Tom, > > >> >> >> > > >> >> >> One thing i did not do in the webrev I sent you is correctly > > >> >> >> handle the code invalidation and I think this is what you are > > >> hitting now: > > >> >> >> - Any action that would invalidate the code needs to be re- > > written > > >> >> >> on one that does not invalidate the code and the code then > > needs > > >> >> >> to be invalidated once all workitems have been processed. > > >> >> >> - The nmethod should never but made non-entrant externally > > while > > >> >> >> the kernel is running (maybe this one can be worked around just > > by > > >> >> >> having an offset on the entrypoint) > > >> >> >> - The nmethod sweeper should see that this nmethod is "on the > > >> stack" > > >> >> >> when a thread is executing the corresponding kernel. > > >> >> >> > > >> >> >> I think you are seeing the 1st problem. After the first > > >> >> >> invalidating deopt, the entry point will be patched and then > > the > > >> >> >> next call will land in the handle_wrong_method_stub but the > > >> >> >> arguments and probably land in the interpreter but with > > completely > > >> unexpected arguments. > > >> >> >> > > >> >> >> -Gilles > > >> >> >> > > >> >> >> On Fri, Feb 14, 2014 at 4:56 AM, Tom Deneau > > > > >> >> wrote: > > >> >> >> > Gilles -- > > >> >> >> > > > >> >> >> > Question about the special javaCalls::call we are using to > > help > > >> >> >> > with > > >> >> >> deoptimization. > > >> >> >> > We are trying to test a case where more than one workitem > > will > > >> >> deopt. > > >> >> >> > > > >> >> >> > I have a test case which basically looks like > > >> >> >> > > > >> >> >> > try { > > >> >> >> > int index = (gid % N == 0 ? num+1 : gid); // num > > + > > >> >> >> > 1 > > >> >> >> forces an arrayOutOfBounds deopt > > >> >> >> > outArray[index] = outval; > > >> >> >> > } catch (ArrayIndexOutOfBoundsException e) { > > >> >> >> > // do some activities in catch block > > >> >> >> > } > > >> >> >> > > > >> >> >> > So every Nth workitem will deopt. And we catch the > > exceptions > > >> >> >> > in the > > >> >> >> same method. > > >> >> >> > > > >> >> >> > When we run our range of workitems, we end up with several > > >> >> >> > deopting > > >> >> >> and several others that are unable to run because the deopt > > save > > >> >> >> slots have been used up. > > >> >> >> > > > >> >> >> > On return from the kernel dispatch, we are trying to do the > > >> >> >> > following to handle the workitems that were unable to run: > > >> >> >> > > > >> >> >> > a) for the ones that deopted, use the javaCalls::call to > > call > > >> >> >> > the > > >> >> >> special alternative > > >> >> >> > method to help with the deopt. > > >> >> >> > > > >> >> >> > b) for the ones that didn't run at all use a normal > > >> >> >> javaCalls:call_virtual to > > >> >> >> > start at the beginning of the method like this > > >> >> >> > > > >> >> >> > JavaCalls::call_virtual(&result, methKlass, mh->name(), > > >> >> >> > mh->signature(), &javaArgs, THREAD); > > >> >> >> > > > >> >> >> > > > >> >> >> > As we process these workitems that didn't finish running on > > the > > >> >> >> > gpu, we see that all of the workitems in case a and some of > > the > > >> >> >> > workitems in case b will generate an > > >> >> >> > ArrayIndexOutOfBoundsException which should > > >> >> >> get immediately caught. > > >> >> >> > > > >> >> >> > For the javacalls of type b) above, we can see that all the > > >> >> >> > workitems that generate an ArrayIndexOutOfBoundsException did > > >> >> >> > indeed execute the > > >> >> >> catch block. > > >> >> >> > > > >> >> >> > However, for the special javacalls of type a) above, only the > > >> >> >> > first such workitem executes the catch block. After the > > second > > >> >> >> > deopting workitem executes, we see the thread- > > >> >_pending_exception is set. > > >> >> >> > > > >> >> >> > It seems like the type b) behavior is more correct since the > > >> >> >> > exceptions are not really pending but are being handled in > > the > > >> >> >> > catch block. Why would the two javaCalls cases behave > > >> differently? > > >> >> >> > > > >> >> >> > -- Tom > > >> >> >> > > > >> >> > > > >> > > > > > > From tom.deneau at amd.com Mon Mar 3 13:46:32 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 3 Mar 2014 21:46:32 +0000 Subject: javaCalls::call and pending_exception In-Reply-To: References: Message-ID: Actually I noticed when I put it back in com.oracle.graal.api.code and added a dependency in mx/projects on com.oracle.graal.nodes, there was then a cycle in the dependencies. So I put it back in com.oracle.graal.gpu for now. -- Tom From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Monday, March 03, 2014 3:39 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: RE: javaCalls::call and pending_exception Yes that sounds good. On 3 Mar 2014 22:21, "Tom Deneau" > wrote: Gilles -- Just clarifying the use of ExternalCompilationResult.java In the original patch you gave me at the beginning of February it had moved into com.oracle.graal.gpu. In the current trunk it is in its original com.oracle.graal.api.code, but in that location it does not have the setHostGraph, getHostGraph, etc. Since I recall you saying you want to get rid of it eventually, I plan to leave it in com.oracle.graal.api.code and just add the setHostGraph, getHostGraph methods there. -- Tom > -----Original Message----- > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > Gilles Duboscq > Sent: Monday, March 03, 2014 5:13 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: javaCalls::call and pending_exception > > Everything should be in the openjdk graal repository. > > -Gilles > > On Thu, Feb 27, 2014 at 5:59 PM, Tom Deneau > wrote: > > Gilles -- > > > > That's good news. Are those HSAIL-independent changes in the trunk > now, > > or on some private branch of yours waiting to get into trunk? > > I confess I have not been following closely the trunk changesets > lately. > > > > If your HSAIL-independent changes are not in trunk yet, are your > changes > > something you can send to me and I can then merge our latest HSAIL- > specific changes > > with that and send as a webrev from that base? > > > > Otherwise I'm not clear about the contents of the webrev you are > asking > > for below. > > > > -- Tom > > > > > >> -----Original Message----- > >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > >> Gilles Duboscq > >> Sent: Thursday, February 27, 2014 9:46 AM > >> To: Deneau, Tom > >> Subject: Re: javaCalls::call and pending_exception > >> > >> Hello Tom, > >> > >> I think i have most of the HSAIL independent changes that i want in. > >> I still would like to remove ExternalCompilationResult and the fact > that > >> HSAIL and PTX rely on installing an nmethod to execute their kernels > (we > >> would still use a nmethod for deopts but only for this purpose, not > for > >> referencing the kernels). > >> But i would probably rather do those changes while integrating your > >> changes. > >> > >> Maybe you can send me a webrev of the things you want to push and I > can > >> work with that. > >> > >> -Gilles > >> > >> On Mon, Feb 24, 2014 at 2:16 PM, Deneau, Tom > > wrote: > >> > Gilles -- > >> > > >> > Status update: > >> > > >> > * I put in the DeoptAction=Action_none workaround mentioned > below > >> and > >> > confirmed that multiple depots from one kernel call all happen > >> correctly. > >> > > >> > * In addition to the workitems that deopt, we can have workitems > >> that did > >> > not run at all (we need this to limit the amount of space we > >> would need > >> > to allocate for saving deopt information). I have been making > >> changes > >> > to the logic which saves the never-ran information and > determines > >> which > >> > workitems did not run, but it is looking better now. > >> > > >> > * We would like to push a webrev that adds the above level of > >> functionality, > >> > incorporating your hsail-independent infrastructure changes > and > >> our hsail-specific changes. > >> > (I've started calling your alternative compilation the > >> "trampoline deopt" code). > >> > How should we go about this? I'm assuming you would like to > >> check your infrastructure > >> > changes in first. > >> > > >> > -- Tom > >> > > >> >> -----Original Message----- > >> >> From: Gilles Duboscq [mailto:gilwooden at gmail.com] > >> >> Sent: Monday, February 24, 2014 4:40 AM > >> >> To: Deneau, Tom > >> >> Cc: graal-dev at openjdk.java.net > >> >> Subject: Re: javaCalls::call and pending_exception > >> >> > >> >> Yes, that should work. > >> >> > >> >> On Tue, Feb 18, 2014 at 6:54 AM, Tom Deneau > > >> wrote: > >> >> > Gilles -- > >> >> > > >> >> > Interesting, yes I do see the alternative method being made non- > >> >> reentrant after the first call. > >> >> > So until this gets corrected, would a workaround be for the > hsail > >> >> > side to always just use DeoptAction = Action_none? // just > >> >> > interpret, do not invalidate nmethod > >> >> > > >> >> > -- Tom > >> >> > > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On > Behalf > >> >> >> Of Gilles Duboscq > >> >> >> Sent: Friday, February 14, 2014 9:13 AM > >> >> >> To: Deneau, Tom > >> >> >> Cc: graal-dev at openjdk.java.net > >> >> >> Subject: Re: javaCalls::call and pending_exception > >> >> >> > >> >> >> Hello Tom, > >> >> >> > >> >> >> One thing i did not do in the webrev I sent you is correctly > >> >> >> handle the code invalidation and I think this is what you are > >> hitting now: > >> >> >> - Any action that would invalidate the code needs to be re- > written > >> >> >> on one that does not invalidate the code and the code then > needs > >> >> >> to be invalidated once all workitems have been processed. > >> >> >> - The nmethod should never but made non-entrant externally > while > >> >> >> the kernel is running (maybe this one can be worked around just > by > >> >> >> having an offset on the entrypoint) > >> >> >> - The nmethod sweeper should see that this nmethod is "on the > >> stack" > >> >> >> when a thread is executing the corresponding kernel. > >> >> >> > >> >> >> I think you are seeing the 1st problem. After the first > >> >> >> invalidating deopt, the entry point will be patched and then > the > >> >> >> next call will land in the handle_wrong_method_stub but the > >> >> >> arguments and probably land in the interpreter but with > completely > >> unexpected arguments. > >> >> >> > >> >> >> -Gilles > >> >> >> > >> >> >> On Fri, Feb 14, 2014 at 4:56 AM, Tom Deneau > > > >> >> wrote: > >> >> >> > Gilles -- > >> >> >> > > >> >> >> > Question about the special javaCalls::call we are using to > help > >> >> >> > with > >> >> >> deoptimization. > >> >> >> > We are trying to test a case where more than one workitem > will > >> >> deopt. > >> >> >> > > >> >> >> > I have a test case which basically looks like > >> >> >> > > >> >> >> > try { > >> >> >> > int index = (gid % N == 0 ? num+1 : gid); // num > + > >> >> >> > 1 > >> >> >> forces an arrayOutOfBounds deopt > >> >> >> > outArray[index] = outval; > >> >> >> > } catch (ArrayIndexOutOfBoundsException e) { > >> >> >> > // do some activities in catch block > >> >> >> > } > >> >> >> > > >> >> >> > So every Nth workitem will deopt. And we catch the > exceptions > >> >> >> > in the > >> >> >> same method. > >> >> >> > > >> >> >> > When we run our range of workitems, we end up with several > >> >> >> > deopting > >> >> >> and several others that are unable to run because the deopt > save > >> >> >> slots have been used up. > >> >> >> > > >> >> >> > On return from the kernel dispatch, we are trying to do the > >> >> >> > following to handle the workitems that were unable to run: > >> >> >> > > >> >> >> > a) for the ones that deopted, use the javaCalls::call to > call > >> >> >> > the > >> >> >> special alternative > >> >> >> > method to help with the deopt. > >> >> >> > > >> >> >> > b) for the ones that didn't run at all use a normal > >> >> >> javaCalls:call_virtual to > >> >> >> > start at the beginning of the method like this > >> >> >> > > >> >> >> > JavaCalls::call_virtual(&result, methKlass, mh->name(), > >> >> >> > mh->signature(), &javaArgs, THREAD); > >> >> >> > > >> >> >> > > >> >> >> > As we process these workitems that didn't finish running on > the > >> >> >> > gpu, we see that all of the workitems in case a and some of > the > >> >> >> > workitems in case b will generate an > >> >> >> > ArrayIndexOutOfBoundsException which should > >> >> >> get immediately caught. > >> >> >> > > >> >> >> > For the javacalls of type b) above, we can see that all the > >> >> >> > workitems that generate an ArrayIndexOutOfBoundsException did > >> >> >> > indeed execute the > >> >> >> catch block. > >> >> >> > > >> >> >> > However, for the special javacalls of type a) above, only the > >> >> >> > first such workitem executes the catch block. After the > second > >> >> >> > deopting workitem executes, we see the thread- > >> >_pending_exception is set. > >> >> >> > > >> >> >> > It seems like the type b) behavior is more correct since the > >> >> >> > exceptions are not really pending but are being handled in > the > >> >> >> > catch block. Why would the two javaCalls cases behave > >> differently? > >> >> >> > > >> >> >> > -- Tom > >> >> >> > > >> >> > > >> > > > From eric.caspole at amd.com Mon Mar 3 15:25:46 2014 From: eric.caspole at amd.com (Eric Caspole) Date: Mon, 3 Mar 2014 18:25:46 -0500 Subject: Substitution/Replacements problem Message-ID: <53150F7A.6020103@amd.com> Hi everybody, We have a lot of lambda based tests that are not in the public repo yet, waiting for JDK 8 to come to Graal. In these tests, I found a problem with the way replacements are being done now. See this method: graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReplacementsImpl.java 107 @Override 108 public StructuredGraph getMethodSubstitution(ResolvedJavaMethod original) { 109 for (GraphProducer gp : graphProducers) { 110 StructuredGraph graph = gp.getGraphFor(original); 111 if (graph != null) { 112 return graph; 113 } 114 } 115 return super.getMethodSubstitution(original); 116 } Here it loops over the backends until it gets a hit. In our tests, I found that while we are compiling an HSAIL kernel that is actually a Stream API lambda, when it goes into getIntrinsicGraph(), it will go into getMethodSubstitution() and look for substitutions in the PTX backend, see the "lambda$" method we are compiling and try to produce a PTX kernel of the thing we are in the middle of compiling for HSAIL, which was a shock :) Up til now, we have been using the replacements/inline mechanism for example AtomicInteger that end up as fence/load/fence type ops, and other uses, that get inlined into the kernel body and that is working well so far. I have a suitable PTX card in my box so I might be the only one in the group that might see this problem. The existing HSAIL KernelTester tests in the public repo do not get this problem since the harness sends an ordinary method to get HSAIL-compiled and they are not called "lambda$..." I think I see that the strategy for offloading for PTX so far is doing a "replacement" of a CPU method with a GPU kernel. But we also want to have some replacements/inlining inside the kernel. What is the best way to fix this problem? Thanks, Eric From christian.thalinger at oracle.com Mon Mar 3 16:47:21 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 3 Mar 2014 16:47:21 -0800 Subject: Substitution/Replacements problem In-Reply-To: <53150F7A.6020103@amd.com> References: <53150F7A.6020103@amd.com> Message-ID: On Mar 3, 2014, at 3:25 PM, Eric Caspole wrote: > Hi everybody, > We have a lot of lambda based tests that are not in the public repo yet, waiting for JDK 8 to come to Graal. In these tests, I found a problem with the way replacements are being done now. > > See this method: > > graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReplacementsImpl.java > > > 107 @Override > 108 public StructuredGraph getMethodSubstitution(ResolvedJavaMethod original) { > 109 for (GraphProducer gp : graphProducers) { > 110 StructuredGraph graph = gp.getGraphFor(original); > 111 if (graph != null) { > 112 return graph; > 113 } > 114 } > 115 return super.getMethodSubstitution(original); > 116 } > > > Here it loops over the backends until it gets a hit. In our tests, I found that while we are compiling an HSAIL kernel that is actually a Stream API lambda, when it goes into getIntrinsicGraph(), it will go into getMethodSubstitution() and look for substitutions in the PTX backend, see the "lambda$" method we are compiling and try to produce a PTX kernel of the thing we are in the middle of compiling for HSAIL, which was a shock :) > > Up til now, we have been using the replacements/inline mechanism for example AtomicInteger that end up as fence/load/fence type ops, and other uses, that get inlined into the kernel body and that is working well so far. > > I have a suitable PTX card in my box so I might be the only one in the group that might see this problem. The existing HSAIL KernelTester tests in the public repo do not get this problem since the harness sends an ordinary method to get HSAIL-compiled and they are not called "lambda$..." > > I think I see that the strategy for offloading for PTX so far is doing a "replacement" of a CPU method with a GPU kernel. But we also want to have some replacements/inlining inside the kernel. Hmm, interesting problem. Although I don?t have an answer to your question I want to put out this general question: How are we going to decide which methods to offload to which GPU given that there is more than one GPU in the system? > > What is the best way to fix this problem? > Thanks, > Eric > > From doug.simon at oracle.com Mon Mar 3 18:00:09 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 04 Mar 2014 02:00:09 +0000 Subject: hg: graal/graal: 7 new changesets Message-ID: <20140304020114.8671062481@hg.openjdk.java.net> Changeset: 67d2c95bfa43 Author: Andreas Woess Date: 2014-02-26 13:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/67d2c95bfa43 dsl processor: delete unused classes - graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/api/ExtensionProcessor.java - graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeTreeVariable.java - graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/SpecializationListenerData.java - graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/JavaName.java Changeset: 2864cb92fa9a Author: Andreas Woess Date: 2014-02-26 15:34 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2864cb92fa9a TruffleDSL: retire NodeFactory#createNodeGeneric ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/TestHelper.java ! graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/NodeFactory.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: 3bd2ad96f162 Author: Andreas Woess Date: 2014-03-03 10:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3bd2ad96f162 TruffleCompilerOptions: add help texts, delete old options ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java Changeset: 0b3960586b48 Author: Andreas Woess Date: 2014-03-03 12:04 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0b3960586b48 IGV: fix NPE ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/Properties.java Changeset: 7b5269608cb3 Author: Tom Rodriguez Date: 2014-02-26 11:39 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/7b5269608cb3 put tighter types on some builtin operations ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotLoweringProvider.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/ThreadSubstitutions.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java Changeset: 8b23db5f4164 Author: Tom Rodriguez Date: 2014-02-28 16:35 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/8b23db5f4164 fix field access and casts in method substitutions ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotForeignCallsProvider.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.nodes/src/com/oracle/graal/nodes/PiNode.java Changeset: fde464340755 Author: Tom Rodriguez Date: 2014-02-28 16:35 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/fde464340755 don't allow unresolved field types to hang around ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java From doug.simon at oracle.com Tue Mar 4 02:01:23 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 4 Mar 2014 11:01:23 +0100 Subject: Substitution/Replacements problem In-Reply-To: References: <53150F7A.6020103@amd.com> Message-ID: <148CBF35-FB8F-4C30-BF24-B4E635579073@oracle.com> On Mar 4, 2014, at 1:47 AM, Christian Thalinger wrote: > > On Mar 3, 2014, at 3:25 PM, Eric Caspole wrote: > >> Hi everybody, >> We have a lot of lambda based tests that are not in the public repo yet, waiting for JDK 8 to come to Graal. In these tests, I found a problem with the way replacements are being done now. >> >> See this method: >> >> graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReplacementsImpl.java >> >> >> 107 @Override >> 108 public StructuredGraph getMethodSubstitution(ResolvedJavaMethod original) { >> 109 for (GraphProducer gp : graphProducers) { >> 110 StructuredGraph graph = gp.getGraphFor(original); >> 111 if (graph != null) { >> 112 return graph; >> 113 } >> 114 } >> 115 return super.getMethodSubstitution(original); >> 116 } >> >> >> Here it loops over the backends until it gets a hit. In our tests, I found that while we are compiling an HSAIL kernel that is actually a Stream API lambda, when it goes into getIntrinsicGraph(), it will go into getMethodSubstitution() and look for substitutions in the PTX backend, see the "lambda$" method we are compiling and try to produce a PTX kernel of the thing we are in the middle of compiling for HSAIL, which was a shock :) >> >> Up til now, we have been using the replacements/inline mechanism for example AtomicInteger that end up as fence/load/fence type ops, and other uses, that get inlined into the kernel body and that is working well so far. >> >> I have a suitable PTX card in my box so I might be the only one in the group that might see this problem. The existing HSAIL KernelTester tests in the public repo do not get this problem since the harness sends an ordinary method to get HSAIL-compiled and they are not called "lambda$..." >> >> I think I see that the strategy for offloading for PTX so far is doing a "replacement" of a CPU method with a GPU kernel. But we also want to have some replacements/inlining inside the kernel. This integration of GPU offloading into the normal compiler pipeline is a hack that should be removed. I put it in only so that Bharadwaj could easily test PTX offloading without having to do the Stream API interposition. The reason that it?s a hack is that it exactly ignores the policy problem of what to offload and to which available GPU. Bharadwaj, can you move to the Sumatra way of offloading soon? Once you?ve done this, I?ll remove this hack. > Hmm, interesting problem. Although I don?t have an answer to your question I want to put out this general question: > > How are we going to decide which methods to offload to which GPU given that there is more than one GPU in the system? Very good question. >> What is the best way to fix this problem? Use -XX:-GPUOffload for now. I don?t think Sumatra uses this option. -Doug From bharadwaj.yadavalli at oracle.com Tue Mar 4 07:23:44 2014 From: bharadwaj.yadavalli at oracle.com (S. Bharadwaj Yadavalli) Date: Tue, 04 Mar 2014 10:23:44 -0500 Subject: Substitution/Replacements problem In-Reply-To: <148CBF35-FB8F-4C30-BF24-B4E635579073@oracle.com> References: <53150F7A.6020103@amd.com> <148CBF35-FB8F-4C30-BF24-B4E635579073@oracle.com> Message-ID: <5315F000.20301@oracle.com> On 03/04/2014 05:01 AM, Doug Simon wrote: > On Mar 4, 2014, at 1:47 AM, Christian Thalinger wrote: > >> On Mar 3, 2014, at 3:25 PM, Eric Caspole wrote: <...> >>> Up til now, we have been using the replacements/inline mechanism for example AtomicInteger that end up as fence/load/fence type ops, and other uses, that get inlined into the kernel body and that is working well so far. >>> >>> I have a suitable PTX card in my box so I might be the only one in the group that might see this problem. The existing HSAIL KernelTester tests in the public repo do not get this problem since the harness sends an ordinary method to get HSAIL-compiled and they are not called "lambda$..." >>> >>> I think I see that the strategy for offloading for PTX so far is doing a "replacement" of a CPU method with a GPU kernel. But we also want to have some replacements/inlining inside the kernel. > This integration of GPU offloading into the normal compiler pipeline is a hack that should be removed. I put it in only so that Bharadwaj could easily test PTX offloading without having to do the Stream API interposition. The reason that it?s a hack is that it exactly ignores the policy problem of what to offload and to which available GPU. Bharadwaj, can you move to the Sumatra way of offloading soon? Once you?ve done this, I?ll remove this hack. I'll work on making the needed changes. Bharadwaj From eric.caspole at amd.com Tue Mar 4 07:28:24 2014 From: eric.caspole at amd.com (Eric Caspole) Date: Tue, 4 Mar 2014 10:28:24 -0500 Subject: Substitution/Replacements problem In-Reply-To: <5315F000.20301@oracle.com> References: <53150F7A.6020103@amd.com> <148CBF35-FB8F-4C30-BF24-B4E635579073@oracle.com> <5315F000.20301@oracle.com> Message-ID: <5315F118.3090600@amd.com> That will be great, I was thinking yesterday we could then have at least a couple simple offload tests in common for the two GPUs. On 03/04/2014 10:23 AM, S. Bharadwaj Yadavalli wrote: > > On 03/04/2014 05:01 AM, Doug Simon wrote: >> On Mar 4, 2014, at 1:47 AM, Christian Thalinger >> wrote: >> >>> On Mar 3, 2014, at 3:25 PM, Eric Caspole wrote: > <...> >>>> Up til now, we have been using the replacements/inline mechanism for >>>> example AtomicInteger that end up as fence/load/fence type ops, and >>>> other uses, that get inlined into the kernel body and that is >>>> working well so far. >>>> >>>> I have a suitable PTX card in my box so I might be the only one in >>>> the group that might see this problem. The existing HSAIL >>>> KernelTester tests in the public repo do not get this problem since >>>> the harness sends an ordinary method to get HSAIL-compiled and they >>>> are not called "lambda$..." >>>> >>>> I think I see that the strategy for offloading for PTX so far is >>>> doing a "replacement" of a CPU method with a GPU kernel. But we also >>>> want to have some replacements/inlining inside the kernel. >> This integration of GPU offloading into the normal compiler pipeline >> is a hack that should be removed. I put it in only so that Bharadwaj >> could easily test PTX offloading without having to do the Stream API >> interposition. The reason that it?s a hack is that it exactly ignores >> the policy problem of what to offload and to which available GPU. >> Bharadwaj, can you move to the Sumatra way of offloading soon? Once >> you?ve done this, I?ll remove this hack. > > I'll work on making the needed changes. > > Bharadwaj > > From bharadwaj.yadavalli at oracle.com Tue Mar 4 07:54:24 2014 From: bharadwaj.yadavalli at oracle.com (S. Bharadwaj Yadavalli) Date: Tue, 04 Mar 2014 10:54:24 -0500 Subject: Substitution/Replacements problem In-Reply-To: <5315F118.3090600@amd.com> References: <53150F7A.6020103@amd.com> <148CBF35-FB8F-4C30-BF24-B4E635579073@oracle.com> <5315F000.20301@oracle.com> <5315F118.3090600@amd.com> Message-ID: <5315F730.4020207@oracle.com> On 03/04/2014 10:28 AM, Eric Caspole wrote: > That will be great, I was thinking yesterday we could then have at > least a couple simple offload tests in common for the two GPUs. > Sure. Do you have candidate tests in mind? I was thinking of something like matrix multiply and may be FFT implementation (??) to start with. Bharadwaj From tom.deneau at amd.com Tue Mar 4 10:49:10 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 4 Mar 2014 18:49:10 +0000 Subject: installHsailCode Message-ID: Gilles -- While preparing for this upcoming webrev for our deoptimization work using your trampoline infrastructure, I noticed we still call installHsailCode but that no longer contains code for a special HsailCodeInstaller (which we both agreed we no longer need). So now it looks just like the original graalCompilerToVM.installCode0 so I will just redirect to that. As a side question, what does this code accomplish? Does it install the host trampoline code associated with the hsail kernel? -- Tom From tom.deneau at amd.com Tue Mar 4 16:27:50 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 5 Mar 2014 00:27:50 +0000 Subject: replacing nodes with DeoptimizeNodes Message-ID: Let's say there is some random graal node that you choose not to implement so you want it to be replaced by a DeoptimizeNode. How does one do that if the original node is not a terminal node, ie, it has usages? -- Tom From doug.simon at oracle.com Tue Mar 4 18:00:10 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 05 Mar 2014 02:00:10 +0000 Subject: hg: graal/graal: 3 new changesets Message-ID: <20140305020021.2432D624E0@hg.openjdk.java.net> Changeset: d2c84a0bf37a Author: Chris Seaton Date: 2014-03-04 01:08 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/d2c84a0bf37a Remove Ruby implementation. ! .hgignore - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/CoreSource.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/CoreSourceSection.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/DefinedNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/InlinableMethodImplementation.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/ReadNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/RubyNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/RubyRootNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/RubyTypes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/WriteNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/BooleanDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/BoxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/BoxingDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/CachedBoxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/CachedUnboxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/CallNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/DispatchHeadNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/DispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/GeneralBoxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/GeneralSuperCallNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/InlineHeuristic.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/InlinedBoxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/InlinedUnboxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/ProcOrNullNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/UnboxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/UninitializedBoxingDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/UninitializedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/cast/BooleanCastNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/cast/LambdaNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/cast/ProcCastNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/cast/SplatCastNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/cast/StringToRegexpNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/cast/StringToSymbolNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/constants/CachedReadConstantNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/constants/ReadConstantNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/constants/UninitializedReadConstantNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/constants/WriteConstantNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/AndNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/BreakNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/ElidableResultNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/EnsureNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/FlipFlopNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/IfNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/NextNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/NotNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/OrNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/RedoNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/RescueAnyNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/RescueClassesNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/RescueNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/RescueSplatNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/RetryNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/ReturnNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/SequenceNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/TryNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/WhileNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ArrayConcatNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ArrayCoreMethodNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ArrayIndexNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ArrayNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ArrayPushNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ArrayRestNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/BasicObjectNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/BignumNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ClassNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ComparableNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ContinuationNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/CoreClass.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/CoreMethod.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/CoreMethodNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/CoreMethodNodeManager.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/DirNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ExceptionNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/FalseClassNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/FiberNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/FileNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/FixnumNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/FloatNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/HashNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/InterpolatedStringNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/KernelNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/MainNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/MatchDataNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/MathNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ModuleNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/NilClassNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ObjectNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ObjectSpaceNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ProcNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ProcessNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/RangeNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/RegexpNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/SignalNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/StringNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/StructNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/SymbolNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/SystemNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ThreadNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/TimeNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/TrueClassNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/YieldingCoreMethodNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/ActiveEnterDebugProbe.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/ActiveLeaveDebugProbe.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/ActiveLineDebugProbe.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/ActiveLocalDebugProbe.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/DebugNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/InactiveEnterDebugProbe.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/InactiveLeaveDebugProbe.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/InactiveLineDebugProbe.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/InactiveLocalDebugProbe.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/RubyASTPrinter.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/RubyProbe.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/RubyProxyNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/RubyTraceProbe.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/BignumLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/BooleanLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/FixnumLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/FloatLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/HashLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/NilNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/ObjectLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/RangeLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/StringLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/array/ArrayLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/array/FixnumArrayLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/array/ObjectArrayLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/array/UninitialisedArrayLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/AddMethodNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/AliasNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/BlockDefinitionNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/CatchNextNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/CatchReturnAsErrorNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/CatchReturnNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/MethodDefinitionNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/ShellResultNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/BlockDestructureSwitchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/CheckArityNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadAllArgumentsNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadBlockArgumentNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadDestructureArgumentNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadOptionalArgumentNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadPostArgumentNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadPreArgumentNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadRestArgumentNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/FlipFlopStateNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/FrameSlotNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/InitFlipFlopSlotNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/LevelFlipFlopStateNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/LocalFlipFlopStateNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/ReadLevelVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/ReadLocalVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/WriteLevelVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/WriteLocalVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/ClassNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/DefineOrGetClassNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/DefineOrGetModuleNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/OpenModuleNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/ReadClassVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/SelfNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/SingletonClassNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/WriteClassVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/ReadFixnumInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/ReadFloatInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/ReadInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/ReadMissingInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/ReadObjectInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/ReadSpecializedInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/UninitializedReadInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/UninitializedWriteInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/WriteFixnumInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/WriteFloatInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/WriteInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/WriteObjectInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/WriteSpecializedInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/yield/GeneralYieldDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/yield/InlinedYieldDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/yield/UninitializedYieldDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/yield/YieldDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/yield/YieldNode.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/DeadNode.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/DefaultRubyNodeInstrumenter.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/JRubyParser.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/MethodTranslator.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/ModuleTranslator.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/RubyFrameTypeConversion.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/RubyNodeInstrumenter.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/Translator.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/TranslatorEnvironment.java - graal/com.oracle.truffle.ruby.runtime/.checkstyle_checks.xml - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/InputReader.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/NilPlaceholder.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/RubyArguments.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/RubyContext.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/RubyParser.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/RubyParserResult.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/ShellResult.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/UndefinedPlaceholder.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/configuration/Configuration.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/configuration/ConfigurationBuilder.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/BreakException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/BreakShellException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/ContinuationReturnException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/ExceptionTranslator.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/NextException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/QuitException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/RaiseException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/RedoException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/RetryException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/ReturnException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/ThrowException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/CoreLibrary.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/GeneralConversions.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyBignum.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyBinding.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyClass.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyContinuation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyFalseClass.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyFiber.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyFile.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyFixnum.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyFloat.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyHash.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyMatchData.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyModule.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyNilClass.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyObject.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyProc.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyRegexp.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyString.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubySymbol.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyThread.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyTime.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyTrueClass.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/StringFormatter.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/ArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/ArrayUtilities.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/BaseArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/EmptyArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/FixnumArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/FixnumImmutablePairArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/GeneraliseArrayStoreException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/ObjectArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/ObjectImmutablePairArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/RubyArray.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/range/FixnumRange.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/range/ObjectRange.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/range/RubyRange.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/debug/MethodLocal.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/debug/RubyDebugManager.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/lookup/LookupFork.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/lookup/LookupNode.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/lookup/LookupTerminal.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/methods/Arity.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/methods/CallTargetMethodImplementation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/methods/MethodImplementation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/methods/RubyMethod.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/methods/UniqueMethodIdentifier.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/methods/Visibility.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/FixnumStorageLocation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/FloatStorageLocation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/GeneralizeStorageLocationException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/ObjectLayout.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/ObjectStorageLocation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/PrimitiveStorageLocation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/RubyBasicObject.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/StorageLocation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/Unboxable.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/subsystems/AtExitManager.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/subsystems/FeatureManager.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/subsystems/FiberManager.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/subsystems/ObjectSpaceManager.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/subsystems/ThreadManager.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/subsystems/TraceManager.java - graal/com.oracle.truffle.ruby.shell/src/com/oracle/truffle/ruby/shell/CommandLineOptions.java - graal/com.oracle.truffle.ruby.shell/src/com/oracle/truffle/ruby/shell/CommandLineParser.java - graal/com.oracle.truffle.ruby.shell/src/com/oracle/truffle/ruby/shell/Shell.java - graal/com.oracle.truffle.ruby.test/specs/README - graal/com.oracle.truffle.ruby.test/specs/rubytruffle - graal/com.oracle.truffle.ruby.test/specs/rubytruffle.mspec - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_a_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_d_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_e_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_n_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_p_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_r_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_s_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_upper_e_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_upper_f_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_upper_i_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_upper_u_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_upper_w_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_v_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_w_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_x_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/error_message_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/BEGIN_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/alias_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/array_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/block_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/break_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/case_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/class_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/class_variable_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/constants_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/def_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/defined_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/encoding_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/ensure_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/execution_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/file_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/for_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/hash_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/line_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/literal_lambda_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/magic_comment_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/match_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/metaclass_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/module_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/next_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/precedence_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/predefined/data_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/predefined_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/private_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/proc_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/redo_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/anchors_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/back-references_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/character_classes_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/encoding_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/escapes_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/grouping_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/interpolation_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/modifiers_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/repetition_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/rescue_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/retry_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/return_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/send_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/singleton_class_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/splat_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/string_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/super_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/symbol_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/throw_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/undef_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/until_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/variables_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/while_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/yield_tags.txt - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/RubyTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ArrayTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/BignumTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/BoolTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ContinuationTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/FiberTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/FixnumTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/FloatTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/HashTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/IntegerTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/KernelTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/MathTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ModuleTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ObjectSpaceTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ObjectTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ProcTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/RangeTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/RegexpTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/StringTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/SymbolTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ThreadTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/AndTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/BlockTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/CaseTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/ClassLocalTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/ClassTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/ConstantTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/ForTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/GlobalVariableTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/IfTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/InterpolatedStringTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/LocalTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/MethodTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/ModuleTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/MultipleAssignmentTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/OrTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/PolymorphismTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/RaiseRescueTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/RedefinitionTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/ShortcutTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/SpecialVariableTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/UntilTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/WhileTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/runtime/ObjectLayoutTests.java ! mx/mx_graal.py ! mx/projects Changeset: 6b8e10e585df Author: twisti Date: 2014-03-03 20:40 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/6b8e10e585df removed duplicate vmStructs entries ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 516eeabb4c62 Author: Tom Rodriguez Date: 2014-03-04 16:12 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/516eeabb4c62 avoid deadlock in clinit of HotSpotResolvedJavaField ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java From doug.simon at oracle.com Wed Mar 5 02:18:00 2014 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 5 Mar 2014 11:18:00 +0100 Subject: replacing nodes with DeoptimizeNodes In-Reply-To: References: Message-ID: <9D3E175A-2980-48FA-A62F-B16F7C613558@oracle.com> On Mar 5, 2014, at 1:27 AM, Deneau, Tom wrote: > Let's say there is some random graal node that you choose not to implement so you want it to be replaced by a DeoptimizeNode. How does one do that if the original node is not a terminal node, ie, it has usages? The subgraph rooted at that node has to be removed (probably through use of com.oracle.graal.nodes.util.GraphUtil.killWithUnusedFloatingInputs(Node)). -Doug From duboscq at ssw.jku.at Wed Mar 5 02:28:39 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Wed, 5 Mar 2014 11:28:39 +0100 Subject: replacing nodes with DeoptimizeNodes In-Reply-To: <9D3E175A-2980-48FA-A62F-B16F7C613558@oracle.com> References: <9D3E175A-2980-48FA-A62F-B16F7C613558@oracle.com> Message-ID: On Wed, Mar 5, 2014 at 11:18 AM, Doug Simon wrote: > > On Mar 5, 2014, at 1:27 AM, Deneau, Tom wrote: > >> Let's say there is some random graal node that you choose not to implement so you want it to be replaced by a DeoptimizeNode. How does one do that if the original node is not a terminal node, ie, it has usages? > > The subgraph rooted at that node has to be removed (probably through use of com.oracle.graal.nodes.util.GraphUtil.killWithUnusedFloatingInputs(Node)). Rather GraphUtil.killCFG(Node). As an example, you can look at CanonicalizerPhase.performReplacement (around line 297): //case 7 fixed.predecessor().replaceFirstSuccessor(fixed, canonical); GraphUtil.killCFG(fixed); even better would be: fixed.replaceAtPredecessor(canonical); GraphUtil.killCFG(fixed); where in you case fixed is the node you want to replace and canonical is the DeoptimizeNode. > > -Doug From java at stefan-marr.de Wed Mar 5 07:57:03 2014 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 5 Mar 2014 16:57:03 +0100 Subject: Truffle CallNode API In-Reply-To: References: Message-ID: Hi Christian: I finally adopted CallNodes, however I wonder how this interacts with things like lexical scoping. Until now, I had special treatment for lexical scoping of blocks that get inlined. How do I communicate that to your inlining framework? I found the `split()` method in RootNode, which happens to be unused in SimpleLanguage, and without a comment, I am kind of unsure whether it is the right hook. Is the idea that I return my properly contextualized copy from split? Perhaps a brief example to show the problem I am thinking of: foo: a = ( a = 0 ifTrue: [ ^ a + 1 ] ifFalse: [ ^ a + ?foobar' ] ) Both blocks are methods that are eventually inlined. However, they both access `a`, and thus, they depend on FrameSlot of it. Now, extending the example by introducing the bar and baz methods: bar = ( ^ self foo: 0 ) baz = ( ^ self foo: ?something and ' ) When #foo: gets inlined into these two methods, I need to use independent copies of the original two block methods in each of the inlined versions, so that the FrameSlot can specialize independently. #bar is supposed to specialize completely for integers, and #baz should specialize to strings. Thanks Stefan On 29 Jan 2014, at 22:09, Christian Humer wrote: > I just updated the Truffle Inlining API with a more robust solution (will > get pushed to openjdk this night). > I removed the old API namely the following interfaces InlinableCallSite and > InlinedCallSite. > As a replacement for those classes you should now use a new class CallNode. > This class is already a Node and can directly be used as such inside of an > polymorphic function inline cache. > For further information on how to use it please see SLDirectDispatchNode > and the javadoc in the CallNode class. > > Feel free to ask further questions. > > Thanks. > > - Christian Humer -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From miguelalfredo.garcia at epfl.ch Wed Mar 5 08:12:38 2014 From: miguelalfredo.garcia at epfl.ch (Garcia Gutierrez Miguel Alfredo) Date: Wed, 5 Mar 2014 16:12:38 +0000 Subject: New type-profiling points in HotSpot, how to use them from Graal? Message-ID: <7E4228B446372948BBB2916FC53FA49E26E56C06@REXMD.intranet.epfl.ch> Hi, It would be great to hear more about that (recently added) functionality in HotSpot. My goal is to have Graal exploit that information. The pointers I'm aware about: (1) http://openjdk.5641.n7.nabble.com/RFR-L-8026054-New-type-profiling-points-type-of-return-values-at-calls-td159355.html (2) http://cr.openjdk.java.net/~roland/8023657/ Summary: x86 interpreter and c1 type profiling for arguments at calls (3) http://cr.openjdk.java.net/~roland/8026054/ Summary: x86 interpreter and c1 type profiling for return values at calls Miguel From christian.humer at gmail.com Wed Mar 5 10:38:52 2014 From: christian.humer at gmail.com (Christian Humer) Date: Wed, 5 Mar 2014 19:38:52 +0100 Subject: Truffle CallNode API In-Reply-To: References: Message-ID: Hi Stefan, I recently changed the inlining heuristic and semantics. I will come up with proper documentation about it soon. Inlining now just pulls a lever for the truffle compiler to inline a certain method in the call graph. As you said it does not contextualize the callee AST into the caller AST anymore. The contextualization on inlining required the interpreter to reprofile the AST after inlining, which delayed the compilation in an unfavorable way. Contextualization is of course still required. Therefore we introduced a new concept called splitting. Splitting basically creates a new CallTarget with an uninitialized AST of the same method and calls the new target instead of the original target. This new target may then afterwards be inlined or not depending on the inlining budget and other criteria. While the inlining heuristic is already quite fine, the split heuristic is still work in progress. So splitting is currently disabled by default. The SimpleLanguage already implements the required parts to support and enable splitting. To support splitting you have to override the methods isSplittable and split in your RootNode implementation. Here is the implementation from the SimpleLanguage which I think you can reuse roughly. @Override public boolean isSplittable() { return true; } @Override public RootNode split() { return new SLRootNode(getFrameDescriptor().shallowCopy(), NodeUtil.cloneNode(uninitializedBodyNode), name); } There is also new API for the CallNode: boolean isSplittable() true if the underlying RootNode returns true in isSplittable boolean isSplit() true if the CallTarget for this CallNode was split. CallTarget getSplitCallTarget() returns the call target that was split. boolean split() enforce a split on the CallTarget. Splitting can also be disabled globally with -G:-TruffleSplittingEnabled (enabled by default). I have to admit that the current heuristic for splitting is quite rough. So I can recommend you to enforce inlining and splitting with CallNode#inline and CallNode#split on the important calls for now. Is that good enough for you, for now? In the future this decision will be based on the polymorphism of the called method. Therefore we also introduced a new method to Node getKind. getKind returns whether the actual node is specialized/monomorphic, polymorphic or generic/megamorphic. By counting polymorphic/megamorphic nodes we can do a good guess if a split could be worthwhile or not. For this heuristic to work you have to implement #getKind() in your specializations. Nodes that use Truffle DSL automatically get support for that. Hope this helps. Please feel free to ask further questions. Thanks. - Christian Humer On Wed, Mar 5, 2014 at 4:57 PM, Stefan Marr wrote: > Hi Christian: > > I finally adopted CallNodes, however I wonder how this interacts with > things like lexical scoping. > Until now, I had special treatment for lexical scoping of blocks that get > inlined. > > How do I communicate that to your inlining framework? > I found the `split()` method in RootNode, which happens to be unused in > SimpleLanguage, and without a comment, I am kind of unsure whether it is > the right hook. > > Is the idea that I return my properly contextualized copy from split? > > Perhaps a brief example to show the problem I am thinking of: > > foo: a = ( > a = 0 ifTrue: [ ^ a + 1 ] > ifFalse: [ ^ a + 'foobar' ] > ) > > Both blocks are methods that are eventually inlined. However, they both > access `a`, and thus, they depend on FrameSlot of it. > Now, extending the example by introducing the bar and baz methods: > > bar = ( ^ self foo: 0 ) > baz = ( ^ self foo: 'something and ' ) > > When #foo: gets inlined into these two methods, I need to use independent > copies of the original two block methods in each of the inlined versions, > so that the FrameSlot can specialize independently. #bar is supposed to > specialize completely for integers, and #baz should specialize to strings. > > Thanks > Stefan > > > On 29 Jan 2014, at 22:09, Christian Humer > wrote: > > > I just updated the Truffle Inlining API with a more robust solution (will > > get pushed to openjdk this night). > > I removed the old API namely the following interfaces InlinableCallSite > and > > InlinedCallSite. > > As a replacement for those classes you should now use a new class > CallNode. > > This class is already a Node and can directly be used as such inside of > an > > polymorphic function inline cache. > > For further information on how to use it please see SLDirectDispatchNode > > and the javadoc in the CallNode class. > > > > Feel free to ask further questions. > > > > Thanks. > > > > - Christian Humer > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > From jules_gosnell at yahoo.com Wed Mar 5 15:56:29 2014 From: jules_gosnell at yahoo.com (Julian Gosnell) Date: Wed, 5 Mar 2014 15:56:29 -0800 (PST) Subject: Graal and Clojure Message-ID: <1394063789.8387.YahooMailNeo@web122406.mail.ne1.yahoo.com> Guys, I just built the Java8 / Graal / Okra stack and managed to run some very simple Clojure copying the contents of one int array into another one on Okra. https://groups.google.com/forum/#!topic/clojure/JpjK__NTR5Y I find the ramifications of this very exciting :-) I understand that fn-ality is limited at the moment - but I am keen to keep testing and to help ensure early visibility of Clojure related issues to both communities - perhaps even the submission of a Clojure testsuite if Graal developers thought that useful. I'd be very interested in your thoughts on Graal / Clojure. regards, Jules From doug.simon at oracle.com Wed Mar 5 18:00:12 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 06 Mar 2014 02:00:12 +0000 Subject: hg: graal/graal: 33 new changesets Message-ID: <20140306020259.49ECD62537@hg.openjdk.java.net> Changeset: e85575f63b60 Author: twisti Date: 2014-03-04 20:07 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e85575f63b60 moved readCString to UnsafeAccess next to the other methods ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/UnsafeAccess.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java Changeset: 361acb279104 Author: twisti Date: 2014-03-04 22:23 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/361acb279104 moved to-constant-pool-index conversion up to Java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotConstantPool.java ! src/share/vm/graal/graalCompiler.hpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: a7f26a522439 Author: Josef Eisl Date: 2014-03-05 10:11 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a7f26a522439 Direct LIR generation: added alternative compilation path to GraalCompilerTest. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: 4c2bfd3e6021 Author: Josef Eisl Date: 2014-03-05 10:11 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4c2bfd3e6021 Direct LIR generation: created a copy of GraphBuilderPhase for LIR generation. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java + graal/com.oracle.graal.java/src/com/oracle/graal/java/LIRBuilderPhase.java Changeset: 89bbedfe0ad3 Author: Josef Eisl Date: 2014-03-05 10:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/89bbedfe0ad3 Direct LIR generation: refactoring alternative compilation path in GraalCompilerTest. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java Changeset: 829dacd23dc3 Author: Josef Eisl Date: 2014-03-05 10:13 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/829dacd23dc3 Direct LIR generation: make compileBytecodeToLIR static. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java Changeset: 38c881305352 Author: Thomas Wuerthinger Date: 2014-02-25 17:51 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/38c881305352 Move functionality of SpillMoveFactory to FrameMap. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/MoveResolver.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/PTXFrameMap.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/LIR.java Changeset: d451a134a545 Author: Thomas Wuerthinger Date: 2014-02-25 18:16 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d451a134a545 Remove unused import. ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIR.java Changeset: ff5aca1b2878 Author: Thomas Wuerthinger Date: 2014-02-25 18:17 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ff5aca1b2878 Merge. Changeset: 96946b41aae7 Author: Thomas Wuerthinger Date: 2014-02-26 13:07 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/96946b41aae7 Merge. Changeset: a3cd3403a958 Author: Thomas Wuerthinger Date: 2014-02-26 13:09 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a3cd3403a958 Remove unused imports. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java Changeset: 09d41e2f8dc7 Author: Thomas Wuerthinger Date: 2014-02-28 16:19 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/09d41e2f8dc7 Merge. - graal/com.oracle.graal.asm/src/com/oracle/graal/asm/AbstractAssembler.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/GraphKit.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java Changeset: 60637fc3fa8c Author: Thomas Wuerthinger Date: 2014-03-05 10:27 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/60637fc3fa8c Merge. ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java - graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/api/ExtensionProcessor.java - graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeTreeVariable.java - graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/SpecializationListenerData.java - graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/JavaName.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/CoreSource.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/CoreSourceSection.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/DefinedNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/InlinableMethodImplementation.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/ReadNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/RubyNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/RubyRootNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/RubyTypes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/WriteNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/BooleanDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/BoxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/BoxingDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/CachedBoxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/CachedUnboxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/CallNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/DispatchHeadNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/DispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/GeneralBoxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/GeneralSuperCallNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/InlineHeuristic.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/InlinedBoxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/InlinedUnboxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/ProcOrNullNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/UnboxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/UninitializedBoxingDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/UninitializedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/cast/BooleanCastNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/cast/LambdaNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/cast/ProcCastNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/cast/SplatCastNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/cast/StringToRegexpNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/cast/StringToSymbolNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/constants/CachedReadConstantNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/constants/ReadConstantNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/constants/UninitializedReadConstantNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/constants/WriteConstantNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/AndNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/BreakNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/ElidableResultNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/EnsureNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/FlipFlopNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/IfNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/NextNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/NotNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/OrNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/RedoNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/RescueAnyNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/RescueClassesNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/RescueNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/RescueSplatNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/RetryNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/ReturnNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/SequenceNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/TryNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/WhileNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ArrayConcatNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ArrayCoreMethodNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ArrayIndexNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ArrayNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ArrayPushNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ArrayRestNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/BasicObjectNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/BignumNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ClassNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ComparableNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ContinuationNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/CoreClass.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/CoreMethod.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/CoreMethodNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/CoreMethodNodeManager.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/DirNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ExceptionNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/FalseClassNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/FiberNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/FileNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/FixnumNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/FloatNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/HashNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/InterpolatedStringNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/KernelNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/MainNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/MatchDataNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/MathNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ModuleNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/NilClassNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ObjectNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ObjectSpaceNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ProcNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ProcessNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/RangeNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/RegexpNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/SignalNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/StringNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/StructNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/SymbolNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/SystemNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ThreadNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/TimeNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/TrueClassNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/YieldingCoreMethodNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/ActiveEnterDebugProbe.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/ActiveLeaveDebugProbe.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/ActiveLineDebugProbe.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/ActiveLocalDebugProbe.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/DebugNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/InactiveEnterDebugProbe.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/InactiveLeaveDebugProbe.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/InactiveLineDebugProbe.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/InactiveLocalDebugProbe.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/RubyASTPrinter.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/RubyProbe.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/RubyProxyNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/RubyTraceProbe.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/BignumLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/BooleanLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/FixnumLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/FloatLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/HashLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/NilNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/ObjectLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/RangeLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/StringLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/array/ArrayLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/array/FixnumArrayLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/array/ObjectArrayLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/array/UninitialisedArrayLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/AddMethodNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/AliasNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/BlockDefinitionNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/CatchNextNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/CatchReturnAsErrorNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/CatchReturnNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/MethodDefinitionNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/ShellResultNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/BlockDestructureSwitchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/CheckArityNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadAllArgumentsNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadBlockArgumentNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadDestructureArgumentNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadOptionalArgumentNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadPostArgumentNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadPreArgumentNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadRestArgumentNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/FlipFlopStateNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/FrameSlotNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/InitFlipFlopSlotNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/LevelFlipFlopStateNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/LocalFlipFlopStateNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/ReadLevelVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/ReadLocalVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/WriteLevelVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/WriteLocalVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/ClassNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/DefineOrGetClassNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/DefineOrGetModuleNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/OpenModuleNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/ReadClassVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/SelfNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/SingletonClassNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/WriteClassVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/ReadFixnumInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/ReadFloatInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/ReadInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/ReadMissingInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/ReadObjectInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/ReadSpecializedInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/UninitializedReadInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/UninitializedWriteInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/WriteFixnumInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/WriteFloatInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/WriteInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/WriteObjectInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/WriteSpecializedInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/yield/GeneralYieldDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/yield/InlinedYieldDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/yield/UninitializedYieldDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/yield/YieldDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/yield/YieldNode.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/DeadNode.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/DefaultRubyNodeInstrumenter.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/JRubyParser.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/MethodTranslator.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/ModuleTranslator.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/RubyFrameTypeConversion.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/RubyNodeInstrumenter.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/Translator.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/TranslatorEnvironment.java - graal/com.oracle.truffle.ruby.runtime/.checkstyle_checks.xml - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/InputReader.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/NilPlaceholder.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/RubyArguments.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/RubyContext.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/RubyParser.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/RubyParserResult.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/ShellResult.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/UndefinedPlaceholder.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/configuration/Configuration.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/configuration/ConfigurationBuilder.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/BreakException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/BreakShellException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/ContinuationReturnException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/ExceptionTranslator.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/NextException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/QuitException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/RaiseException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/RedoException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/RetryException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/ReturnException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/ThrowException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/CoreLibrary.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/GeneralConversions.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyBignum.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyBinding.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyClass.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyContinuation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyFalseClass.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyFiber.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyFile.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyFixnum.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyFloat.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyHash.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyMatchData.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyModule.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyNilClass.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyObject.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyProc.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyRegexp.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyString.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubySymbol.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyThread.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyTime.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyTrueClass.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/StringFormatter.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/ArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/ArrayUtilities.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/BaseArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/EmptyArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/FixnumArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/FixnumImmutablePairArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/GeneraliseArrayStoreException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/ObjectArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/ObjectImmutablePairArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/RubyArray.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/range/FixnumRange.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/range/ObjectRange.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/range/RubyRange.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/debug/MethodLocal.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/debug/RubyDebugManager.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/lookup/LookupFork.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/lookup/LookupNode.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/lookup/LookupTerminal.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/methods/Arity.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/methods/CallTargetMethodImplementation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/methods/MethodImplementation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/methods/RubyMethod.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/methods/UniqueMethodIdentifier.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/methods/Visibility.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/FixnumStorageLocation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/FloatStorageLocation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/GeneralizeStorageLocationException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/ObjectLayout.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/ObjectStorageLocation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/PrimitiveStorageLocation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/RubyBasicObject.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/StorageLocation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/Unboxable.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/subsystems/AtExitManager.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/subsystems/FeatureManager.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/subsystems/FiberManager.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/subsystems/ObjectSpaceManager.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/subsystems/ThreadManager.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/subsystems/TraceManager.java - graal/com.oracle.truffle.ruby.shell/src/com/oracle/truffle/ruby/shell/CommandLineOptions.java - graal/com.oracle.truffle.ruby.shell/src/com/oracle/truffle/ruby/shell/CommandLineParser.java - graal/com.oracle.truffle.ruby.shell/src/com/oracle/truffle/ruby/shell/Shell.java - graal/com.oracle.truffle.ruby.test/specs/README - graal/com.oracle.truffle.ruby.test/specs/rubytruffle - graal/com.oracle.truffle.ruby.test/specs/rubytruffle.mspec - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_a_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_d_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_e_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_n_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_p_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_r_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_s_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_upper_e_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_upper_f_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_upper_i_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_upper_u_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_upper_w_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_v_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_w_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_x_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/error_message_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/BEGIN_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/alias_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/array_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/block_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/break_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/case_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/class_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/class_variable_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/constants_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/def_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/defined_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/encoding_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/ensure_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/execution_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/file_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/for_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/hash_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/line_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/literal_lambda_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/magic_comment_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/match_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/metaclass_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/module_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/next_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/precedence_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/predefined/data_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/predefined_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/private_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/proc_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/redo_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/anchors_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/back-references_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/character_classes_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/encoding_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/escapes_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/grouping_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/interpolation_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/modifiers_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/repetition_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/rescue_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/retry_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/return_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/send_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/singleton_class_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/splat_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/string_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/super_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/symbol_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/throw_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/undef_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/until_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/variables_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/while_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/yield_tags.txt - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/RubyTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ArrayTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/BignumTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/BoolTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ContinuationTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/FiberTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/FixnumTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/FloatTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/HashTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/IntegerTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/KernelTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/MathTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ModuleTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ObjectSpaceTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ObjectTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ProcTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/RangeTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/RegexpTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/StringTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/SymbolTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ThreadTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/AndTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/BlockTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/CaseTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/ClassLocalTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/ClassTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/ConstantTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/ForTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/GlobalVariableTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/IfTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/InterpolatedStringTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/LocalTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/MethodTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/ModuleTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/MultipleAssignmentTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/OrTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/PolymorphismTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/RaiseRescueTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/RedefinitionTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/ShortcutTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/SpecialVariableTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/UntilTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/WhileTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/runtime/ObjectLayoutTests.java Changeset: fe8d6e12c75e Author: Thomas Wuerthinger Date: 2014-03-05 10:32 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/fe8d6e12c75e Merge. Changeset: 5dec26f3d4a4 Author: Thomas Wuerthinger Date: 2014-03-05 11:24 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5dec26f3d4a4 Use LIR instead of LIRGenerator as parameter in emitCode. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/Backend.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java Changeset: 56726a90dc71 Author: Thomas Wuerthinger Date: 2014-03-05 13:56 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/56726a90dc71 First draft of baseline compiler. + graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaslineCompiler.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java - graal/com.oracle.graal.java/src/com/oracle/graal/java/LIRBuilderPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java ! mx/projects Changeset: 655a4fd5038b Author: Thomas Wuerthinger Date: 2014-03-05 14:01 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/655a4fd5038b Remove unused imports. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: 73f5ddd8414d Author: Lukas Stadler Date: 2014-03-05 17:53 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/73f5ddd8414d clean up snippet-related assertion in GraphBuilderPhase ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: 2f37b0e442fe Author: Doug Simon Date: 2014-03-05 19:07 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2f37b0e442fe removed remaining VMToCompiler calls for allocating Graal API objects ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompiler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotConstantPool.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotUnresolvedJavaType.java ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalCompiler.hpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalVMToCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.hpp Changeset: a8a82c6e2981 Author: Josef Eisl Date: 2014-03-05 20:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a8a82c6e2981 Remove LIRGenerator from LinearScan. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java Changeset: 2606d64dc08b Author: Doug Simon Date: 2014-03-05 21:37 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2606d64dc08b fixed link in javadoc ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ClassCastNode.java Changeset: 036e61d4cebd Author: Doug Simon Date: 2014-03-05 21:37 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/036e61d4cebd removed HotSpotRuntimeInterpreterInterface ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotRuntimeInterpreterInterface.java Changeset: c5411233cdf8 Author: Christian Humer Date: 2014-03-05 23:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c5411233cdf8 Truffle: Now keeps track of all not just inlined call-sites called by CallNode. Deprecated some old API in NodeUtil. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallNodeProfile.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultCallNode.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/CallNode.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/GraphPrintVisitor.java ! 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 ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/RootNode.java Changeset: ed4b5d1ef667 Author: Christian Humer Date: 2014-03-05 23:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ed4b5d1ef667 Truffle: Added separate option to trace splitting. ! 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: 3cee899bad8a Author: Christian Humer Date: 2014-03-05 23:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3cee899bad8a Truffle: Improved ASTSize output for opt done events. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: 61bc19c3dcdc Author: Christian Humer Date: 2014-03-05 23:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/61bc19c3dcdc Truffle: implemented new tracing flag TraceTruffleCompilationPolymorphism. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallNode.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: 3ea5f337cc0d Author: Christian Humer Date: 2014-03-05 23:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3ea5f337cc0d Truffle-DSL: generate better implementations for getKind() ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: f157fabf6b38 Author: Christian Humer Date: 2014-03-05 23:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f157fabf6b38 Truffle: deprecated CallNode.isInlinable ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallNode.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultCallNode.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/CallNode.java Changeset: ca92db718c74 Author: Christian Humer Date: 2014-03-05 23:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ca92db718c74 Truffle: refined split/inlining heuristics. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallNodeProfile.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 ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/CallNode.java Changeset: cd4595e8a685 Author: Christian Humer Date: 2014-03-05 23:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/cd4595e8a685 Truffle: added notification from callee to callers in the CallNode. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/CallNode.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/RootNode.java Changeset: a5fe04acc81a Author: Christian Humer Date: 2014-03-05 23:58 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a5fe04acc81a Truffle: fixed minor formatting problem. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallNode.java Changeset: 8434ae8c2cdd Author: Tom Rodriguez Date: 2014-03-05 15:50 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/8434ae8c2cdd improve comment ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java Changeset: 1b84e499127b Author: Tom Rodriguez Date: 2014-03-05 16:22 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/1b84e499127b Wrap access to ThreadPoolExecutor to avoid ConcurrentModificationExceptions ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java From doug.simon at oracle.com Thu Mar 6 02:24:22 2014 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 6 Mar 2014 11:24:22 +0100 Subject: Graal and Clojure In-Reply-To: <1394063789.8387.YahooMailNeo@web122406.mail.ne1.yahoo.com> References: <1394063789.8387.YahooMailNeo@web122406.mail.ne1.yahoo.com> Message-ID: Hi Julian, This looks very interesting and will be an good alternative testing vector for the Sumatra work as it matures. If Clojure tests can somehow be made to run from Junit, then I?m sure we can try integrating it into our testing. -Doug On Mar 6, 2014, at 12:56 AM, Julian Gosnell wrote: > Guys, > > I just built the Java8 / Graal / Okra stack and managed to run some very simple Clojure copying the contents of one int array into another one on Okra. > > https://groups.google.com/forum/#!topic/clojure/JpjK__NTR5Y > > > I find the ramifications of this very exciting :-) > > I understand that fn-ality is limited at the moment - but I am keen to keep testing and to help ensure early visibility of Clojure related issues to both communities - perhaps even the submission of a Clojure testsuite if Graal developers thought that useful. > > I'd be very interested in your thoughts on Graal / Clojure. > > regards, > > > Jules > From christian.thalinger at oracle.com Thu Mar 6 11:17:51 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 6 Mar 2014 11:17:51 -0800 Subject: New type-profiling points in HotSpot, how to use them from Graal? In-Reply-To: <7E4228B446372948BBB2916FC53FA49E26E56C06@REXMD.intranet.epfl.ch> References: <7E4228B446372948BBB2916FC53FA49E26E56C06@REXMD.intranet.epfl.ch> Message-ID: <79370FE9-EFD4-46EE-B0E3-A112CA6C564C@oracle.com> On Mar 5, 2014, at 8:12 AM, Garcia Gutierrez Miguel Alfredo wrote: > > Hi, > > It would be great to hear more about that (recently added) functionality in HotSpot. What would you like to hear? > > My goal is to have Graal exploit that information. > > The pointers I'm aware about: > > (1) http://openjdk.5641.n7.nabble.com/RFR-L-8026054-New-type-profiling-points-type-of-return-values-at-calls-td159355.html > > (2) http://cr.openjdk.java.net/~roland/8023657/ > Summary: x86 interpreter and c1 type profiling for arguments at calls > > (3) http://cr.openjdk.java.net/~roland/8026054/ > Summary: x86 interpreter and c1 type profiling for return values at calls > > > Miguel > > From miguelalfredo.garcia at epfl.ch Thu Mar 6 12:01:10 2014 From: miguelalfredo.garcia at epfl.ch (Garcia Gutierrez Miguel Alfredo) Date: Thu, 6 Mar 2014 20:01:10 +0000 Subject: New type-profiling points in HotSpot, how to use them from Graal? In-Reply-To: <79370FE9-EFD4-46EE-B0E3-A112CA6C564C@oracle.com> References: <7E4228B446372948BBB2916FC53FA49E26E56C06@REXMD.intranet.epfl.ch>, <79370FE9-EFD4-46EE-B0E3-A112CA6C564C@oracle.com> Message-ID: <7E4228B446372948BBB2916FC53FA49E26E57DE0@REXMD.intranet.epfl.ch> >> It would be great to hear more about that (recently added) functionality in HotSpot. > What would you like to hear? Any kind of context on the problem would be of help, e.g. what code needs to be changed in Graal. Miguel -- Miguel Garcia Swiss Federal Institute of Technology EPFL - IC - LAMP1 - INR 328 - Station 14 CH-1015 Lausanne - Switzerland http://lamp.epfl.ch/~magarcia/ ________________________________________ From: Christian Thalinger [christian.thalinger at oracle.com] Sent: Thursday, March 06, 2014 8:17 PM To: Garcia Gutierrez Miguel Alfredo Cc: graal-dev at openjdk.java.net; Roland Westrelin Subject: Re: New type-profiling points in HotSpot, how to use them from Graal? On Mar 5, 2014, at 8:12 AM, Garcia Gutierrez Miguel Alfredo wrote: > > Hi, > > It would be great to hear more about that (recently added) functionality in HotSpot. What would you like to hear? > > My goal is to have Graal exploit that information. > > The pointers I'm aware about: > > (1) http://openjdk.5641.n7.nabble.com/RFR-L-8026054-New-type-profiling-points-type-of-return-values-at-calls-td159355.html > > (2) http://cr.openjdk.java.net/~roland/8023657/ > Summary: x86 interpreter and c1 type profiling for arguments at calls > > (3) http://cr.openjdk.java.net/~roland/8026054/ > Summary: x86 interpreter and c1 type profiling for return values at calls > > > Miguel > > From tom.deneau at amd.com Thu Mar 6 12:21:07 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 6 Mar 2014 20:21:07 +0000 Subject: replacing nodes with DeoptimizeNodes In-Reply-To: References: <9D3E175A-2980-48FA-A62F-B16F7C613558@oracle.com> Message-ID: OK, and if I get an error like lowering of NodeA produced lowerable NodeB that should have been recursively lowered as it introduces these new nodes: [171|Deopt] does that mean I have to write my own lowering for NodeA which as part of that also lowers the replacement nodeB? -- Tom > -----Original Message----- > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > Gilles Duboscq > Sent: Wednesday, March 05, 2014 4:29 AM > To: Doug Simon > Cc: Deneau, Tom; graal-dev at openjdk.java.net > Subject: Re: replacing nodes with DeoptimizeNodes > > On Wed, Mar 5, 2014 at 11:18 AM, Doug Simon > wrote: > > > > On Mar 5, 2014, at 1:27 AM, Deneau, Tom wrote: > > > >> Let's say there is some random graal node that you choose not to > implement so you want it to be replaced by a DeoptimizeNode. How does > one do that if the original node is not a terminal node, ie, it has > usages? > > > > The subgraph rooted at that node has to be removed (probably through > use of > com.oracle.graal.nodes.util.GraphUtil.killWithUnusedFloatingInputs(Node) > ). > > Rather GraphUtil.killCFG(Node). > As an example, you can look at CanonicalizerPhase.performReplacement > (around line 297): > //case 7 > fixed.predecessor().replaceFirstSuccessor(fixed, canonical); > GraphUtil.killCFG(fixed); > > even better would be: > fixed.replaceAtPredecessor(canonical); > GraphUtil.killCFG(fixed); > > where in you case fixed is the node you want to replace and canonical is > the DeoptimizeNode. > > > > > -Doug From tom.rodriguez at oracle.com Thu Mar 6 15:17:17 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 6 Mar 2014 15:17:17 -0800 Subject: replacing nodes with DeoptimizeNodes In-Reply-To: References: <9D3E175A-2980-48FA-A62F-B16F7C613558@oracle.com> Message-ID: <5353D462-A043-41A1-B58C-8EBB763E67FE@oracle.com> On Mar 6, 2014, at 12:21 PM, Deneau, Tom wrote: > OK, and if I get an error like > lowering of NodeA produced lowerable NodeB that should have been > recursively lowered as it introduces these new nodes: [171|Deopt] > > does that mean I have to write my own lowering for NodeA which as part of that also lowers the replacement nodeB? Generally any lowering phase is required to finish in a single pass, so if you?re lowering is doing anything tricky that introduces Lowerable nodes than you need to manually lower them, usually by running your own LoweringPhase. When are you getting this message? MacroNodes do this for instance. Is this happening as a result of your conversion of a node into a Deopt node? Are you trying to do that during lowering? tom > > -- Tom > >> -----Original Message----- >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of >> Gilles Duboscq >> Sent: Wednesday, March 05, 2014 4:29 AM >> To: Doug Simon >> Cc: Deneau, Tom; graal-dev at openjdk.java.net >> Subject: Re: replacing nodes with DeoptimizeNodes >> >> On Wed, Mar 5, 2014 at 11:18 AM, Doug Simon >> wrote: >>> >>> On Mar 5, 2014, at 1:27 AM, Deneau, Tom wrote: >>> >>>> Let's say there is some random graal node that you choose not to >> implement so you want it to be replaced by a DeoptimizeNode. How does >> one do that if the original node is not a terminal node, ie, it has >> usages? >>> >>> The subgraph rooted at that node has to be removed (probably through >> use of >> com.oracle.graal.nodes.util.GraphUtil.killWithUnusedFloatingInputs(Node) >> ). >> >> Rather GraphUtil.killCFG(Node). >> As an example, you can look at CanonicalizerPhase.performReplacement >> (around line 297): >> //case 7 >> fixed.predecessor().replaceFirstSuccessor(fixed, canonical); >> GraphUtil.killCFG(fixed); >> >> even better would be: >> fixed.replaceAtPredecessor(canonical); >> GraphUtil.killCFG(fixed); >> >> where in you case fixed is the node you want to replace and canonical is >> the DeoptimizeNode. >> >>> >>> -Doug > From tom.deneau at amd.com Thu Mar 6 15:25:48 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 6 Mar 2014 23:25:48 +0000 Subject: replacing nodes with DeoptimizeNodes In-Reply-To: <5353D462-A043-41A1-B58C-8EBB763E67FE@oracle.com> References: <9D3E175A-2980-48FA-A62F-B16F7C613558@oracle.com> <5353D462-A043-41A1-B58C-8EBB763E67FE@oracle.com> Message-ID: Yes, it's happening as a result of my conversion of a node into a Deopt node? Which I was trying to do during lowering. Maybe that's the wrong place to do it? -- Tom > -----Original Message----- > From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > Sent: Thursday, March 06, 2014 5:17 PM > To: Deneau, Tom > Cc: Gilles Duboscq; Douglas Simon; graal-dev at openjdk.java.net > Subject: Re: replacing nodes with DeoptimizeNodes > > > On Mar 6, 2014, at 12:21 PM, Deneau, Tom wrote: > > > OK, and if I get an error like > > lowering of NodeA produced lowerable NodeB that should have been > > recursively lowered as it introduces these new nodes: [171|Deopt] > > > > does that mean I have to write my own lowering for NodeA which as part > of that also lowers the replacement nodeB? > > Generally any lowering phase is required to finish in a single pass, so > if you're lowering is doing anything tricky that introduces Lowerable > nodes than you need to manually lower them, usually by running your own > LoweringPhase. When are you getting this message? MacroNodes do this > for instance. > > Is this happening as a result of your conversion of a node into a Deopt > node? Are you trying to do that during lowering? > > tom > > > > > -- Tom > > > >> -----Original Message----- > >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > >> Gilles Duboscq > >> Sent: Wednesday, March 05, 2014 4:29 AM > >> To: Doug Simon > >> Cc: Deneau, Tom; graal-dev at openjdk.java.net > >> Subject: Re: replacing nodes with DeoptimizeNodes > >> > >> On Wed, Mar 5, 2014 at 11:18 AM, Doug Simon > >> wrote: > >>> > >>> On Mar 5, 2014, at 1:27 AM, Deneau, Tom wrote: > >>> > >>>> Let's say there is some random graal node that you choose not to > >> implement so you want it to be replaced by a DeoptimizeNode. How > >> does one do that if the original node is not a terminal node, ie, it > >> has usages? > >>> > >>> The subgraph rooted at that node has to be removed (probably through > >> use of > >> com.oracle.graal.nodes.util.GraphUtil.killWithUnusedFloatingInputs(No > >> de) > >> ). > >> > >> Rather GraphUtil.killCFG(Node). > >> As an example, you can look at CanonicalizerPhase.performReplacement > >> (around line 297): > >> //case 7 > >> fixed.predecessor().replaceFirstSuccessor(fixed, canonical); > >> GraphUtil.killCFG(fixed); > >> > >> even better would be: > >> fixed.replaceAtPredecessor(canonical); > >> GraphUtil.killCFG(fixed); > >> > >> where in you case fixed is the node you want to replace and canonical > >> is the DeoptimizeNode. > >> > >>> > >>> -Doug > > > From tom.rodriguez at oracle.com Thu Mar 6 15:28:20 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 6 Mar 2014 15:28:20 -0800 Subject: replacing nodes with DeoptimizeNodes In-Reply-To: References: <9D3E175A-2980-48FA-A62F-B16F7C613558@oracle.com> <5353D462-A043-41A1-B58C-8EBB763E67FE@oracle.com> Message-ID: <07E666C4-0991-4A03-B971-48EAD8F5DBC2@oracle.com> It?s probably not the best place to do it, though it could be made to work. What kinds of operations are you converting into deopts? tom On Mar 6, 2014, at 3:25 PM, Deneau, Tom wrote: > Yes, it's happening as a result of my conversion of a node into a Deopt > node? Which I was trying to do during lowering. Maybe that's the wrong place to do it? > > -- Tom > >> -----Original Message----- >> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] >> Sent: Thursday, March 06, 2014 5:17 PM >> To: Deneau, Tom >> Cc: Gilles Duboscq; Douglas Simon; graal-dev at openjdk.java.net >> Subject: Re: replacing nodes with DeoptimizeNodes >> >> >> On Mar 6, 2014, at 12:21 PM, Deneau, Tom wrote: >> >>> OK, and if I get an error like >>> lowering of NodeA produced lowerable NodeB that should have been >>> recursively lowered as it introduces these new nodes: [171|Deopt] >>> >>> does that mean I have to write my own lowering for NodeA which as part >> of that also lowers the replacement nodeB? >> >> Generally any lowering phase is required to finish in a single pass, so >> if you're lowering is doing anything tricky that introduces Lowerable >> nodes than you need to manually lower them, usually by running your own >> LoweringPhase. When are you getting this message? MacroNodes do this >> for instance. >> >> Is this happening as a result of your conversion of a node into a Deopt >> node? Are you trying to do that during lowering? >> >> tom >> >>> >>> -- Tom >>> >>>> -----Original Message----- >>>> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of >>>> Gilles Duboscq >>>> Sent: Wednesday, March 05, 2014 4:29 AM >>>> To: Doug Simon >>>> Cc: Deneau, Tom; graal-dev at openjdk.java.net >>>> Subject: Re: replacing nodes with DeoptimizeNodes >>>> >>>> On Wed, Mar 5, 2014 at 11:18 AM, Doug Simon >>>> wrote: >>>>> >>>>> On Mar 5, 2014, at 1:27 AM, Deneau, Tom wrote: >>>>> >>>>>> Let's say there is some random graal node that you choose not to >>>> implement so you want it to be replaced by a DeoptimizeNode. How >>>> does one do that if the original node is not a terminal node, ie, it >>>> has usages? >>>>> >>>>> The subgraph rooted at that node has to be removed (probably through >>>> use of >>>> com.oracle.graal.nodes.util.GraphUtil.killWithUnusedFloatingInputs(No >>>> de) >>>> ). >>>> >>>> Rather GraphUtil.killCFG(Node). >>>> As an example, you can look at CanonicalizerPhase.performReplacement >>>> (around line 297): >>>> //case 7 >>>> fixed.predecessor().replaceFirstSuccessor(fixed, canonical); >>>> GraphUtil.killCFG(fixed); >>>> >>>> even better would be: >>>> fixed.replaceAtPredecessor(canonical); >>>> GraphUtil.killCFG(fixed); >>>> >>>> where in you case fixed is the node you want to replace and canonical >>>> is the DeoptimizeNode. >>>> >>>>> >>>>> -Doug >>> >> > > From tom.deneau at amd.com Thu Mar 6 15:30:20 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 6 Mar 2014 23:30:20 +0000 Subject: suspcions about GC and HSAIL Deopt Message-ID: While preparing this webrev for the hsail deoptimization work we've been doing, I noticed some spurious failures when we run on HSA hardware. I have a theory of what's happening, let me know if this makes sense... First the big overview: When we run a kernel, and it returns from the GPU each workitem can be in one of 3 states: a) finished normally b) deopted and saved its state (and set the deopt-happened flag) c) on entry, saw deopt-happened=true and so just exited early without running. This last one exists because we don't want to have to allocate enough deopt save space so that each workitem has its own unique save space. Instead we only allocate enough for the number of concurrent workitems possible. When we return from the GPU, if one or more workitems deopted we: a) for the workitems that finished normally, there is nothing to do b) for each deopted workitems, we want to run it thru the interpreter going first thru the special host trampoline code infrastructure that Gilles created. The trampoline host code takes a deoptId (sort of like a pc, telling where the deopt occurred in the hsail code) and a pointer to the saved hsail frame. We currently do this sequentially although other policies are possible. c) for each never ran workitem, we can just run it from the beginning of the kernel "method", just making sure we pass the arguments and the appropriate workitem id for each one. Again, we currently do this sequentially although other policies are possible. When we enter the JVM to run the kernel, we transition to thread_in_vm mode. So while running on the GPU, no oops are moving (although of course GCs may be delayed). When we start looking for workitems of type b or c above, we are still in thread_in_vm mode. However since both b and c above use the javaCall infrastructure, I believe they are transitioning to thread_in_java mode on each call, and oops can move. So if for instance there are two deopting workitems, it is possible that after executing the first one that the saved deopt state for the second one is no longer valid. The junit tests on which I have seen the spurious failures are ones where lots of workitems deopt. When run in the hotspot debug build, we usually see SEGVs in interpreter code and the access is always to 0xbaadbabe. Note that when Gilles was developing his infrastructure, the only test cases we had all had a single workitem deopting so would not show this. Also even with multi-deopting test cases, I believe the reason we don't see this on the simulator is that the concurrency is much less there so the number of workitems of type b) above will be much less. On hardware, we can have thousands of workitems deopting. I suppose the solution to this is to mark any oops in the deopt saved state in some way that GC can find them and fix them. What is the best way to do this? Or is there any way to execute javaCalls from thread_in_vm mode without allowing GCs to happen? -- Tom From tom.deneau at amd.com Thu Mar 6 15:32:43 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 6 Mar 2014 23:32:43 +0000 Subject: replacing nodes with DeoptimizeNodes In-Reply-To: <07E666C4-0991-4A03-B971-48EAD8F5DBC2@oracle.com> References: <9D3E175A-2980-48FA-A62F-B16F7C613558@oracle.com> <5353D462-A043-41A1-B58C-8EBB763E67FE@oracle.com> <07E666C4-0991-4A03-B971-48EAD8F5DBC2@oracle.com> Message-ID: Just playing around, wanted to see what would happen if I made all NewInstance nodes deopt. In reality we would handle fastpath and medium slow path allocations thru hsail and only deopt if say we could not get a new tlab, etc. -- Tom > -----Original Message----- > From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > Sent: Thursday, March 06, 2014 5:28 PM > To: Deneau, Tom > Cc: Gilles Duboscq; Douglas Simon; graal-dev at openjdk.java.net > Subject: Re: replacing nodes with DeoptimizeNodes > > It's probably not the best place to do it, though it could be made to > work. What kinds of operations are you converting into deopts? > > tom > > On Mar 6, 2014, at 3:25 PM, Deneau, Tom wrote: > > > Yes, it's happening as a result of my conversion of a node into a > > Deopt node? Which I was trying to do during lowering. Maybe that's > the wrong place to do it? > > > > -- Tom > > > >> -----Original Message----- > >> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > >> Sent: Thursday, March 06, 2014 5:17 PM > >> To: Deneau, Tom > >> Cc: Gilles Duboscq; Douglas Simon; graal-dev at openjdk.java.net > >> Subject: Re: replacing nodes with DeoptimizeNodes > >> > >> > >> On Mar 6, 2014, at 12:21 PM, Deneau, Tom wrote: > >> > >>> OK, and if I get an error like > >>> lowering of NodeA produced lowerable NodeB that should have been > >>> recursively lowered as it introduces these new nodes: [171|Deopt] > >>> > >>> does that mean I have to write my own lowering for NodeA which as > >>> part > >> of that also lowers the replacement nodeB? > >> > >> Generally any lowering phase is required to finish in a single pass, > >> so if you're lowering is doing anything tricky that introduces > >> Lowerable nodes than you need to manually lower them, usually by > >> running your own LoweringPhase. When are you getting this message? > >> MacroNodes do this for instance. > >> > >> Is this happening as a result of your conversion of a node into a > >> Deopt node? Are you trying to do that during lowering? > >> > >> tom > >> > >>> > >>> -- Tom > >>> > >>>> -----Original Message----- > >>>> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > >>>> Gilles Duboscq > >>>> Sent: Wednesday, March 05, 2014 4:29 AM > >>>> To: Doug Simon > >>>> Cc: Deneau, Tom; graal-dev at openjdk.java.net > >>>> Subject: Re: replacing nodes with DeoptimizeNodes > >>>> > >>>> On Wed, Mar 5, 2014 at 11:18 AM, Doug Simon > >>>> wrote: > >>>>> > >>>>> On Mar 5, 2014, at 1:27 AM, Deneau, Tom > wrote: > >>>>> > >>>>>> Let's say there is some random graal node that you choose not to > >>>> implement so you want it to be replaced by a DeoptimizeNode. How > >>>> does one do that if the original node is not a terminal node, ie, > >>>> it has usages? > >>>>> > >>>>> The subgraph rooted at that node has to be removed (probably > >>>>> through > >>>> use of > >>>> com.oracle.graal.nodes.util.GraphUtil.killWithUnusedFloatingInputs( > >>>> No > >>>> de) > >>>> ). > >>>> > >>>> Rather GraphUtil.killCFG(Node). > >>>> As an example, you can look at > >>>> CanonicalizerPhase.performReplacement > >>>> (around line 297): > >>>> //case 7 > >>>> fixed.predecessor().replaceFirstSuccessor(fixed, canonical); > >>>> GraphUtil.killCFG(fixed); > >>>> > >>>> even better would be: > >>>> fixed.replaceAtPredecessor(canonical); > >>>> GraphUtil.killCFG(fixed); > >>>> > >>>> where in you case fixed is the node you want to replace and > >>>> canonical is the DeoptimizeNode. > >>>> > >>>>> > >>>>> -Doug > >>> > >> > > > > > From doug.simon at oracle.com Thu Mar 6 18:01:21 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 07 Mar 2014 02:01:21 +0000 Subject: hg: graal/graal: 17 new changesets Message-ID: <20140307020318.1CAA4625C0@hg.openjdk.java.net> Changeset: 40fac3ef157d Author: Tom Rodriguez Date: 2014-03-05 21:13 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/40fac3ef157d fix queue code ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: af84c0b2e74f Author: Roland Schatz Date: 2014-03-06 10:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/af84c0b2e74f Don't remove UnboxNode if the incoming type is wrong. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnboxNode.java Changeset: b6c6a18b2232 Author: Roland Schatz Date: 2014-03-06 13:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b6c6a18b2232 Verify existence of constructor for @NodeIntrinsic methods. + graal/com.oracle.graal.replacements.verifier/src/com/oracle/graal/replacements/verifier/NodeIntrinsicVerifier.java ! graal/com.oracle.graal.replacements.verifier/src/com/oracle/graal/replacements/verifier/VerifierAnnotationProcessor.java ! mx/projects Changeset: ce79de7da9ab Author: Andreas Woess Date: 2014-03-04 12:59 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ce79de7da9ab remove assertion in UnexpectedResultException constructor ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/UnexpectedResultException.java Changeset: dd2c23065f47 Author: Andreas Woess Date: 2014-03-06 16:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/dd2c23065f47 Truffle: remove call node notification loop (O(n^2)) ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/RootNode.java Changeset: 280332c0180e Author: Doug Simon Date: 2014-03-06 17:26 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/280332c0180e removed unnecessary explicit cast by tightening return type of overloaded method ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ReflectionGetCallerClassNode.java Changeset: 98e0e315d727 Author: Doug Simon Date: 2014-03-06 17:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/98e0e315d727 removed java.lang.Class fields in HotSpotResolvedPrimitiveType ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedPrimitiveType.java Changeset: ed92bc6900d5 Author: Doug Simon Date: 2014-03-06 17:46 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ed92bc6900d5 simplified HotSpotResolvedObjectType.FieldInfo.getType(); encapsulated all access to javaClass in HotSpotResolvedObjectType more ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java Changeset: 13072c084e6f Author: Bernhard Urban Date: 2014-03-06 23:17 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/13072c084e6f TruffleCompiler: avoid interleaved output with application and compiler ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java Changeset: dd783f0ecf17 Author: twisti Date: 2014-03-06 15:18 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/dd783f0ecf17 refactor CompilerToVM interface ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotConstantPool.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodUnresolved.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotUnresolvedField.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotUnresolvedJavaType.java ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalCompiler.hpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalCompilerToVM.hpp ! src/share/vm/graal/vmStructs_graal.hpp Changeset: 3f27e57439ed Author: Michael Van De Vanter Date: 2014-02-03 20:58 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/3f27e57439ed Truffle/Instrumentation: significant rearrangement (including moved class) and extension of the Truffle Instrumentation Framework. New interfaces include DebugContext (which can be attached to the ExecutionContext), through which access is provided to possibly language-specific (a) node instrumentation, (b) debug services manager, (c) notification when programs halt, (d) display of language values, and (e) display of variable identifiers. - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/ASTPrinter.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/DebugManager.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/ExecutionContext.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/debug/ASTPrinter.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/debug/DebugContext.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/debug/DebugManager.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/debug/DefaultDebugManager.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/debug/KillException.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/debug/QuitException.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultDebugManager.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/instrument/DefaultNodeInstrumenter.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/instrument/InstrumentationProbeNode.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/instrument/NodeInstrumenter.java ! graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/RubyNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/RubyASTPrinter.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/debug/RubyProxyNode.java + graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/instrument/DefaultRubyNodeInstrumenter.java + graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/instrument/RubyASTPrinter.java + graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/instrument/RubyNodeInstrumenter.java + graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/instrument/RubyProxyNode.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/DefaultRubyNodeInstrumenter.java ! graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/JRubyParser.java + graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/MinimumRubyDebugContext.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/RubyNodeInstrumenter.java ! graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/Translator.java ! graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/TranslatorEnvironment.java ! graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/RubyContext.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/BreakShellException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/QuitException.java ! graal/com.oracle.truffle.ruby.shell/src/com/oracle/truffle/ruby/shell/Shell.java ! graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/RubyTests.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLScript.java Changeset: cf16ff2dba69 Author: Michael Van De Vanter Date: 2014-02-04 11:17 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/cf16ff2dba69 Ruby/Instrumentation: class rename = graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/MinimalRubyDebugContext.java < graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/MinimumRubyDebugContext.java ! graal/com.oracle.truffle.ruby.shell/src/com/oracle/truffle/ruby/shell/Shell.java ! graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/RubyTests.java Changeset: d0e82d536325 Author: Michael Van De Vanter Date: 2014-02-23 17:00 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/d0e82d536325 Ruby/Instrumentation: renaming/API rearrangements - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/instrument/DefaultRubyNodeInstrumenter.java + graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/instrument/MinimalRubyNodeInstrumenter.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/instrument/RubyASTPrinter.java ! graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/MinimalRubyDebugContext.java Changeset: a124cc76cde9 Author: Michael Van De Vanter Date: 2014-03-05 19:40 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/a124cc76cde9 Merge with 1b84e499127b0086271898a1298577d15e0b3101 - GRAAL_AUTHORS - README - README_GRAAL.txt - graal/com.oracle.graal.asm/src/com/oracle/graal/asm/AbstractAssembler.java - graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/PTXPhase.java - graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILCompilationResult.java - graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotSuitesProvider.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotRuntimeInterpreterInterface.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/stubs/GraphKit.java - graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64CharArrayEqualsOp.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/CharArrayEqualsNode.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleInlining.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleInliningImpl.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/DefaultCallTargetSubstitutions.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/FrameFactory.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/InlinableCallSite.java - graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/InlinedCallSite.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/instrument/InstrumentationProbeNode.java - graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/api/ExtensionProcessor.java - graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeTreeVariable.java - graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/SpecializationListenerData.java - graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/JavaName.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/CoreSource.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/CoreSourceSection.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/DefinedNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/InlinableMethodImplementation.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/ReadNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/RubyNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/RubyRootNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/RubyTypes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/WriteNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/BooleanDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/BoxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/BoxingDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/CachedBoxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/CachedUnboxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/CallNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/DispatchHeadNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/DispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/GeneralBoxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/GeneralSuperCallNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/InlineHeuristic.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/InlinedBoxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/InlinedUnboxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/ProcOrNullNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/UnboxedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/UninitializedBoxingDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/call/UninitializedDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/cast/BooleanCastNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/cast/LambdaNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/cast/ProcCastNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/cast/SplatCastNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/cast/StringToRegexpNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/cast/StringToSymbolNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/constants/CachedReadConstantNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/constants/ReadConstantNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/constants/UninitializedReadConstantNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/constants/WriteConstantNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/AndNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/BreakNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/ElidableResultNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/EnsureNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/FlipFlopNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/IfNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/NextNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/NotNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/OrNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/RedoNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/RescueAnyNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/RescueClassesNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/RescueNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/RescueSplatNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/RetryNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/ReturnNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/SequenceNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/TryNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/control/WhileNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ArrayConcatNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ArrayCoreMethodNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ArrayIndexNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ArrayNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ArrayPushNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ArrayRestNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/BasicObjectNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/BignumNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ClassNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ComparableNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ContinuationNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/CoreClass.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/CoreMethod.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/CoreMethodNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/CoreMethodNodeManager.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/DirNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ExceptionNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/FalseClassNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/FiberNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/FileNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/FixnumNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/FloatNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/HashNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/InterpolatedStringNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/KernelNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/MainNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/MatchDataNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/MathNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ModuleNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/NilClassNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ObjectNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ObjectSpaceNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ProcNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ProcessNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/RangeNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/RegexpNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/SignalNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/StringNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/StructNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/SymbolNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/SystemNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/ThreadNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/TimeNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/TrueClassNodes.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/core/YieldingCoreMethodNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/instrument/MinimalRubyNodeInstrumenter.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/instrument/RubyNodeInstrumenter.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/instrument/RubyProxyNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/BignumLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/BooleanLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/FixnumLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/FloatLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/HashLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/NilNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/ObjectLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/RangeLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/StringLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/array/ArrayLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/array/FixnumArrayLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/array/ObjectArrayLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/literal/array/UninitialisedArrayLiteralNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/AddMethodNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/AliasNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/BlockDefinitionNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/CatchNextNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/CatchReturnAsErrorNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/CatchReturnNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/MethodDefinitionNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/ShellResultNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/BlockDestructureSwitchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/CheckArityNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadAllArgumentsNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadBlockArgumentNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadDestructureArgumentNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadOptionalArgumentNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadPostArgumentNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadPreArgumentNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/arguments/ReadRestArgumentNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/FlipFlopStateNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/FrameSlotNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/InitFlipFlopSlotNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/LevelFlipFlopStateNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/LocalFlipFlopStateNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/ReadLevelVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/ReadLocalVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/WriteLevelVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/methods/locals/WriteLocalVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/ClassNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/DefineOrGetClassNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/DefineOrGetModuleNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/OpenModuleNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/ReadClassVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/SelfNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/SingletonClassNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/WriteClassVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/ReadFixnumInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/ReadFloatInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/ReadInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/ReadMissingInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/ReadObjectInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/ReadSpecializedInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/UninitializedReadInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/UninitializedWriteInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/WriteFixnumInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/WriteFloatInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/WriteInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/WriteObjectInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/objects/instancevariables/WriteSpecializedInstanceVariableNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/yield/GeneralYieldDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/yield/InlinedYieldDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/yield/UninitializedYieldDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/yield/YieldDispatchNode.java - graal/com.oracle.truffle.ruby.nodes/src/com/oracle/truffle/ruby/nodes/yield/YieldNode.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/DeadNode.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/JRubyParser.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/MethodTranslator.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/ModuleTranslator.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/RubyFrameTypeConversion.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/Translator.java - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/TranslatorEnvironment.java - graal/com.oracle.truffle.ruby.runtime/.checkstyle_checks.xml - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/InputReader.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/NilPlaceholder.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/RubyArguments.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/RubyContext.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/RubyParser.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/RubyParserResult.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/ShellResult.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/UndefinedPlaceholder.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/configuration/Configuration.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/configuration/ConfigurationBuilder.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/BreakException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/ContinuationReturnException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/ExceptionTranslator.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/NextException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/RaiseException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/RedoException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/RetryException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/ReturnException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/control/ThrowException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/CoreLibrary.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/GeneralConversions.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyBignum.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyBinding.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyClass.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyContinuation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyFalseClass.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyFiber.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyFile.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyFixnum.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyFloat.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyHash.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyMatchData.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyModule.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyNilClass.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyObject.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyProc.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyRegexp.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyString.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubySymbol.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyThread.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyTime.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/RubyTrueClass.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/StringFormatter.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/ArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/ArrayUtilities.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/BaseArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/EmptyArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/FixnumArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/FixnumImmutablePairArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/GeneraliseArrayStoreException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/ObjectArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/ObjectImmutablePairArrayStore.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/array/RubyArray.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/range/FixnumRange.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/range/ObjectRange.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/core/range/RubyRange.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/debug/RubyProbe.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/debug/RubyTraceProbe.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/lookup/LookupFork.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/lookup/LookupNode.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/lookup/LookupTerminal.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/methods/Arity.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/methods/CallTargetMethodImplementation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/methods/MethodImplementation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/methods/RubyMethod.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/methods/UniqueMethodIdentifier.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/methods/Visibility.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/FixnumStorageLocation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/FloatStorageLocation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/GeneralizeStorageLocationException.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/ObjectLayout.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/ObjectStorageLocation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/PrimitiveStorageLocation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/RubyBasicObject.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/StorageLocation.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/objects/Unboxable.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/subsystems/AtExitManager.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/subsystems/FeatureManager.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/subsystems/FiberManager.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/subsystems/ObjectSpaceManager.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/subsystems/ThreadManager.java - graal/com.oracle.truffle.ruby.runtime/src/com/oracle/truffle/ruby/runtime/subsystems/TraceManager.java - graal/com.oracle.truffle.ruby.shell/src/com/oracle/truffle/ruby/shell/CommandLineOptions.java - graal/com.oracle.truffle.ruby.shell/src/com/oracle/truffle/ruby/shell/CommandLineParser.java - graal/com.oracle.truffle.ruby.shell/src/com/oracle/truffle/ruby/shell/Shell.java - graal/com.oracle.truffle.ruby.test/specs/README - graal/com.oracle.truffle.ruby.test/specs/rubytruffle - graal/com.oracle.truffle.ruby.test/specs/rubytruffle.mspec - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_a_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_d_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_e_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_n_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_p_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_r_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_s_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_upper_e_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_upper_f_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_upper_i_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_upper_u_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_upper_w_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_v_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_w_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/dash_x_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/command_line/error_message_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/BEGIN_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/alias_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/array_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/block_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/break_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/case_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/class_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/class_variable_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/constants_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/def_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/defined_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/encoding_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/ensure_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/execution_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/file_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/for_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/hash_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/line_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/literal_lambda_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/magic_comment_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/match_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/metaclass_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/module_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/next_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/precedence_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/predefined/data_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/predefined_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/private_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/proc_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/redo_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/anchors_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/back-references_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/character_classes_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/encoding_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/escapes_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/grouping_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/interpolation_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/modifiers_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp/repetition_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/regexp_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/rescue_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/retry_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/return_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/send_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/singleton_class_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/splat_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/string_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/super_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/symbol_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/throw_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/undef_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/until_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/variables_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/while_tags.txt - graal/com.oracle.truffle.ruby.test/specs/tags/language/yield_tags.txt - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/RubyTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ArrayTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/BignumTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/BoolTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ContinuationTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/FiberTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/FixnumTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/FloatTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/HashTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/IntegerTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/KernelTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/MathTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ModuleTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ObjectSpaceTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ObjectTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ProcTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/RangeTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/RegexpTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/StringTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/SymbolTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/core/ThreadTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/AndTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/BlockTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/CaseTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/ClassLocalTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/ClassTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/ConstantTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/ForTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/GlobalVariableTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/IfTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/InterpolatedStringTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/LocalTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/MethodTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/ModuleTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/MultipleAssignmentTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/OrTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/PolymorphismTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/RaiseRescueTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/RedefinitionTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/ShortcutTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/SpecialVariableTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/UntilTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/language/WhileTests.java - graal/com.oracle.truffle.ruby.test/src/com/oracle/truffle/ruby/test/runtime/ObjectLayoutTests.java - graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/AbstractTest.java - graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/AddTest.java - graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/BuiltinsTest.java - graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/CallTest.java - graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/ComparisonTest.java - graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/DivTest.java - graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/FibonacciTest.java - graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/LoopPrintTest.java - graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/LoopTest.java - graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/MulTest.java - graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/SplitOutputStream.java - graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/SubTest.java - graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/SumTest.java - graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/TernaryTest.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLNodeFactory.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLScript.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLTypes.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SimpleLanguage.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/BuiltinNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/DefaultBuiltins.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/PrintBuiltin.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/builtins/TimeBuiltin.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ArgumentsNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ArithmeticNode.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/BinaryNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/BlockNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/BreakException.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/BreakNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/CallNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ConditionNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ContinueException.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ContinueNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/FrameSlotNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/FunctionBodyNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/FunctionRootNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/IfNode.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/LessThanNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/LogicalAndNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/NullLiteralNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ReadArgumentNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ReadFunctionNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ReadLocalNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ReadUninitializedNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ReturnException.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ReturnNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/StatementNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/StringLiteralNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/TernaryNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/TypedNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/WhileNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/WriteLocalNode.java - graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/ParserUtils.java - src/gpu/ptx/vm/ptxKernelArguments.cpp - src/gpu/ptx/vm/ptxKernelArguments.hpp - src/os_gpu/bsd_ptx/vm/gpu_bsd.cpp - src/os_gpu/bsd_ptx/vm/gpu_bsd.hpp - src/os_gpu/linux_ptx/vm/gpu_linux.cpp - src/os_gpu/linux_ptx/vm/gpu_linux.hpp - src/os_gpu/windows_hsail/vm/gpu_windows.cpp - src/os_gpu/windows_hsail/vm/gpu_windows.hpp - src/share/vm/graal/graalCompilerToGPU.cpp - src/share/vm/graal/graalCompilerToGPU.hpp Changeset: e7f611868ffb Author: Michael Van De Vanter Date: 2014-03-05 19:54 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e7f611868ffb merge - graal/com.oracle.truffle.ruby.parser/src/com/oracle/truffle/ruby/parser/MinimalRubyDebugContext.java Changeset: 34efe38ee8d8 Author: Michael Van De Vanter Date: 2014-03-06 15:56 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/34efe38ee8d8 Merge with 13072c084e6f8f4a402827c0a541c54938537041 Changeset: 8c376c174030 Author: Michael Van De Vanter Date: 2014-03-06 16:24 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/8c376c174030 Merge with dd783f0ecf171f786674bb5b6b762581c3367f80 From doug.simon at oracle.com Fri Mar 7 02:26:49 2014 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 7 Mar 2014 11:26:49 +0100 Subject: suspcions about GC and HSAIL Deopt In-Reply-To: References: Message-ID: <661FF05A-0F67-43EE-9281-85C1BA875994@oracle.com> On Mar 7, 2014, at 12:30 AM, Deneau, Tom wrote: > While preparing this webrev for the hsail deoptimization work we've been doing, I noticed some spurious failures when we run on HSA hardware. I have a theory of what's happening, let me know if this makes sense... > > First the big overview: > > When we run a kernel, and it returns from the GPU each workitem can be in one of 3 states: > > a) finished normally > b) deopted and saved its state (and set the deopt-happened flag) > c) on entry, saw deopt-happened=true and so just exited early > without running. > > This last one exists because we don't want to have to allocate enough deopt save space so that each workitem has its own unique save space. > Instead we only allocate enough for the number of concurrent workitems possible. > > When we return from the GPU, if one or more workitems deopted we: > > a) for the workitems that finished normally, there is nothing to do > > b) for each deopted workitems, we want to run it thru the > interpreter going first thru the special host trampoline code > infrastructure that Gilles created. The trampoline host code > takes a deoptId (sort of like a pc, telling where the deopt > occurred in the hsail code) and a pointer to the saved hsail > frame. We currently do this sequentially although other > policies are possible. > > c) for each never ran workitem, we can just run it from the > beginning of the kernel "method", just making sure we pass the > arguments and the appropriate workitem id for each one. Again, > we currently do this sequentially although other policies are > possible. > > When we enter the JVM to run the kernel, we transition to thread_in_vm mode. So while running on the GPU, no oops are moving (although of course GCs may be delayed). > > When we start looking for workitems of type b or c above, we are still in thread_in_vm mode. However since both b and c above use the javaCall infrastructure, I believe they are transitioning to thread_in_java mode on each call, and oops can move. > > So if for instance there are two deopting workitems, it is possible that after executing the first one that the saved deopt state for the second one is no longer valid. > > The junit tests on which I have seen the spurious failures are ones where lots of workitems deopt. When run in the hotspot debug build, we usually see SEGVs in interpreter code and the access is always to 0xbaadbabe. > > Note that when Gilles was developing his infrastructure, the only test cases we had all had a single workitem deopting so would not show this. Also even with multi-deopting test cases, I believe the reason we don't see this on the simulator is that the concurrency is much less there so the number of workitems of type b) above will be much less. On hardware, we can have thousands of workitems deopting. > > I suppose the solution to this is to mark any oops in the deopt saved state in some way that GC can find them and fix them. What is the best way to do this? I?m not sure it?s the most optimal solution, but around each javaCall, you could convert each saved oop to a Handle and convert it back after the call. I?m not aware of other mechanisms in HotSpot for registering GC roots but that doesn?t mean they don?t exist. > Or is there any way to execute javaCalls from thread_in_vm mode without allowing GCs to happen? You are calling arbitrary Java code right? That means you cannot guarantee allocation won?t be performed which in turn means you cannot disable GC (even though there are mechanisms for doing so like GC_locker::lock_critical/GC_locker::unlock_critical). -Doug From doug.simon at oracle.com Fri Mar 7 02:28:05 2014 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 7 Mar 2014 11:28:05 +0100 Subject: replacing nodes with DeoptimizeNodes In-Reply-To: <07E666C4-0991-4A03-B971-48EAD8F5DBC2@oracle.com> References: <9D3E175A-2980-48FA-A62F-B16F7C613558@oracle.com> <5353D462-A043-41A1-B58C-8EBB763E67FE@oracle.com> <07E666C4-0991-4A03-B971-48EAD8F5DBC2@oracle.com> Message-ID: <125B6999-7D0C-400C-9D36-3401FEF4617F@oracle.com> On Mar 7, 2014, at 12:28 AM, Tom Rodriguez wrote: > It?s probably not the best place to do it, though it could be made to work. I agree - you want to do this in a separate phase. > What kinds of operations are you converting into deopts? > > tom > > On Mar 6, 2014, at 3:25 PM, Deneau, Tom wrote: > >> Yes, it's happening as a result of my conversion of a node into a Deopt >> node? Which I was trying to do during lowering. Maybe that's the wrong place to do it? >> >> -- Tom >> >>> -----Original Message----- >>> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] >>> Sent: Thursday, March 06, 2014 5:17 PM >>> To: Deneau, Tom >>> Cc: Gilles Duboscq; Douglas Simon; graal-dev at openjdk.java.net >>> Subject: Re: replacing nodes with DeoptimizeNodes >>> >>> >>> On Mar 6, 2014, at 12:21 PM, Deneau, Tom wrote: >>> >>>> OK, and if I get an error like >>>> lowering of NodeA produced lowerable NodeB that should have been >>>> recursively lowered as it introduces these new nodes: [171|Deopt] >>>> >>>> does that mean I have to write my own lowering for NodeA which as part >>> of that also lowers the replacement nodeB? >>> >>> Generally any lowering phase is required to finish in a single pass, so >>> if you're lowering is doing anything tricky that introduces Lowerable >>> nodes than you need to manually lower them, usually by running your own >>> LoweringPhase. When are you getting this message? MacroNodes do this >>> for instance. >>> >>> Is this happening as a result of your conversion of a node into a Deopt >>> node? Are you trying to do that during lowering? >>> >>> tom >>> >>>> >>>> -- Tom >>>> >>>>> -----Original Message----- >>>>> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of >>>>> Gilles Duboscq >>>>> Sent: Wednesday, March 05, 2014 4:29 AM >>>>> To: Doug Simon >>>>> Cc: Deneau, Tom; graal-dev at openjdk.java.net >>>>> Subject: Re: replacing nodes with DeoptimizeNodes >>>>> >>>>> On Wed, Mar 5, 2014 at 11:18 AM, Doug Simon >>>>> wrote: >>>>>> >>>>>> On Mar 5, 2014, at 1:27 AM, Deneau, Tom wrote: >>>>>> >>>>>>> Let's say there is some random graal node that you choose not to >>>>> implement so you want it to be replaced by a DeoptimizeNode. How >>>>> does one do that if the original node is not a terminal node, ie, it >>>>> has usages? >>>>>> >>>>>> The subgraph rooted at that node has to be removed (probably through >>>>> use of >>>>> com.oracle.graal.nodes.util.GraphUtil.killWithUnusedFloatingInputs(No >>>>> de) >>>>> ). >>>>> >>>>> Rather GraphUtil.killCFG(Node). >>>>> As an example, you can look at CanonicalizerPhase.performReplacement >>>>> (around line 297): >>>>> //case 7 >>>>> fixed.predecessor().replaceFirstSuccessor(fixed, canonical); >>>>> GraphUtil.killCFG(fixed); >>>>> >>>>> even better would be: >>>>> fixed.replaceAtPredecessor(canonical); >>>>> GraphUtil.killCFG(fixed); >>>>> >>>>> where in you case fixed is the node you want to replace and canonical >>>>> is the DeoptimizeNode. >>>>> >>>>>> >>>>>> -Doug >>>> >>> >> >> > From tom.deneau at amd.com Fri Mar 7 04:52:36 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 7 Mar 2014 12:52:36 +0000 Subject: suspcions about GC and HSAIL Deopt In-Reply-To: <661FF05A-0F67-43EE-9281-85C1BA875994@oracle.com> References: <661FF05A-0F67-43EE-9281-85C1BA875994@oracle.com> Message-ID: Doug -- Regarding your handle-based solution... would it be sufficient to convert all the saved oops (in all the workitem saved state areas) to Handles before the first javaCall (while we are still in thread_in_vm mode), and then before each javaCall just convert back the one save area that is being used in that javaCall? -- Tom > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Friday, March 07, 2014 4:27 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > Subject: Re: suspcions about GC and HSAIL Deopt > > > On Mar 7, 2014, at 12:30 AM, Deneau, Tom wrote: > > > While preparing this webrev for the hsail deoptimization work we've > been doing, I noticed some spurious failures when we run on HSA > hardware. I have a theory of what's happening, let me know if this > makes sense... > > > > First the big overview: > > > > When we run a kernel, and it returns from the GPU each workitem can be > in one of 3 states: > > > > a) finished normally > > b) deopted and saved its state (and set the deopt-happened flag) > > c) on entry, saw deopt-happened=true and so just exited early > > without running. > > > > This last one exists because we don't want to have to allocate enough > deopt save space so that each workitem has its own unique save space. > > Instead we only allocate enough for the number of concurrent workitems > possible. > > > > When we return from the GPU, if one or more workitems deopted we: > > > > a) for the workitems that finished normally, there is nothing to do > > > > b) for each deopted workitems, we want to run it thru the > > interpreter going first thru the special host trampoline code > > infrastructure that Gilles created. The trampoline host code > > takes a deoptId (sort of like a pc, telling where the deopt > > occurred in the hsail code) and a pointer to the saved hsail > > frame. We currently do this sequentially although other > > policies are possible. > > > > c) for each never ran workitem, we can just run it from the > > beginning of the kernel "method", just making sure we pass the > > arguments and the appropriate workitem id for each one. Again, > > we currently do this sequentially although other policies are > > possible. > > > > When we enter the JVM to run the kernel, we transition to thread_in_vm > mode. So while running on the GPU, no oops are moving (although of > course GCs may be delayed). > > > > When we start looking for workitems of type b or c above, we are still > in thread_in_vm mode. However since both b and c above use the javaCall > infrastructure, I believe they are transitioning to thread_in_java mode > on each call, and oops can move. > > > > So if for instance there are two deopting workitems, it is possible > that after executing the first one that the saved deopt state for the > second one is no longer valid. > > > > The junit tests on which I have seen the spurious failures are ones > where lots of workitems deopt. When run in the hotspot debug build, we > usually see SEGVs in interpreter code and the access is always to > 0xbaadbabe. > > > > Note that when Gilles was developing his infrastructure, the only test > cases we had all had a single workitem deopting so would not show this. > Also even with multi-deopting test cases, I believe the reason we don't > see this on the simulator is that the concurrency is much less there so > the number of workitems of type b) above will be much less. On > hardware, we can have thousands of workitems deopting. > > > > I suppose the solution to this is to mark any oops in the deopt saved > state in some way that GC can find them and fix them. What is the best > way to do this? > > I'm not sure it's the most optimal solution, but around each javaCall, > you could convert each saved oop to a Handle and convert it back after > the call. I'm not aware of other mechanisms in HotSpot for registering > GC roots but that doesn't mean they don't exist. > > > Or is there any way to execute javaCalls from thread_in_vm mode > without allowing GCs to happen? > > You are calling arbitrary Java code right? That means you cannot > guarantee allocation won't be performed which in turn means you cannot > disable GC (even though there are mechanisms for doing so like > GC_locker::lock_critical/GC_locker::unlock_critical). > > -Doug From doug.simon at oracle.com Fri Mar 7 05:21:47 2014 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 7 Mar 2014 14:21:47 +0100 Subject: suspcions about GC and HSAIL Deopt In-Reply-To: References: <661FF05A-0F67-43EE-9281-85C1BA875994@oracle.com> Message-ID: On Mar 7, 2014, at 1:52 PM, Deneau, Tom wrote: > Doug -- > > Regarding your handle-based solution... > > would it be sufficient to convert all the saved oops (in all the workitem saved state areas) to Handles before the first javaCall (while we are still in thread_in_vm mode), and then before each javaCall just convert back the one save area that is being used in that javaCall? This javaCall is to the special deopting nmethod if I understand correctly. And the save state area is used solely as input to a deopt instruction in which case there is no possibility of a GC between entering the javaCall and hitting the deopt instruction by which time all oops have been copied from the save state area (i.e., the hsailFrame) to slots in the special deopting method?s frame. At that point, the oops in the save state area are dead and standard GC root scanning knows where to find their copies. If this is all correct, then your suggestion should work. -Doug >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Friday, March 07, 2014 4:27 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >> Subject: Re: suspcions about GC and HSAIL Deopt >> >> >> On Mar 7, 2014, at 12:30 AM, Deneau, Tom wrote: >> >>> While preparing this webrev for the hsail deoptimization work we've >> been doing, I noticed some spurious failures when we run on HSA >> hardware. I have a theory of what's happening, let me know if this >> makes sense... >>> >>> First the big overview: >>> >>> When we run a kernel, and it returns from the GPU each workitem can be >> in one of 3 states: >>> >>> a) finished normally >>> b) deopted and saved its state (and set the deopt-happened flag) >>> c) on entry, saw deopt-happened=true and so just exited early >>> without running. >>> >>> This last one exists because we don't want to have to allocate enough >> deopt save space so that each workitem has its own unique save space. >>> Instead we only allocate enough for the number of concurrent workitems >> possible. >>> >>> When we return from the GPU, if one or more workitems deopted we: >>> >>> a) for the workitems that finished normally, there is nothing to do >>> >>> b) for each deopted workitems, we want to run it thru the >>> interpreter going first thru the special host trampoline code >>> infrastructure that Gilles created. The trampoline host code >>> takes a deoptId (sort of like a pc, telling where the deopt >>> occurred in the hsail code) and a pointer to the saved hsail >>> frame. We currently do this sequentially although other >>> policies are possible. >>> >>> c) for each never ran workitem, we can just run it from the >>> beginning of the kernel "method", just making sure we pass the >>> arguments and the appropriate workitem id for each one. Again, >>> we currently do this sequentially although other policies are >>> possible. >>> >>> When we enter the JVM to run the kernel, we transition to thread_in_vm >> mode. So while running on the GPU, no oops are moving (although of >> course GCs may be delayed). >>> >>> When we start looking for workitems of type b or c above, we are still >> in thread_in_vm mode. However since both b and c above use the javaCall >> infrastructure, I believe they are transitioning to thread_in_java mode >> on each call, and oops can move. >>> >>> So if for instance there are two deopting workitems, it is possible >> that after executing the first one that the saved deopt state for the >> second one is no longer valid. >>> >>> The junit tests on which I have seen the spurious failures are ones >> where lots of workitems deopt. When run in the hotspot debug build, we >> usually see SEGVs in interpreter code and the access is always to >> 0xbaadbabe. >>> >>> Note that when Gilles was developing his infrastructure, the only test >> cases we had all had a single workitem deopting so would not show this. >> Also even with multi-deopting test cases, I believe the reason we don't >> see this on the simulator is that the concurrency is much less there so >> the number of workitems of type b) above will be much less. On >> hardware, we can have thousands of workitems deopting. >>> >>> I suppose the solution to this is to mark any oops in the deopt saved >> state in some way that GC can find them and fix them. What is the best >> way to do this? >> >> I'm not sure it's the most optimal solution, but around each javaCall, >> you could convert each saved oop to a Handle and convert it back after >> the call. I'm not aware of other mechanisms in HotSpot for registering >> GC roots but that doesn't mean they don't exist. >> >>> Or is there any way to execute javaCalls from thread_in_vm mode >> without allowing GCs to happen? >> >> You are calling arbitrary Java code right? That means you cannot >> guarantee allocation won't be performed which in turn means you cannot >> disable GC (even though there are mechanisms for doing so like >> GC_locker::lock_critical/GC_locker::unlock_critical). >> >> -Doug > > From miguelalfredo.garcia at epfl.ch Fri Mar 7 06:37:58 2014 From: miguelalfredo.garcia at epfl.ch (Garcia Gutierrez Miguel Alfredo) Date: Fri, 7 Mar 2014 14:37:58 +0000 Subject: New type-profiling points in HotSpot, how to use them from Graal? In-Reply-To: References: <7E4228B446372948BBB2916FC53FA49E26E56C06@REXMD.intranet.epfl.ch>, <79370FE9-EFD4-46EE-B0E3-A112CA6C564C@oracle.com> <7E4228B446372948BBB2916FC53FA49E26E57DE0@REXMD.intranet.epfl.ch>, Message-ID: <7E4228B446372948BBB2916FC53FA49E26E57F75@REXMD.intranet.epfl.ch> Roland, Per-callsite profiling of actual-return-type looks promising to (a) achieve one of the benefits of inlining (letting the JIT compiler specialize the usages of an invocation, ie specialize dependent code to the type actually returned) (b) without actually inlining For example, for a monomorphic callsite the dispatched method is (sometimes) an override with a more specific actual return type. In case inlining doesn't inline it, the more precise type information remains unexploited. I hadn't thought about levering that profiling info for invokedynamic (but will look into it, thanks for the link to the webrev). Miguel -- Miguel Garcia Swiss Federal Institute of Technology EPFL - IC - LAMP1 - INR 328 - Station 14 CH-1015 Lausanne - Switzerland http://lamp.epfl.ch/~magarcia/ ________________________________________ From: Roland Westrelin [roland.westrelin at oracle.com] Sent: Friday, March 07, 2014 2:37 PM To: Garcia Gutierrez Miguel Alfredo Cc: Christian Thalinger; graal-dev at openjdk.java.net Subject: Re: New type-profiling points in HotSpot, how to use them from Graal? Hi Miguel, >>> It would be great to hear more about that (recently added) functionality in HotSpot. > >> What would you like to hear? > > Any kind of context on the problem would be of help, e.g. what code needs to be changed in Graal. We use the new profiling to improve code generation in c2 with dynamic languages that use invokedynamic. The way we use it in c2 is with what we call type speculation. It was pushed with this change: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b2ee5dc63353 and a number of fixes and improvements has been following since. What are you trying to achieve? Roland. From tom.deneau at amd.com Fri Mar 7 11:54:58 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 7 Mar 2014 19:54:58 +0000 Subject: gdb to native frame that made a javaCall Message-ID: Say you're debugging hotspot in gdb and you hit a SEGV or some other fault while running in the interpreter on behalf of making a javaCall that was invoked from the vm. Is there a way to get gdb back to the native frame that made the javaCall? -- Tom From miguelalfredo.garcia at epfl.ch Sat Mar 8 19:23:43 2014 From: miguelalfredo.garcia at epfl.ch (Garcia Gutierrez Miguel Alfredo) Date: Sat, 8 Mar 2014 19:23:43 +0000 Subject: a JDK build with Graal as default Message-ID: <7E4228B446372948BBB2916FC53FA49E26E5824C@REXMD.intranet.epfl.ch> Hi, After installing the JDK build from http://lafo.ssw.uni-linz.ac.at/builds/ and running "java -version" looks like Graal isn't the default JIT compiler (for that, one needs "java -graal ...") Is there a build as above but with the Graal configuration as default? That would simplify tricking any Java software into using the Graal JIT compiler. Miguel -- Miguel Garcia Swiss Federal Institute of Technology EPFL - IC - LAMP1 - INR 328 - Station 14 CH-1015 Lausanne - Switzerland http://lamp.epfl.ch/~magarcia/ From igor.ignatyev at oracle.com Sun Mar 9 09:58:25 2014 From: igor.ignatyev at oracle.com (=?utf-8?B?aWdvci5pZ25hdHlldkBvcmFjbGUuY29t?=) Date: Sun, 09 Mar 2014 13:58:25 +0400 Subject: =?utf-8?B?UmU6IGEgSkRLIGJ1aWxkIHdpdGggR3JhYWwgYXMgZGVmYXVsdA==?= Message-ID: <201403090958.s299wRAB004620@aserz7022.oracle.com> Hi Miguel, You can change default configuration by adding '-graal KNOWN' as the 1st line in 'jre/lib//jvm.cfg' file. -- II ----- Reply message ----- From: "Garcia Gutierrez Miguel Alfredo" To: "graal-dev at openjdk.java.net" Subject: a JDK build with Graal as default Date: Sat, Mar 8, 2014 23:23 Hi, After installing the JDK build from http://lafo.ssw.uni-linz.ac.at/builds/ and running "java -version" looks like Graal isn't the default JIT compiler (for that, one needs "java -graal ...") Is there a build as above but with the Graal configuration as default? That would simplify tricking any Java software into using the Graal JIT compiler. Miguel -- Miguel Garcia Swiss Federal Institute of Technology EPFL - IC - LAMP1 - INR 328 - Station 14 CH-1015 Lausanne - Switzerland http://lamp.epfl.ch/~magarcia/ From java at stefan-marr.de Sun Mar 9 19:42:01 2014 From: java at stefan-marr.de (Stefan Marr) Date: Sun, 9 Mar 2014 20:42:01 +0100 Subject: Truffle CallNode API In-Reply-To: References: Message-ID: Hi Christian: On 05 Mar 2014, at 19:38, Christian Humer wrote: > I have to admit that the current heuristic for splitting is quite rough. So I can recommend you to enforce inlining and splitting with CallNode#inline and CallNode#split on the important calls for now. Is that good enough for you, for now? Yes, works well, I think. Thanks. At least the DeltaBlue and Richards are back to the same performance as before. > In the future this decision will be based on the polymorphism of the called method. Therefore we also introduced a new method to Node getKind. getKind returns whether the actual node is specialized/monomorphic, polymorphic or generic/megamorphic. By counting polymorphic/megamorphic nodes we can do a good guess if a split could be worthwhile or not. For this heuristic to work you have to implement #getKind() in your specializations. Nodes that use Truffle DSL automatically get support for that. Ok, what exactly are the implications for the different node kinds? For some of the nodes I am not entirely sure whether they are ?specialized? or ?generic?. For instance, the lookup of globals goes from uninitialized to cached, because it simply looks up the association object (key, global value). So, is the ?cached? class a specialized or generic one? Does the distinction have an influence on your heuristic? Thanks Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From christian.humer at gmail.com Sun Mar 9 21:28:31 2014 From: christian.humer at gmail.com (Christian Humer) Date: Sun, 9 Mar 2014 22:28:31 +0100 Subject: Truffle CallNode API In-Reply-To: References: Message-ID: Hi Stefan, On Sun, Mar 9, 2014 at 8:42 PM, Stefan Marr wrote: > For instance, the lookup of globals goes from uninitialized to cached, > because it simply looks up the association object (key, global value). So, > is the 'cached' class a specialized or generic one? Does the distinction > have an influence on your heuristic? > I am not yet sure how to do the exact distinction of kinds. Often it is hard to categorize. If you are not sure, you can leave them as specialized for now. That will do no harm (while generic or polymorphic could). A generic version of a node is a node which encodes the full operation in the node. It is kind of the worst case specialization. A generic version is considered expensive. However if the generic version is the only specialization that is available I would mark that node as specialized for now otherwise the enclosing method will always get split. I would consider a cache chain as polymorphic as soon as there are two or more entries. If there are less than two entries it could be considered specialized. I solved this for simple language using this pattern: @Override public Kind getKind() { return nextNode.getKind() == Kind.UNINITIALIZED ? Kind.SPECIALIZED : Kind.POLYMORPHIC; } For a cache chain with n entries the heuristic will get the information that n - 1 nodes are polymorphic. If the cache chain gets to big it should rewrite the chain with a node that is marked as generic/megamorphic. The heuristic counts the number of polymorphic and generic marked nodes. It uses this information to determine if it should split or not (beside some other criteria). However I am not yet sure how the heuristic will look like in the end. Maybe it will just always split if there is a polymorphic and/or generic node contained in the method. So the exact number of polymorphic and/or generic nodes may not be required in the end. It is even possible that we will drop this idea of counting polymorphic/generic nodes for the split heuristic completely ;). - Christian Humer From java at stefan-marr.de Mon Mar 10 11:23:00 2014 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 10 Mar 2014 12:23:00 +0100 Subject: TruffleSOM Update and Issues with Splitting Message-ID: Hi: In order to finally get TruffleSOM up to reasonable speeds, I adopted the new design for function invocation/message sends of SimpleLanguage. == New design: This means, TruffleSOM does no longer use the distinction between unary, binary, ternary, and keyword message sends. Instead, it uses a single MessageSendNode. To facilitate specialization, I now use direct n-ary expression nodes, which are subclassed by specializing classes for instance for control structures, and primitives. This design disentangles the notion of message sending from the specialization, which was previously conflated. As a side note, I am also using this distinction, and the logic in UninitalizedMessageSendNode to eagerly specialize message send nodes for basic operations such as addition to their primitive expression nodes by wrapping them into a simple [U|Bi|Ter]naryEagerPrimitiveSpecializationNode [1], which catches the UnsupportedSpecializationException and only then goes to a full message send. Not sure whether that?s the best way to do it, but so far it gives good results. It reduces warmup time and improves peak performance on micrbenchmarks (it seems to have a negative impact on DeltaBlue) It would probably still be nicer if I could specify my GenericMessageSendNode to be the generic case for all specializations. Overall, with the new design, I can avoid significant amounts for code duplication I had before because of the direct use of subclasses for message send nodes for specialization as well. Unfortunately, performance is generally worse. == @ExplodeLoop not enough to avoid ?escaping frames?: I again ran into issues with escaping frames. Eventually, I fixed the issue with the change in [2]. Essentially, the @ExplodeLoop annotation did not properly work on the method as long as there was the tail call to executeEvaluated(.). Such things are really really hard to figure out for me, because I have no idea how to get hints on what is going on. The only information was, as usual that there was a call to executeGeneric(frame) that let the frame escape. By now I already know that it means the call could not be devirtualized. And that I should look out for loops that are not unrolled. Ok, fine. But this time there was no loop that missed the @ExplodeLoop annotation. And it was guessing which of the many changes I introduce could be the culprit. The change in [2] was a random guess that happened to work and leaves me with a very unsatisfied feeling. Anyway, on to the real problem. == Execution Tree is not stabilizing with splitting: With splitting is enabled, only a handful of benchmarks stabilize. Things like the simple WhileLoop benchmark, but also Richards and DeltaBlue seem to be ok. Highly recursive benchmarks such as Fibonacci seem to be problematic. After a while, I get for Fibonacci output like the one below [3]. I don?t see any specialization going on anymore, instead I see those ?inline success? reports perpetually. I am not sure what to make of that. What exactly is indicated by this message? Are the tree copies, i.e., splitted copies gradually inlined? Could it indicate that an upper limit on inlining doesn?t trigger while it probably should? Any hints what that could mean are highly appreciate! Thanks Stefan [1] https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/nary/EagerBinaryPrimitiveNode.java#L47 [2] https://github.com/SOM-st/TruffleSOM/commit/3f01afebfbf603e21519c608beff201af3d11a90 [3] Output for Fibonacci: [truffle] opt done Method Fibonacci>>#$block method:Examples/Benchmarks//Fibonacci.som:38 at 3a507beb |ASTSize 1482 (0/109) |Time 797( 648+149 )ms |Nodes 1246/ 1323 |CodeSize 6768 |Source Examples/Benchmarks//Fibonacci.som:38 [truffle] inline success Method Fibonacci>>#fibonacci::Examples/Benchmarks//Fibonacci.som:37 at 23877e40 |ASTSize 16 (0/2) |shallowCount 16 |currentCount 54 |inlinedTotalCount 86 |score 0.06 |frequency 1.00 |callCount 1000 [truffle] inline success Method Fibonacci>>#fibonacci::Examples/Benchmarks//Fibonacci.som:37 at 2ede6d8e |ASTSize 16 (0/2) |shallowCount 16 |currentCount 86 |inlinedTotalCount 118 |score 0.06 |frequency 1.00 |callCount 1000 [truffle] inline success Method Fibonacci>>#$block method:Examples/Benchmarks//Fibonacci.som:38 at 1fc40e10 |ASTSize 54 (0/1) |shallowCount 54 |currentCount 118 |inlinedTotalCount 226 |score 0.02 |frequency 1.00 |callCount 999 [truffle] inline success Method Fibonacci>>#fibonacci::Examples/Benchmarks//Fibonacci.som:37 at 7895b698 |ASTSize 16 (0/2) |shallowCount 16 |currentCount 226 |inlinedTotalCount 290 |score 0.06 |frequency 1.00 |callCount 998 [truffle] inline success Method Fibonacci>>#fibonacci::Examples/Benchmarks//Fibonacci.som:37 at e424bba |ASTSize 16 (0/2) |shallowCount 16 |currentCount 290 |inlinedTotalCount 354 |score 0.06 |frequency 1.00 |callCount 998 [truffle] inline success Method Fibonacci>>#$block method:Examples/Benchmarks//Fibonacci.som:38 at 89ab152 |ASTSize 54 (0/1) |shallowCount 54 |currentCount 354 |inlinedTotalCount 570 |score 0.02 |frequency 1.00 |callCount 997 [truffle] inline success Method Fibonacci>>#fibonacci::Examples/Benchmarks//Fibonacci.som:37 at 4203f936 |ASTSize 16 (0/2) |shallowCount 16 |currentCount 570 |inlinedTotalCount 698 |score 0.06 |frequency 1.00 |callCount 996 [truffle] inline success Method Fibonacci>>#fibonacci::Examples/Benchmarks//Fibonacci.som:37 at 30cd607d |ASTSize 16 (0/2) |shallowCount 16 |currentCount 698 |inlinedTotalCount 826 |score 0.06 |frequency 1.00 |callCount 996 [truffle] inline success Method Fibonacci>>#$block method:Examples/Benchmarks//Fibonacci.som:38 at c20f79c|ASTSize 15 (0/1) |shallowCount 15 |currentCount 826 |inlinedTotalCount 946 |score NaN |frequency NaN |callCount 0 [truffle] inline success Method Fibonacci>>#$block method:Examples/Benchmarks//Fibonacci.som:38 at 3a3e575d |ASTSize 54 (0/1) |shallowCount 54 |currentCount 946 |inlinedTotalCount 1054 |score 0.02 |frequency 1.00 |callCount 999 [truffle] inline success Method Fibonacci>>#fibonacci::Examples/Benchmarks//Fibonacci.som:37 at 32579775 |ASTSize 16 (0/2) |shallowCount 16 |currentCount 1054 |inlinedTotalCount 1118 |score 0.06 |frequency 1.00 |callCount 998 [truffle] inline success Method Fibonacci>>#fibonacci::Examples/Benchmarks//Fibonacci.som:37 at 4acce36b |ASTSize 16 (0/2) |shallowCount 16 |currentCount 1118 |inlinedTotalCount 1182 |score 0.06 |frequency 1.00 |callCount 998 [truffle] inline success Method Fibonacci>>#$block method:Examples/Benchmarks//Fibonacci.som:38 at 55766e96|ASTSize 15 (0/1) |shallowCount 15 |currentCount 1182 |inlinedTotalCount 1242 |score NaN |frequency NaN |callCount 0 [truffle] inline success Method Fibonacci>>#$block method:Examples/Benchmarks//Fibonacci.som:38 at 23d9bebe |ASTSize 54 (0/1) |shallowCount 54 |currentCount 1242 |inlinedTotalCount 1674 |score 0.02 |frequency 1.00 |callCount 995 [truffle] inline success Method Fibonacci>>#fibonacci::Examples/Benchmarks//Fibonacci.som:37 at 313a51b |ASTSize 16 (0/2) |shallowCount 16 |currentCount 1674 |inlinedTotalCount 1930 |score 0.06 |frequency 1.00 |callCount 994 [truffle] inline success Method Fibonacci>>#$block method:Examples/Benchmarks//Fibonacci.som:38 at 5c07f072|ASTSize 15 (0/1) |shallowCount 15 |currentCount 1930 |inlinedTotalCount 2170 |score NaN |frequency NaN |callCount 0 [truffle] opt queued Method Fibonacci>>#$block method:Examples/Benchmarks//Fibonacci.som:38 at 4d27d539 |ASTSize 2170 (0/149) |C/T 1000/ 1001 |L/T 1000/ 1010 |Inval#/Replace# 0/ 38 [truffle] opt start Method Fibonacci>>#$block method:Examples/Benchmarks//Fibonacci.som:38 at 4d27d539 |ASTSize 2170 (0/149) |C/T 1000/ 1001 |L/T 1000/ 1010 |Inval#/Replace# 0/ 38 -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From duboscq at ssw.jku.at Mon Mar 10 12:58:19 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Mon, 10 Mar 2014 13:58:19 +0100 Subject: suspcions about GC and HSAIL Deopt In-Reply-To: References: <661FF05A-0F67-43EE-9281-85C1BA875994@oracle.com> Message-ID: Using Handle and restoring the value should work. In the long term we may want to just have an opps_do on the save area and hook into JavaThread::oops_do. However even with the Handles version you need "oop maps" for the save areas. It shouldn't be very hard to extract them from the HSAIL compilation but currently they are just thrown away. -Gilles On Fri, Mar 7, 2014 at 2:21 PM, Doug Simon wrote: > > On Mar 7, 2014, at 1:52 PM, Deneau, Tom wrote: > >> Doug -- >> >> Regarding your handle-based solution... >> >> would it be sufficient to convert all the saved oops (in all the workitem saved state areas) to Handles before the first javaCall (while we are still in thread_in_vm mode), and then before each javaCall just convert back the one save area that is being used in that javaCall? > > This javaCall is to the special deopting nmethod if I understand correctly. And the save state area is used solely as input to a deopt instruction in which case there is no possibility of a GC between entering the javaCall and hitting the deopt instruction by which time all oops have been copied from the save state area (i.e., the hsailFrame) to slots in the special deopting method?s frame. At that point, the oops in the save state area are dead and standard GC root scanning knows where to find their copies. If this is all correct, then your suggestion should work. > > -Doug > >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Friday, March 07, 2014 4:27 AM >>> To: Deneau, Tom >>> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >>> Subject: Re: suspcions about GC and HSAIL Deopt >>> >>> >>> On Mar 7, 2014, at 12:30 AM, Deneau, Tom wrote: >>> >>>> While preparing this webrev for the hsail deoptimization work we've >>> been doing, I noticed some spurious failures when we run on HSA >>> hardware. I have a theory of what's happening, let me know if this >>> makes sense... >>>> >>>> First the big overview: >>>> >>>> When we run a kernel, and it returns from the GPU each workitem can be >>> in one of 3 states: >>>> >>>> a) finished normally >>>> b) deopted and saved its state (and set the deopt-happened flag) >>>> c) on entry, saw deopt-happened=true and so just exited early >>>> without running. >>>> >>>> This last one exists because we don't want to have to allocate enough >>> deopt save space so that each workitem has its own unique save space. >>>> Instead we only allocate enough for the number of concurrent workitems >>> possible. >>>> >>>> When we return from the GPU, if one or more workitems deopted we: >>>> >>>> a) for the workitems that finished normally, there is nothing to do >>>> >>>> b) for each deopted workitems, we want to run it thru the >>>> interpreter going first thru the special host trampoline code >>>> infrastructure that Gilles created. The trampoline host code >>>> takes a deoptId (sort of like a pc, telling where the deopt >>>> occurred in the hsail code) and a pointer to the saved hsail >>>> frame. We currently do this sequentially although other >>>> policies are possible. >>>> >>>> c) for each never ran workitem, we can just run it from the >>>> beginning of the kernel "method", just making sure we pass the >>>> arguments and the appropriate workitem id for each one. Again, >>>> we currently do this sequentially although other policies are >>>> possible. >>>> >>>> When we enter the JVM to run the kernel, we transition to thread_in_vm >>> mode. So while running on the GPU, no oops are moving (although of >>> course GCs may be delayed). >>>> >>>> When we start looking for workitems of type b or c above, we are still >>> in thread_in_vm mode. However since both b and c above use the javaCall >>> infrastructure, I believe they are transitioning to thread_in_java mode >>> on each call, and oops can move. >>>> >>>> So if for instance there are two deopting workitems, it is possible >>> that after executing the first one that the saved deopt state for the >>> second one is no longer valid. >>>> >>>> The junit tests on which I have seen the spurious failures are ones >>> where lots of workitems deopt. When run in the hotspot debug build, we >>> usually see SEGVs in interpreter code and the access is always to >>> 0xbaadbabe. >>>> >>>> Note that when Gilles was developing his infrastructure, the only test >>> cases we had all had a single workitem deopting so would not show this. >>> Also even with multi-deopting test cases, I believe the reason we don't >>> see this on the simulator is that the concurrency is much less there so >>> the number of workitems of type b) above will be much less. On >>> hardware, we can have thousands of workitems deopting. >>>> >>>> I suppose the solution to this is to mark any oops in the deopt saved >>> state in some way that GC can find them and fix them. What is the best >>> way to do this? >>> >>> I'm not sure it's the most optimal solution, but around each javaCall, >>> you could convert each saved oop to a Handle and convert it back after >>> the call. I'm not aware of other mechanisms in HotSpot for registering >>> GC roots but that doesn't mean they don't exist. >>> >>>> Or is there any way to execute javaCalls from thread_in_vm mode >>> without allowing GCs to happen? >>> >>> You are calling arbitrary Java code right? That means you cannot >>> guarantee allocation won't be performed which in turn means you cannot >>> disable GC (even though there are mechanisms for doing so like >>> GC_locker::lock_critical/GC_locker::unlock_critical). >>> >>> -Doug >> >> > From tom.deneau at amd.com Mon Mar 10 13:28:48 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 10 Mar 2014 13:28:48 +0000 Subject: suspcions about GC and HSAIL Deopt In-Reply-To: References: <661FF05A-0F67-43EE-9281-85C1BA875994@oracle.com> Message-ID: Gilles -- Update on this... Yes, I put in the code to save the oops maps, currently somewhat simplified in that only hsail $d registers can have oops and we are not saving stack slots yet. Using that I implemented a quickie solution that copied the detected oops into a regular java Object array before the first deopt, then reloaded them into the particular frame before each deopt. Logging code did show that there were times when the original value of the oop had changed to a new value and we no longer hit our spurious failures. I'm sure its inefficient when compared to an oops_do approach but it did seem to work. I will probably submit the webrev with this quickie solution and we can discuss how to make it use oops_do. -- Tom > -----Original Message----- > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > Gilles Duboscq > Sent: Monday, March 10, 2014 7:58 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > Subject: Re: suspcions about GC and HSAIL Deopt > > Using Handle and restoring the value should work. In the long term we > may want to just have an opps_do on the save area and hook into > JavaThread::oops_do. > > However even with the Handles version you need "oop maps" for the save > areas. It shouldn't be very hard to extract them from the HSAIL > compilation but currently they are just thrown away. > > -Gilles > > On Fri, Mar 7, 2014 at 2:21 PM, Doug Simon > wrote: > > > > On Mar 7, 2014, at 1:52 PM, Deneau, Tom wrote: > > > >> Doug -- > >> > >> Regarding your handle-based solution... > >> > >> would it be sufficient to convert all the saved oops (in all the > workitem saved state areas) to Handles before the first javaCall (while > we are still in thread_in_vm mode), and then before each javaCall just > convert back the one save area that is being used in that javaCall? > > > > This javaCall is to the special deopting nmethod if I understand > correctly. And the save state area is used solely as input to a deopt > instruction in which case there is no possibility of a GC between > entering the javaCall and hitting the deopt instruction by which time > all oops have been copied from the save state area (i.e., the > hsailFrame) to slots in the special deopting method?s frame. At that > point, the oops in the save state area are dead and standard GC root > scanning knows where to find their copies. If this is all correct, then > your suggestion should work. > > > > -Doug > > > >>> -----Original Message----- > >>> From: Doug Simon [mailto:doug.simon at oracle.com] > >>> Sent: Friday, March 07, 2014 4:27 AM > >>> To: Deneau, Tom > >>> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > >>> Subject: Re: suspcions about GC and HSAIL Deopt > >>> > >>> > >>> On Mar 7, 2014, at 12:30 AM, Deneau, Tom wrote: > >>> > >>>> While preparing this webrev for the hsail deoptimization work we've > >>> been doing, I noticed some spurious failures when we run on HSA > >>> hardware. I have a theory of what's happening, let me know if this > >>> makes sense... > >>>> > >>>> First the big overview: > >>>> > >>>> When we run a kernel, and it returns from the GPU each workitem can > >>>> be > >>> in one of 3 states: > >>>> > >>>> a) finished normally > >>>> b) deopted and saved its state (and set the deopt-happened flag) > >>>> c) on entry, saw deopt-happened=true and so just exited early > >>>> without running. > >>>> > >>>> This last one exists because we don't want to have to allocate > >>>> enough > >>> deopt save space so that each workitem has its own unique save > space. > >>>> Instead we only allocate enough for the number of concurrent > >>>> workitems > >>> possible. > >>>> > >>>> When we return from the GPU, if one or more workitems deopted we: > >>>> > >>>> a) for the workitems that finished normally, there is nothing to > >>>> do > >>>> > >>>> b) for each deopted workitems, we want to run it thru the > >>>> interpreter going first thru the special host trampoline code > >>>> infrastructure that Gilles created. The trampoline host code > >>>> takes a deoptId (sort of like a pc, telling where the deopt > >>>> occurred in the hsail code) and a pointer to the saved hsail > >>>> frame. We currently do this sequentially although other > >>>> policies are possible. > >>>> > >>>> c) for each never ran workitem, we can just run it from the > >>>> beginning of the kernel "method", just making sure we pass the > >>>> arguments and the appropriate workitem id for each one. Again, > >>>> we currently do this sequentially although other policies are > >>>> possible. > >>>> > >>>> When we enter the JVM to run the kernel, we transition to > >>>> thread_in_vm > >>> mode. So while running on the GPU, no oops are moving (although of > >>> course GCs may be delayed). > >>>> > >>>> When we start looking for workitems of type b or c above, we are > >>>> still > >>> in thread_in_vm mode. However since both b and c above use the > >>> javaCall infrastructure, I believe they are transitioning to > >>> thread_in_java mode on each call, and oops can move. > >>>> > >>>> So if for instance there are two deopting workitems, it is possible > >>> that after executing the first one that the saved deopt state for > >>> the second one is no longer valid. > >>>> > >>>> The junit tests on which I have seen the spurious failures are ones > >>> where lots of workitems deopt. When run in the hotspot debug build, > >>> we usually see SEGVs in interpreter code and the access is always to > >>> 0xbaadbabe. > >>>> > >>>> Note that when Gilles was developing his infrastructure, the only > >>>> test > >>> cases we had all had a single workitem deopting so would not show > this. > >>> Also even with multi-deopting test cases, I believe the reason we > >>> don't see this on the simulator is that the concurrency is much less > >>> there so the number of workitems of type b) above will be much less. > >>> On hardware, we can have thousands of workitems deopting. > >>>> > >>>> I suppose the solution to this is to mark any oops in the deopt > >>>> saved > >>> state in some way that GC can find them and fix them. What is the > >>> best way to do this? > >>> > >>> I'm not sure it's the most optimal solution, but around each > >>> javaCall, you could convert each saved oop to a Handle and convert > >>> it back after the call. I'm not aware of other mechanisms in HotSpot > >>> for registering GC roots but that doesn't mean they don't exist. > >>> > >>>> Or is there any way to execute javaCalls from thread_in_vm mode > >>> without allowing GCs to happen? > >>> > >>> You are calling arbitrary Java code right? That means you cannot > >>> guarantee allocation won't be performed which in turn means you > >>> cannot disable GC (even though there are mechanisms for doing so > >>> like GC_locker::lock_critical/GC_locker::unlock_critical). > >>> > >>> -Doug > >> > >> > > From duboscq at ssw.jku.at Mon Mar 10 15:14:29 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Mon, 10 Mar 2014 16:14:29 +0100 Subject: suspcions about GC and HSAIL Deopt In-Reply-To: References: <661FF05A-0F67-43EE-9281-85C1BA875994@oracle.com> Message-ID: Ok, sounds good On Mon, Mar 10, 2014 at 2:28 PM, Tom Deneau wrote: > Gilles -- > > Update on this... > > Yes, I put in the code to save the oops maps, currently somewhat simplified in that only hsail $d registers can have oops and we are not saving stack slots yet. > > Using that I implemented a quickie solution that copied the detected oops into a regular java Object array before the first deopt, then reloaded them into the particular frame before each deopt. Logging code did show that there were times when the original value of the oop had changed to a new value and we no longer hit our spurious failures. I'm sure its inefficient when compared to an oops_do approach but it did seem to work. > > I will probably submit the webrev with this quickie solution and we can discuss how to make it use oops_do. > > -- Tom > > > > > >> -----Original Message----- >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of >> Gilles Duboscq >> Sent: Monday, March 10, 2014 7:58 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >> Subject: Re: suspcions about GC and HSAIL Deopt >> >> Using Handle and restoring the value should work. In the long term we >> may want to just have an opps_do on the save area and hook into >> JavaThread::oops_do. >> >> However even with the Handles version you need "oop maps" for the save >> areas. It shouldn't be very hard to extract them from the HSAIL >> compilation but currently they are just thrown away. >> >> -Gilles >> >> On Fri, Mar 7, 2014 at 2:21 PM, Doug Simon >> wrote: >> > >> > On Mar 7, 2014, at 1:52 PM, Deneau, Tom wrote: >> > >> >> Doug -- >> >> >> >> Regarding your handle-based solution... >> >> >> >> would it be sufficient to convert all the saved oops (in all the >> workitem saved state areas) to Handles before the first javaCall (while >> we are still in thread_in_vm mode), and then before each javaCall just >> convert back the one save area that is being used in that javaCall? >> > >> > This javaCall is to the special deopting nmethod if I understand >> correctly. And the save state area is used solely as input to a deopt >> instruction in which case there is no possibility of a GC between >> entering the javaCall and hitting the deopt instruction by which time >> all oops have been copied from the save state area (i.e., the >> hsailFrame) to slots in the special deopting method?s frame. At that >> point, the oops in the save state area are dead and standard GC root >> scanning knows where to find their copies. If this is all correct, then >> your suggestion should work. >> > >> > -Doug >> > >> >>> -----Original Message----- >> >>> From: Doug Simon [mailto:doug.simon at oracle.com] >> >>> Sent: Friday, March 07, 2014 4:27 AM >> >>> To: Deneau, Tom >> >>> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >> >>> Subject: Re: suspcions about GC and HSAIL Deopt >> >>> >> >>> >> >>> On Mar 7, 2014, at 12:30 AM, Deneau, Tom wrote: >> >>> >> >>>> While preparing this webrev for the hsail deoptimization work we've >> >>> been doing, I noticed some spurious failures when we run on HSA >> >>> hardware. I have a theory of what's happening, let me know if this >> >>> makes sense... >> >>>> >> >>>> First the big overview: >> >>>> >> >>>> When we run a kernel, and it returns from the GPU each workitem can >> >>>> be >> >>> in one of 3 states: >> >>>> >> >>>> a) finished normally >> >>>> b) deopted and saved its state (and set the deopt-happened flag) >> >>>> c) on entry, saw deopt-happened=true and so just exited early >> >>>> without running. >> >>>> >> >>>> This last one exists because we don't want to have to allocate >> >>>> enough >> >>> deopt save space so that each workitem has its own unique save >> space. >> >>>> Instead we only allocate enough for the number of concurrent >> >>>> workitems >> >>> possible. >> >>>> >> >>>> When we return from the GPU, if one or more workitems deopted we: >> >>>> >> >>>> a) for the workitems that finished normally, there is nothing to >> >>>> do >> >>>> >> >>>> b) for each deopted workitems, we want to run it thru the >> >>>> interpreter going first thru the special host trampoline code >> >>>> infrastructure that Gilles created. The trampoline host code >> >>>> takes a deoptId (sort of like a pc, telling where the deopt >> >>>> occurred in the hsail code) and a pointer to the saved hsail >> >>>> frame. We currently do this sequentially although other >> >>>> policies are possible. >> >>>> >> >>>> c) for each never ran workitem, we can just run it from the >> >>>> beginning of the kernel "method", just making sure we pass the >> >>>> arguments and the appropriate workitem id for each one. Again, >> >>>> we currently do this sequentially although other policies are >> >>>> possible. >> >>>> >> >>>> When we enter the JVM to run the kernel, we transition to >> >>>> thread_in_vm >> >>> mode. So while running on the GPU, no oops are moving (although of >> >>> course GCs may be delayed). >> >>>> >> >>>> When we start looking for workitems of type b or c above, we are >> >>>> still >> >>> in thread_in_vm mode. However since both b and c above use the >> >>> javaCall infrastructure, I believe they are transitioning to >> >>> thread_in_java mode on each call, and oops can move. >> >>>> >> >>>> So if for instance there are two deopting workitems, it is possible >> >>> that after executing the first one that the saved deopt state for >> >>> the second one is no longer valid. >> >>>> >> >>>> The junit tests on which I have seen the spurious failures are ones >> >>> where lots of workitems deopt. When run in the hotspot debug build, >> >>> we usually see SEGVs in interpreter code and the access is always to >> >>> 0xbaadbabe. >> >>>> >> >>>> Note that when Gilles was developing his infrastructure, the only >> >>>> test >> >>> cases we had all had a single workitem deopting so would not show >> this. >> >>> Also even with multi-deopting test cases, I believe the reason we >> >>> don't see this on the simulator is that the concurrency is much less >> >>> there so the number of workitems of type b) above will be much less. >> >>> On hardware, we can have thousands of workitems deopting. >> >>>> >> >>>> I suppose the solution to this is to mark any oops in the deopt >> >>>> saved >> >>> state in some way that GC can find them and fix them. What is the >> >>> best way to do this? >> >>> >> >>> I'm not sure it's the most optimal solution, but around each >> >>> javaCall, you could convert each saved oop to a Handle and convert >> >>> it back after the call. I'm not aware of other mechanisms in HotSpot >> >>> for registering GC roots but that doesn't mean they don't exist. >> >>> >> >>>> Or is there any way to execute javaCalls from thread_in_vm mode >> >>> without allowing GCs to happen? >> >>> >> >>> You are calling arbitrary Java code right? That means you cannot >> >>> guarantee allocation won't be performed which in turn means you >> >>> cannot disable GC (even though there are mechanisms for doing so >> >>> like GC_locker::lock_critical/GC_locker::unlock_critical). >> >>> >> >>> -Doug >> >> >> >> >> > > From doug.simon at oracle.com Mon Mar 10 15:58:04 2014 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 10 Mar 2014 16:58:04 +0100 Subject: Moving GPU offload policy into Java sources In-Reply-To: <531DD592.2050806@oracle.com> References: <531A347B.4030906@oracle.com> <581921E1-8E90-46FD-9635-A6BDBEE12A8C@oracle.com> <531A380B.7040608@oracle.com> <6ED7D40E-56A8-4EE3-A66D-A2132AB734EE@oracle.com> <531DD592.2050806@oracle.com> Message-ID: [opening up for broader discussion] Bharadwaj, I think this is really a discussion on whether or not it makes sense for a whole bytecode method to be offloaded to a GPU. I cannot imagine a scenario in which this would achieve faster execution that host CPU execution. In my understanding, for GPU execution to be a win, there needs to be parallel execution. This requires either some compiler-like analysis or some library API that implies parallel execution. The latter justifies the Sumatra approach. For the former, an ideal place to do the analysis is as part of compilation. The compiler may recognize a loop whose body can offloaded to GPU. So, in that sense, you could say that offload is part of compilation. However, I still think this is different from being part of *compilation policy*. For the latter, all the analysis has to be done as part of the process deciding whether or not to compile something. Not only would this be very expensive, it would almost certainly require an analysis framework very similar to what the compiler already offers. So, I think we agree on the worthy goal of automatic GPU offload. I just think this is best done within a compilation. Assuming you still think the required analysis is best done outside of compilation, can you describe how it can be done (efficiently) and what mechanisms it would use? -Doug On Mar 10, 2014, at 4:09 PM, S. Bharadwaj Yadavalli wrote: > > On 03/08/2014 03:50 AM, Doug Simon wrote: >> Why? All the context needed for the decision can be accessed from Java code. In any case, it needs to be removed from the normal compilation policy mechanism. > > In my opinion, deciding which non-host target to compile and execute Java methods _is_ part of compilation policy - just like the current compilation policy decides which methods to compile and which to interpret. Enhancing the present policy to offload execution of appropriate portions of Java for better performance _transparently_ is what gives the ability to run Java applications on heterogeneous systems. Adding GPU-specific changes to JDK (similar to what AMD guys did for Streams) is at best an intermediate step. Taking that approach will require implementations of data structures such as Streams to be specialized for GPUs as well as other heterogeneous architectures like Intel's Phi. We will have to then specialize implementations of other data structures. > > I believe that non-host offload should be decided by the VM based on structure of the code in a compilation unit and the nature of data that unit manipulates. Any specialization/annotation in the library code should be to provide hints to the offload policy. > > Bharadwaj > From tom.deneau at amd.com Mon Mar 10 16:53:11 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 10 Mar 2014 16:53:11 +0000 Subject: suspcions about GC and HSAIL Deopt In-Reply-To: References: <661FF05A-0F67-43EE-9281-85C1BA875994@oracle.com> Message-ID: Gilles, Doug -- I was wondering about this statement Doug made... This javaCall is to the special deopting nmethod if I understand correctly. And the save state area is used solely as input to a deopt instruction in which case there is no possibility of a GC between entering the javaCall and hitting the deopt instruction by which time all oops have been copied from the save state area (i.e., the hsailFrame) to slots in the special deopting method?s frame. Is it true there is no possibility of GC between entering the nmethod and hitting the deopt call/instruction? How is that prevented? -- Tom > -----Original Message----- > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > Gilles Duboscq > Sent: Monday, March 10, 2014 10:14 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > Subject: Re: suspcions about GC and HSAIL Deopt > > Ok, sounds good > > On Mon, Mar 10, 2014 at 2:28 PM, Tom Deneau > wrote: > > Gilles -- > > > > Update on this... > > > > Yes, I put in the code to save the oops maps, currently somewhat > simplified in that only hsail $d registers can have oops and we are not > saving stack slots yet. > > > > Using that I implemented a quickie solution that copied the detected > oops into a regular java Object array before the first deopt, then > reloaded them into the particular frame before each deopt. Logging code > did show that there were times when the original value of the oop had > changed to a new value and we no longer hit our spurious failures. > I'm sure its inefficient when compared to an oops_do approach but it did > seem to work. > > > > I will probably submit the webrev with this quickie solution and we > can discuss how to make it use oops_do. > > > > -- Tom > > > > > > > > > > > >> -----Original Message----- > >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > >> Gilles Duboscq > >> Sent: Monday, March 10, 2014 7:58 AM > >> To: Deneau, Tom > >> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > >> Subject: Re: suspcions about GC and HSAIL Deopt > >> > >> Using Handle and restoring the value should work. In the long term we > >> may want to just have an opps_do on the save area and hook into > >> JavaThread::oops_do. > >> > >> However even with the Handles version you need "oop maps" for the > >> save areas. It shouldn't be very hard to extract them from the HSAIL > >> compilation but currently they are just thrown away. > >> > >> -Gilles > >> > >> On Fri, Mar 7, 2014 at 2:21 PM, Doug Simon > > >> wrote: > >> > > >> > On Mar 7, 2014, at 1:52 PM, Deneau, Tom > wrote: > >> > > >> >> Doug -- > >> >> > >> >> Regarding your handle-based solution... > >> >> > >> >> would it be sufficient to convert all the saved oops (in all the > >> workitem saved state areas) to Handles before the first javaCall > >> (while we are still in thread_in_vm mode), and then before each > >> javaCall just convert back the one save area that is being used in > that javaCall? > >> > > >> > This javaCall is to the special deopting nmethod if I understand > >> correctly. And the save state area is used solely as input to a deopt > >> instruction in which case there is no possibility of a GC between > >> entering the javaCall and hitting the deopt instruction by which time > >> all oops have been copied from the save state area (i.e., the > >> hsailFrame) to slots in the special deopting method?s frame. At that > >> point, the oops in the save state area are dead and standard GC root > >> scanning knows where to find their copies. If this is all correct, > >> then your suggestion should work. > >> > > >> > -Doug > >> > > >> >>> -----Original Message----- > >> >>> From: Doug Simon [mailto:doug.simon at oracle.com] > >> >>> Sent: Friday, March 07, 2014 4:27 AM > >> >>> To: Deneau, Tom > >> >>> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > >> >>> Subject: Re: suspcions about GC and HSAIL Deopt > >> >>> > >> >>> > >> >>> On Mar 7, 2014, at 12:30 AM, Deneau, Tom > > wrote: > >> >>> > >> >>>> While preparing this webrev for the hsail deoptimization work > >> >>>> we've > >> >>> been doing, I noticed some spurious failures when we run on HSA > >> >>> hardware. I have a theory of what's happening, let me know if > >> >>> this makes sense... > >> >>>> > >> >>>> First the big overview: > >> >>>> > >> >>>> When we run a kernel, and it returns from the GPU each workitem > >> >>>> can be > >> >>> in one of 3 states: > >> >>>> > >> >>>> a) finished normally > >> >>>> b) deopted and saved its state (and set the deopt-happened > >> >>>> flag) > >> >>>> c) on entry, saw deopt-happened=true and so just exited early > >> >>>> without running. > >> >>>> > >> >>>> This last one exists because we don't want to have to allocate > >> >>>> enough > >> >>> deopt save space so that each workitem has its own unique save > >> space. > >> >>>> Instead we only allocate enough for the number of concurrent > >> >>>> workitems > >> >>> possible. > >> >>>> > >> >>>> When we return from the GPU, if one or more workitems deopted > we: > >> >>>> > >> >>>> a) for the workitems that finished normally, there is nothing > >> >>>> to do > >> >>>> > >> >>>> b) for each deopted workitems, we want to run it thru the > >> >>>> interpreter going first thru the special host trampoline > code > >> >>>> infrastructure that Gilles created. The trampoline host > code > >> >>>> takes a deoptId (sort of like a pc, telling where the deopt > >> >>>> occurred in the hsail code) and a pointer to the saved hsail > >> >>>> frame. We currently do this sequentially although other > >> >>>> policies are possible. > >> >>>> > >> >>>> c) for each never ran workitem, we can just run it from the > >> >>>> beginning of the kernel "method", just making sure we pass > the > >> >>>> arguments and the appropriate workitem id for each one. > Again, > >> >>>> we currently do this sequentially although other policies > are > >> >>>> possible. > >> >>>> > >> >>>> When we enter the JVM to run the kernel, we transition to > >> >>>> thread_in_vm > >> >>> mode. So while running on the GPU, no oops are moving (although > >> >>> of course GCs may be delayed). > >> >>>> > >> >>>> When we start looking for workitems of type b or c above, we are > >> >>>> still > >> >>> in thread_in_vm mode. However since both b and c above use the > >> >>> javaCall infrastructure, I believe they are transitioning to > >> >>> thread_in_java mode on each call, and oops can move. > >> >>>> > >> >>>> So if for instance there are two deopting workitems, it is > >> >>>> possible > >> >>> that after executing the first one that the saved deopt state for > >> >>> the second one is no longer valid. > >> >>>> > >> >>>> The junit tests on which I have seen the spurious failures are > >> >>>> ones > >> >>> where lots of workitems deopt. When run in the hotspot debug > >> >>> build, we usually see SEGVs in interpreter code and the access is > >> >>> always to 0xbaadbabe. > >> >>>> > >> >>>> Note that when Gilles was developing his infrastructure, the > >> >>>> only test > >> >>> cases we had all had a single workitem deopting so would not show > >> this. > >> >>> Also even with multi-deopting test cases, I believe the reason we > >> >>> don't see this on the simulator is that the concurrency is much > >> >>> less there so the number of workitems of type b) above will be > much less. > >> >>> On hardware, we can have thousands of workitems deopting. > >> >>>> > >> >>>> I suppose the solution to this is to mark any oops in the deopt > >> >>>> saved > >> >>> state in some way that GC can find them and fix them. What is > >> >>> the best way to do this? > >> >>> > >> >>> I'm not sure it's the most optimal solution, but around each > >> >>> javaCall, you could convert each saved oop to a Handle and > >> >>> convert it back after the call. I'm not aware of other mechanisms > >> >>> in HotSpot for registering GC roots but that doesn't mean they > don't exist. > >> >>> > >> >>>> Or is there any way to execute javaCalls from thread_in_vm mode > >> >>> without allowing GCs to happen? > >> >>> > >> >>> You are calling arbitrary Java code right? That means you cannot > >> >>> guarantee allocation won't be performed which in turn means you > >> >>> cannot disable GC (even though there are mechanisms for doing so > >> >>> like GC_locker::lock_critical/GC_locker::unlock_critical). > >> >>> > >> >>> -Doug > >> >> > >> >> > >> > > > From doug.simon at oracle.com Mon Mar 10 17:03:12 2014 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 10 Mar 2014 18:03:12 +0100 Subject: suspcions about GC and HSAIL Deopt In-Reply-To: References: <661FF05A-0F67-43EE-9281-85C1BA875994@oracle.com> Message-ID: <759DBD3C-1037-4D2F-BB24-F93719E21A66@oracle.com> It?s based on my understanding of what the special deopting method does which is something like: void deoptFromHSAIL(int id, HSAILFrame frame) { if (id == 0) { // copy info out of frame into registers/stack slots Deoptimize(); } else if (id == 1) { // copy info out of frame into registers/stack slots Deoptimize(); } else if ... Gilles can confirm/correct. -Doug On Mar 10, 2014, at 5:53 PM, Deneau, Tom wrote: > Gilles, Doug -- > > > > I was wondering about this statement Doug made... > > > > This javaCall is to the special deopting nmethod if I understand correctly. And the save state area is used solely as input to a deopt instruction in which case there is no possibility of a GC between entering the javaCall and hitting the deopt instruction by which time all oops have been copied from the save state area (i.e., the hsailFrame) to slots in the special deopting method?s frame. > > > > > > Is it true there is no possibility of GC between entering the nmethod and hitting the deopt call/instruction? How is that prevented? > > > > -- Tom > > > >> -----Original Message----- > >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > >> Gilles Duboscq > >> Sent: Monday, March 10, 2014 10:14 AM > >> To: Deneau, Tom > >> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > >> Subject: Re: suspcions about GC and HSAIL Deopt > >> > >> Ok, sounds good > >> > >> On Mon, Mar 10, 2014 at 2:28 PM, Tom Deneau > wrote: > >>> Gilles -- > >>> > >>> Update on this... > >>> > >>> Yes, I put in the code to save the oops maps, currently somewhat > >> simplified in that only hsail $d registers can have oops and we are not > >> saving stack slots yet. > >>> > >>> Using that I implemented a quickie solution that copied the detected > >> oops into a regular java Object array before the first deopt, then > >> reloaded them into the particular frame before each deopt. Logging code > >> did show that there were times when the original value of the oop had > >> changed to a new value and we no longer hit our spurious failures. > >> I'm sure its inefficient when compared to an oops_do approach but it did > >> seem to work. > >>> > >>> I will probably submit the webrev with this quickie solution and we > >> can discuss how to make it use oops_do. > >>> > >>> -- Tom > >>> > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > >>>> Gilles Duboscq > >>>> Sent: Monday, March 10, 2014 7:58 AM > >>>> To: Deneau, Tom > >>>> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > >>>> Subject: Re: suspcions about GC and HSAIL Deopt > >>>> > >>>> Using Handle and restoring the value should work. In the long term we > >>>> may want to just have an opps_do on the save area and hook into > >>>> JavaThread::oops_do. > >>>> > >>>> However even with the Handles version you need "oop maps" for the > >>>> save areas. It shouldn't be very hard to extract them from the HSAIL > >>>> compilation but currently they are just thrown away. > >>>> > >>>> -Gilles > >>>> > >>>> On Fri, Mar 7, 2014 at 2:21 PM, Doug Simon > > >>>> wrote: > >>>>> > >>>>> On Mar 7, 2014, at 1:52 PM, Deneau, Tom > wrote: > >>>>> > >>>>>> Doug -- > >>>>>> > >>>>>> Regarding your handle-based solution... > >>>>>> > >>>>>> would it be sufficient to convert all the saved oops (in all the > >>>> workitem saved state areas) to Handles before the first javaCall > >>>> (while we are still in thread_in_vm mode), and then before each > >>>> javaCall just convert back the one save area that is being used in > >> that javaCall? > >>>>> > >>>>> This javaCall is to the special deopting nmethod if I understand > >>>> correctly. And the save state area is used solely as input to a deopt > >>>> instruction in which case there is no possibility of a GC between > >>>> entering the javaCall and hitting the deopt instruction by which time > >>>> all oops have been copied from the save state area (i.e., the > >>>> hsailFrame) to slots in the special deopting method?s frame. At that > >>>> point, the oops in the save state area are dead and standard GC root > >>>> scanning knows where to find their copies. If this is all correct, > >>>> then your suggestion should work. > >>>>> > >>>>> -Doug > >>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com] > >>>>>>> Sent: Friday, March 07, 2014 4:27 AM > >>>>>>> To: Deneau, Tom > >>>>>>> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > >>>>>>> Subject: Re: suspcions about GC and HSAIL Deopt > >>>>>>> > >>>>>>> > >>>>>>> On Mar 7, 2014, at 12:30 AM, Deneau, Tom > > >> wrote: > >>>>>>> > >>>>>>>> While preparing this webrev for the hsail deoptimization work > >>>>>>>> we've > >>>>>>> been doing, I noticed some spurious failures when we run on HSA > >>>>>>> hardware. I have a theory of what's happening, let me know if > >>>>>>> this makes sense... > >>>>>>>> > >>>>>>>> First the big overview: > >>>>>>>> > >>>>>>>> When we run a kernel, and it returns from the GPU each workitem > >>>>>>>> can be > >>>>>>> in one of 3 states: > >>>>>>>> > >>>>>>>> a) finished normally > >>>>>>>> b) deopted and saved its state (and set the deopt-happened > >>>>>>>> flag) > >>>>>>>> c) on entry, saw deopt-happened=true and so just exited early > >>>>>>>> without running. > >>>>>>>> > >>>>>>>> This last one exists because we don't want to have to allocate > >>>>>>>> enough > >>>>>>> deopt save space so that each workitem has its own unique save > >>>> space. > >>>>>>>> Instead we only allocate enough for the number of concurrent > >>>>>>>> workitems > >>>>>>> possible. > >>>>>>>> > >>>>>>>> When we return from the GPU, if one or more workitems deopted > >> we: > >>>>>>>> > >>>>>>>> a) for the workitems that finished normally, there is nothing > >>>>>>>> to do > >>>>>>>> > >>>>>>>> b) for each deopted workitems, we want to run it thru the > >>>>>>>> interpreter going first thru the special host trampoline > >> code > >>>>>>>> infrastructure that Gilles created. The trampoline host > >> code > >>>>>>>> takes a deoptId (sort of like a pc, telling where the deopt > >>>>>>>> occurred in the hsail code) and a pointer to the saved hsail > >>>>>>>> frame. We currently do this sequentially although other > >>>>>>>> policies are possible. > >>>>>>>> > >>>>>>>> c) for each never ran workitem, we can just run it from the > >>>>>>>> beginning of the kernel "method", just making sure we pass > >> the > >>>>>>>> arguments and the appropriate workitem id for each one. > >> Again, > >>>>>>>> we currently do this sequentially although other policies > >> are > >>>>>>>> possible. > >>>>>>>> > >>>>>>>> When we enter the JVM to run the kernel, we transition to > >>>>>>>> thread_in_vm > >>>>>>> mode. So while running on the GPU, no oops are moving (although > >>>>>>> of course GCs may be delayed). > >>>>>>>> > >>>>>>>> When we start looking for workitems of type b or c above, we are > >>>>>>>> still > >>>>>>> in thread_in_vm mode. However since both b and c above use the > >>>>>>> javaCall infrastructure, I believe they are transitioning to > >>>>>>> thread_in_java mode on each call, and oops can move. > >>>>>>>> > >>>>>>>> So if for instance there are two deopting workitems, it is > >>>>>>>> possible > >>>>>>> that after executing the first one that the saved deopt state for > >>>>>>> the second one is no longer valid. > >>>>>>>> > >>>>>>>> The junit tests on which I have seen the spurious failures are > >>>>>>>> ones > >>>>>>> where lots of workitems deopt. When run in the hotspot debug > >>>>>>> build, we usually see SEGVs in interpreter code and the access is > >>>>>>> always to 0xbaadbabe. > >>>>>>>> > >>>>>>>> Note that when Gilles was developing his infrastructure, the > >>>>>>>> only test > >>>>>>> cases we had all had a single workitem deopting so would not show > >>>> this. > >>>>>>> Also even with multi-deopting test cases, I believe the reason we > >>>>>>> don't see this on the simulator is that the concurrency is much > >>>>>>> less there so the number of workitems of type b) above will be > >> much less. > >>>>>>> On hardware, we can have thousands of workitems deopting. > >>>>>>>> > >>>>>>>> I suppose the solution to this is to mark any oops in the deopt > >>>>>>>> saved > >>>>>>> state in some way that GC can find them and fix them. What is > >>>>>>> the best way to do this? > >>>>>>> > >>>>>>> I'm not sure it's the most optimal solution, but around each > >>>>>>> javaCall, you could convert each saved oop to a Handle and > >>>>>>> convert it back after the call. I'm not aware of other mechanisms > >>>>>>> in HotSpot for registering GC roots but that doesn't mean they > >> don't exist. > >>>>>>> > >>>>>>>> Or is there any way to execute javaCalls from thread_in_vm mode > >>>>>>> without allowing GCs to happen? > >>>>>>> > >>>>>>> You are calling arbitrary Java code right? That means you cannot > >>>>>>> guarantee allocation won't be performed which in turn means you > >>>>>>> cannot disable GC (even though there are mechanisms for doing so > >>>>>>> like GC_locker::lock_critical/GC_locker::unlock_critical). > >>>>>>> > >>>>>>> -Doug > >>>>>> > >>>>>> > >>>>> > >>> > > From tom.deneau at amd.com Mon Mar 10 17:10:12 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 10 Mar 2014 17:10:12 +0000 Subject: suspcions about GC and HSAIL Deopt In-Reply-To: <759DBD3C-1037-4D2F-BB24-F93719E21A66@oracle.com> References: <661FF05A-0F67-43EE-9281-85C1BA875994@oracle.com> <759DBD3C-1037-4D2F-BB24-F93719E21A66@oracle.com> Message-ID: Ah, I was worried about the (admittedly small) window between entering the special deopting method and getting those values safely into register/stack slots, but now I realize there are no safepoints in that window (I hope) so no GC can happen. -- Tom > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Monday, March 10, 2014 12:03 PM > To: Deneau, Tom > Cc: Gilles Duboscq; sumatra-dev at openjdk.java.net; graal- > dev at openjdk.java.net > Subject: Re: suspcions about GC and HSAIL Deopt > > It's based on my understanding of what the special deopting method does > which is something like: > > void deoptFromHSAIL(int id, HSAILFrame frame) { > if (id == 0) { > // copy info out of frame into registers/stack slots > Deoptimize(); > } else if (id == 1) { > // copy info out of frame into registers/stack slots > Deoptimize(); > } else if ... > > Gilles can confirm/correct. > > -Doug > > On Mar 10, 2014, at 5:53 PM, Deneau, Tom wrote: > > > Gilles, Doug -- > > > > > > > > I was wondering about this statement Doug made... > > > > > > > > This javaCall is to the special deopting nmethod if I understand > correctly. And the save state area is used solely as input to a deopt > instruction in which case there is no possibility of a GC between > entering the javaCall and hitting the deopt instruction by which time > all oops have been copied from the save state area (i.e., the > hsailFrame) to slots in the special deopting method's frame. > > > > > > > > > > > > Is it true there is no possibility of GC between entering the nmethod > and hitting the deopt call/instruction? How is that prevented? > > > > > > > > -- Tom > > > > > > > >> -----Original Message----- > > > >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > > > >> Gilles Duboscq > > > >> Sent: Monday, March 10, 2014 10:14 AM > > > >> To: Deneau, Tom > > > >> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net > > > >> Subject: Re: suspcions about GC and HSAIL Deopt > > > >> > > > >> Ok, sounds good > > > >> > > > >> On Mon, Mar 10, 2014 at 2:28 PM, Tom Deneau > > wrote: > > > >>> Gilles -- > > > >>> > > > >>> Update on this... > > > >>> > > > >>> Yes, I put in the code to save the oops maps, currently somewhat > > > >> simplified in that only hsail $d registers can have oops and we are > not > > > >> saving stack slots yet. > > > >>> > > > >>> Using that I implemented a quickie solution that copied the detected > > > >> oops into a regular java Object array before the first deopt, then > > > >> reloaded them into the particular frame before each deopt. Logging > code > > > >> did show that there were times when the original value of the oop had > > > >> changed to a new value and we no longer hit our spurious failures. > > > >> I'm sure its inefficient when compared to an oops_do approach but it > did > > > >> seem to work. > > > >>> > > > >>> I will probably submit the webrev with this quickie solution and we > > > >> can discuss how to make it use oops_do. > > > >>> > > > >>> -- Tom > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: gilwooden at gmail.com > [mailto:gilwooden at gmail.com] On Behalf Of > > > >>>> Gilles Duboscq > > > >>>> Sent: Monday, March 10, 2014 7:58 AM > > > >>>> To: Deneau, Tom > > > >>>> Cc: graal-dev at openjdk.java.net; > sumatra-dev at openjdk.java.net > > > >>>> Subject: Re: suspcions about GC and HSAIL Deopt > > > >>>> > > > >>>> Using Handle and restoring the value should work. In the long term > we > > > >>>> may want to just have an opps_do on the save area and hook into > > > >>>> JavaThread::oops_do. > > > >>>> > > > >>>> However even with the Handles version you need "oop maps" for the > > > >>>> save areas. It shouldn't be very hard to extract them from the > HSAIL > > > >>>> compilation but currently they are just thrown away. > > > >>>> > > > >>>> -Gilles > > > >>>> > > > >>>> On Fri, Mar 7, 2014 at 2:21 PM, Doug Simon > > > > > >>>> wrote: > > > >>>>> > > > >>>>> On Mar 7, 2014, at 1:52 PM, Deneau, Tom > > wrote: > > > >>>>> > > > >>>>>> Doug -- > > > >>>>>> > > > >>>>>> Regarding your handle-based solution... > > > >>>>>> > > > >>>>>> would it be sufficient to convert all the saved oops (in all the > > > >>>> workitem saved state areas) to Handles before the first javaCall > > > >>>> (while we are still in thread_in_vm mode), and then before each > > > >>>> javaCall just convert back the one save area that is being used in > > > >> that javaCall? > > > >>>>> > > > >>>>> This javaCall is to the special deopting nmethod if I understand > > > >>>> correctly. And the save state area is used solely as input to a > deopt > > > >>>> instruction in which case there is no possibility of a GC between > > > >>>> entering the javaCall and hitting the deopt instruction by which > time > > > >>>> all oops have been copied from the save state area (i.e., the > > > >>>> hsailFrame) to slots in the special deopting method's frame. At > that > > > >>>> point, the oops in the save state area are dead and standard GC > root > > > >>>> scanning knows where to find their copies. If this is all correct, > > > >>>> then your suggestion should work. > > > >>>>> > > > >>>>> -Doug > > > >>>>> > > > >>>>>>> -----Original Message----- > > > >>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com] > > > >>>>>>> Sent: Friday, March 07, 2014 4:27 AM > > > >>>>>>> To: Deneau, Tom > > > >>>>>>> Cc: graal-dev at openjdk.java.net dev at openjdk.java.net>; sumatra-dev at openjdk.java.net dev at openjdk.java.net> > > > >>>>>>> Subject: Re: suspcions about GC and HSAIL Deopt > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> On Mar 7, 2014, at 12:30 AM, Deneau, Tom > > > > > >> wrote: > > > >>>>>>> > > > >>>>>>>> While preparing this webrev for the hsail deoptimization work > > > >>>>>>>> we've > > > >>>>>>> been doing, I noticed some spurious failures when we run on HSA > > > >>>>>>> hardware. I have a theory of what's happening, let me know if > > > >>>>>>> this makes sense... > > > >>>>>>>> > > > >>>>>>>> First the big overview: > > > >>>>>>>> > > > >>>>>>>> When we run a kernel, and it returns from the GPU each workitem > > > >>>>>>>> can be > > > >>>>>>> in one of 3 states: > > > >>>>>>>> > > > >>>>>>>> a) finished normally > > > >>>>>>>> b) deopted and saved its state (and set the deopt-happened > > > >>>>>>>> flag) > > > >>>>>>>> c) on entry, saw deopt-happened=true and so just exited early > > > >>>>>>>> without running. > > > >>>>>>>> > > > >>>>>>>> This last one exists because we don't want to have to allocate > > > >>>>>>>> enough > > > >>>>>>> deopt save space so that each workitem has its own unique save > > > >>>> space. > > > >>>>>>>> Instead we only allocate enough for the number of concurrent > > > >>>>>>>> workitems > > > >>>>>>> possible. > > > >>>>>>>> > > > >>>>>>>> When we return from the GPU, if one or more workitems deopted > > > >> we: > > > >>>>>>>> > > > >>>>>>>> a) for the workitems that finished normally, there is nothing > > > >>>>>>>> to do > > > >>>>>>>> > > > >>>>>>>> b) for each deopted workitems, we want to run it thru the > > > >>>>>>>> interpreter going first thru the special host trampoline > > > >> code > > > >>>>>>>> infrastructure that Gilles created. The trampoline host > > > >> code > > > >>>>>>>> takes a deoptId (sort of like a pc, telling where the deopt > > > >>>>>>>> occurred in the hsail code) and a pointer to the saved hsail > > > >>>>>>>> frame. We currently do this sequentially although other > > > >>>>>>>> policies are possible. > > > >>>>>>>> > > > >>>>>>>> c) for each never ran workitem, we can just run it from the > > > >>>>>>>> beginning of the kernel "method", just making sure we pass > > > >> the > > > >>>>>>>> arguments and the appropriate workitem id for each one. > > > >> Again, > > > >>>>>>>> we currently do this sequentially although other policies > > > >> are > > > >>>>>>>> possible. > > > >>>>>>>> > > > >>>>>>>> When we enter the JVM to run the kernel, we transition to > > > >>>>>>>> thread_in_vm > > > >>>>>>> mode. So while running on the GPU, no oops are moving (although > > > >>>>>>> of course GCs may be delayed). > > > >>>>>>>> > > > >>>>>>>> When we start looking for workitems of type b or c above, we > are > > > >>>>>>>> still > > > >>>>>>> in thread_in_vm mode. However since both b and c above use the > > > >>>>>>> javaCall infrastructure, I believe they are transitioning to > > > >>>>>>> thread_in_java mode on each call, and oops can move. > > > >>>>>>>> > > > >>>>>>>> So if for instance there are two deopting workitems, it is > > > >>>>>>>> possible > > > >>>>>>> that after executing the first one that the saved deopt state > for > > > >>>>>>> the second one is no longer valid. > > > >>>>>>>> > > > >>>>>>>> The junit tests on which I have seen the spurious failures are > > > >>>>>>>> ones > > > >>>>>>> where lots of workitems deopt. When run in the hotspot debug > > > >>>>>>> build, we usually see SEGVs in interpreter code and the access > is > > > >>>>>>> always to 0xbaadbabe. > > > >>>>>>>> > > > >>>>>>>> Note that when Gilles was developing his infrastructure, the > > > >>>>>>>> only test > > > >>>>>>> cases we had all had a single workitem deopting so would not > show > > > >>>> this. > > > >>>>>>> Also even with multi-deopting test cases, I believe the reason > we > > > >>>>>>> don't see this on the simulator is that the concurrency is much > > > >>>>>>> less there so the number of workitems of type b) above will be > > > >> much less. > > > >>>>>>> On hardware, we can have thousands of workitems deopting. > > > >>>>>>>> > > > >>>>>>>> I suppose the solution to this is to mark any oops in the deopt > > > >>>>>>>> saved > > > >>>>>>> state in some way that GC can find them and fix them. What is > > > >>>>>>> the best way to do this? > > > >>>>>>> > > > >>>>>>> I'm not sure it's the most optimal solution, but around each > > > >>>>>>> javaCall, you could convert each saved oop to a Handle and > > > >>>>>>> convert it back after the call. I'm not aware of other > mechanisms > > > >>>>>>> in HotSpot for registering GC roots but that doesn't mean they > > > >> don't exist. > > > >>>>>>> > > > >>>>>>>> Or is there any way to execute javaCalls from thread_in_vm mode > > > >>>>>>> without allowing GCs to happen? > > > >>>>>>> > > > >>>>>>> You are calling arbitrary Java code right? That means you cannot > > > >>>>>>> guarantee allocation won't be performed which in turn means you > > > >>>>>>> cannot disable GC (even though there are mechanisms for doing so > > > >>>>>>> like GC_locker::lock_critical/GC_locker::unlock_critical). > > > >>>>>>> > > > >>>>>>> -Doug > > > >>>>>> > > > >>>>>> > > > >>>>> > > > >>> > > > > > From duboscq at ssw.jku.at Mon Mar 10 17:45:34 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Mon, 10 Mar 2014 18:45:34 +0100 Subject: suspcions about GC and HSAIL Deopt In-Reply-To: References: <661FF05A-0F67-43EE-9281-85C1BA875994@oracle.com> <759DBD3C-1037-4D2F-BB24-F93719E21A66@oracle.com> Message-ID: On Mon, Mar 10, 2014 at 6:10 PM, Tom Deneau wrote: > Ah, I was worried about the (admittedly small) window between entering the special deopting method and getting those values safely into register/stack slots, but now I realize there are no safepoints in that window (I hope) so no GC can happen. Yes exactly > > -- Tom > >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Monday, March 10, 2014 12:03 PM >> To: Deneau, Tom >> Cc: Gilles Duboscq; sumatra-dev at openjdk.java.net; graal- >> dev at openjdk.java.net >> Subject: Re: suspcions about GC and HSAIL Deopt >> >> It's based on my understanding of what the special deopting method does >> which is something like: >> >> void deoptFromHSAIL(int id, HSAILFrame frame) { >> if (id == 0) { >> // copy info out of frame into registers/stack slots >> Deoptimize(); >> } else if (id == 1) { >> // copy info out of frame into registers/stack slots >> Deoptimize(); >> } else if ... >> >> Gilles can confirm/correct. >> >> -Doug >> >> On Mar 10, 2014, at 5:53 PM, Deneau, Tom wrote: >> >> > Gilles, Doug -- >> > >> > >> > >> > I was wondering about this statement Doug made... >> > >> > >> > >> > This javaCall is to the special deopting nmethod if I understand >> correctly. And the save state area is used solely as input to a deopt >> instruction in which case there is no possibility of a GC between >> entering the javaCall and hitting the deopt instruction by which time >> all oops have been copied from the save state area (i.e., the >> hsailFrame) to slots in the special deopting method's frame. >> > >> > >> > >> > >> > >> > Is it true there is no possibility of GC between entering the nmethod >> and hitting the deopt call/instruction? How is that prevented? >> > >> > >> > >> > -- Tom >> > >> > >> > >> >> -----Original Message----- >> > >> >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of >> > >> >> Gilles Duboscq >> > >> >> Sent: Monday, March 10, 2014 10:14 AM >> > >> >> To: Deneau, Tom >> > >> >> Cc: graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net >> > >> >> Subject: Re: suspcions about GC and HSAIL Deopt >> > >> >> >> > >> >> Ok, sounds good >> > >> >> >> > >> >> On Mon, Mar 10, 2014 at 2:28 PM, Tom Deneau >> > wrote: >> > >> >>> Gilles -- >> > >> >>> >> > >> >>> Update on this... >> > >> >>> >> > >> >>> Yes, I put in the code to save the oops maps, currently somewhat >> > >> >> simplified in that only hsail $d registers can have oops and we are >> not >> > >> >> saving stack slots yet. >> > >> >>> >> > >> >>> Using that I implemented a quickie solution that copied the detected >> > >> >> oops into a regular java Object array before the first deopt, then >> > >> >> reloaded them into the particular frame before each deopt. Logging >> code >> > >> >> did show that there were times when the original value of the oop had >> > >> >> changed to a new value and we no longer hit our spurious failures. >> > >> >> I'm sure its inefficient when compared to an oops_do approach but it >> did >> > >> >> seem to work. >> > >> >>> >> > >> >>> I will probably submit the webrev with this quickie solution and we >> > >> >> can discuss how to make it use oops_do. >> > >> >>> >> > >> >>> -- Tom >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>>> -----Original Message----- >> > >> >>>> From: gilwooden at gmail.com >> [mailto:gilwooden at gmail.com] On Behalf Of >> > >> >>>> Gilles Duboscq >> > >> >>>> Sent: Monday, March 10, 2014 7:58 AM >> > >> >>>> To: Deneau, Tom >> > >> >>>> Cc: graal-dev at openjdk.java.net; >> sumatra-dev at openjdk.java.net >> > >> >>>> Subject: Re: suspcions about GC and HSAIL Deopt >> > >> >>>> >> > >> >>>> Using Handle and restoring the value should work. In the long term >> we >> > >> >>>> may want to just have an opps_do on the save area and hook into >> > >> >>>> JavaThread::oops_do. >> > >> >>>> >> > >> >>>> However even with the Handles version you need "oop maps" for the >> > >> >>>> save areas. It shouldn't be very hard to extract them from the >> HSAIL >> > >> >>>> compilation but currently they are just thrown away. >> > >> >>>> >> > >> >>>> -Gilles >> > >> >>>> >> > >> >>>> On Fri, Mar 7, 2014 at 2:21 PM, Doug Simon >> > >> > >> >>>> wrote: >> > >> >>>>> >> > >> >>>>> On Mar 7, 2014, at 1:52 PM, Deneau, Tom >> > wrote: >> > >> >>>>> >> > >> >>>>>> Doug -- >> > >> >>>>>> >> > >> >>>>>> Regarding your handle-based solution... >> > >> >>>>>> >> > >> >>>>>> would it be sufficient to convert all the saved oops (in all the >> > >> >>>> workitem saved state areas) to Handles before the first javaCall >> > >> >>>> (while we are still in thread_in_vm mode), and then before each >> > >> >>>> javaCall just convert back the one save area that is being used in >> > >> >> that javaCall? >> > >> >>>>> >> > >> >>>>> This javaCall is to the special deopting nmethod if I understand >> > >> >>>> correctly. And the save state area is used solely as input to a >> deopt >> > >> >>>> instruction in which case there is no possibility of a GC between >> > >> >>>> entering the javaCall and hitting the deopt instruction by which >> time >> > >> >>>> all oops have been copied from the save state area (i.e., the >> > >> >>>> hsailFrame) to slots in the special deopting method's frame. At >> that >> > >> >>>> point, the oops in the save state area are dead and standard GC >> root >> > >> >>>> scanning knows where to find their copies. If this is all correct, >> > >> >>>> then your suggestion should work. >> > >> >>>>> >> > >> >>>>> -Doug >> > >> >>>>> >> > >> >>>>>>> -----Original Message----- >> > >> >>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com] >> > >> >>>>>>> Sent: Friday, March 07, 2014 4:27 AM >> > >> >>>>>>> To: Deneau, Tom >> > >> >>>>>>> Cc: graal-dev at openjdk.java.net> dev at openjdk.java.net>; sumatra-dev at openjdk.java.net> dev at openjdk.java.net> >> > >> >>>>>>> Subject: Re: suspcions about GC and HSAIL Deopt >> > >> >>>>>>> >> > >> >>>>>>> >> > >> >>>>>>> On Mar 7, 2014, at 12:30 AM, Deneau, Tom >> > >> > >> >> wrote: >> > >> >>>>>>> >> > >> >>>>>>>> While preparing this webrev for the hsail deoptimization work >> > >> >>>>>>>> we've >> > >> >>>>>>> been doing, I noticed some spurious failures when we run on HSA >> > >> >>>>>>> hardware. I have a theory of what's happening, let me know if >> > >> >>>>>>> this makes sense... >> > >> >>>>>>>> >> > >> >>>>>>>> First the big overview: >> > >> >>>>>>>> >> > >> >>>>>>>> When we run a kernel, and it returns from the GPU each workitem >> > >> >>>>>>>> can be >> > >> >>>>>>> in one of 3 states: >> > >> >>>>>>>> >> > >> >>>>>>>> a) finished normally >> > >> >>>>>>>> b) deopted and saved its state (and set the deopt-happened >> > >> >>>>>>>> flag) >> > >> >>>>>>>> c) on entry, saw deopt-happened=true and so just exited early >> > >> >>>>>>>> without running. >> > >> >>>>>>>> >> > >> >>>>>>>> This last one exists because we don't want to have to allocate >> > >> >>>>>>>> enough >> > >> >>>>>>> deopt save space so that each workitem has its own unique save >> > >> >>>> space. >> > >> >>>>>>>> Instead we only allocate enough for the number of concurrent >> > >> >>>>>>>> workitems >> > >> >>>>>>> possible. >> > >> >>>>>>>> >> > >> >>>>>>>> When we return from the GPU, if one or more workitems deopted >> > >> >> we: >> > >> >>>>>>>> >> > >> >>>>>>>> a) for the workitems that finished normally, there is nothing >> > >> >>>>>>>> to do >> > >> >>>>>>>> >> > >> >>>>>>>> b) for each deopted workitems, we want to run it thru the >> > >> >>>>>>>> interpreter going first thru the special host trampoline >> > >> >> code >> > >> >>>>>>>> infrastructure that Gilles created. The trampoline host >> > >> >> code >> > >> >>>>>>>> takes a deoptId (sort of like a pc, telling where the deopt >> > >> >>>>>>>> occurred in the hsail code) and a pointer to the saved hsail >> > >> >>>>>>>> frame. We currently do this sequentially although other >> > >> >>>>>>>> policies are possible. >> > >> >>>>>>>> >> > >> >>>>>>>> c) for each never ran workitem, we can just run it from the >> > >> >>>>>>>> beginning of the kernel "method", just making sure we pass >> > >> >> the >> > >> >>>>>>>> arguments and the appropriate workitem id for each one. >> > >> >> Again, >> > >> >>>>>>>> we currently do this sequentially although other policies >> > >> >> are >> > >> >>>>>>>> possible. >> > >> >>>>>>>> >> > >> >>>>>>>> When we enter the JVM to run the kernel, we transition to >> > >> >>>>>>>> thread_in_vm >> > >> >>>>>>> mode. So while running on the GPU, no oops are moving (although >> > >> >>>>>>> of course GCs may be delayed). >> > >> >>>>>>>> >> > >> >>>>>>>> When we start looking for workitems of type b or c above, we >> are >> > >> >>>>>>>> still >> > >> >>>>>>> in thread_in_vm mode. However since both b and c above use the >> > >> >>>>>>> javaCall infrastructure, I believe they are transitioning to >> > >> >>>>>>> thread_in_java mode on each call, and oops can move. >> > >> >>>>>>>> >> > >> >>>>>>>> So if for instance there are two deopting workitems, it is >> > >> >>>>>>>> possible >> > >> >>>>>>> that after executing the first one that the saved deopt state >> for >> > >> >>>>>>> the second one is no longer valid. >> > >> >>>>>>>> >> > >> >>>>>>>> The junit tests on which I have seen the spurious failures are >> > >> >>>>>>>> ones >> > >> >>>>>>> where lots of workitems deopt. When run in the hotspot debug >> > >> >>>>>>> build, we usually see SEGVs in interpreter code and the access >> is >> > >> >>>>>>> always to 0xbaadbabe. >> > >> >>>>>>>> >> > >> >>>>>>>> Note that when Gilles was developing his infrastructure, the >> > >> >>>>>>>> only test >> > >> >>>>>>> cases we had all had a single workitem deopting so would not >> show >> > >> >>>> this. >> > >> >>>>>>> Also even with multi-deopting test cases, I believe the reason >> we >> > >> >>>>>>> don't see this on the simulator is that the concurrency is much >> > >> >>>>>>> less there so the number of workitems of type b) above will be >> > >> >> much less. >> > >> >>>>>>> On hardware, we can have thousands of workitems deopting. >> > >> >>>>>>>> >> > >> >>>>>>>> I suppose the solution to this is to mark any oops in the deopt >> > >> >>>>>>>> saved >> > >> >>>>>>> state in some way that GC can find them and fix them. What is >> > >> >>>>>>> the best way to do this? >> > >> >>>>>>> >> > >> >>>>>>> I'm not sure it's the most optimal solution, but around each >> > >> >>>>>>> javaCall, you could convert each saved oop to a Handle and >> > >> >>>>>>> convert it back after the call. I'm not aware of other >> mechanisms >> > >> >>>>>>> in HotSpot for registering GC roots but that doesn't mean they >> > >> >> don't exist. >> > >> >>>>>>> >> > >> >>>>>>>> Or is there any way to execute javaCalls from thread_in_vm mode >> > >> >>>>>>> without allowing GCs to happen? >> > >> >>>>>>> >> > >> >>>>>>> You are calling arbitrary Java code right? That means you cannot >> > >> >>>>>>> guarantee allocation won't be performed which in turn means you >> > >> >>>>>>> cannot disable GC (even though there are mechanisms for doing so >> > >> >>>>>>> like GC_locker::lock_critical/GC_locker::unlock_critical). >> > >> >>>>>>> >> > >> >>>>>>> -Doug >> > >> >>>>>> >> > >> >>>>>> >> > >> >>>>> >> > >> >>> >> > >> > >> > > From doug.simon at oracle.com Mon Mar 10 18:05:02 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Mon, 10 Mar 2014 18:05:02 +0000 Subject: hg: graal/graal: 24 new changesets Message-ID: <201403101805.s2AI5WIN010554@aojmv0008> Changeset: 2ec05c3f773b Author: Tom Rodriguez Date: 2014-03-06 18:41 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/2ec05c3f773b fix overzeroing of new storage, refactor zeroing and unroll zeroing of small arrays ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.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.word/src/com/oracle/graal/word/Pointer.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/Word.java Changeset: 43a80ad2730a Author: Tom Rodriguez Date: 2014-03-06 18:41 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/43a80ad2730a rename BeginEnqueue to Enqueueing ! 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: 9d8aaa3200a3 Author: Tom Rodriguez Date: 2014-03-06 18:43 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/9d8aaa3200a3 make mx respect umask when making jar files ! mxtool/mx.py Changeset: a38a54030ea2 Author: twisti Date: 2014-03-06 21:03 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/a38a54030ea2 pass metaspace pointers instead of object to VM ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.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/HotSpotCodeCacheProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalCodeInstaller.hpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalCompilerToVM.hpp Changeset: f62c770c22be Author: twisti Date: 2014-03-06 22:40 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/f62c770c22be make HotSpotResolvedJavaMethod leaner ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalJavaAccess.hpp Changeset: ca37cb080dad Author: twisti Date: 2014-03-06 22:45 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/ca37cb080dad reorganized graalCompilerToVM.cpp ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 800057208a2c Author: Tom Rodriguez Date: 2014-03-06 17:11 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/800057208a2c enable C1 + Graal tiered ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! make/bsd/makefiles/graal.make ! make/bsd/makefiles/vm.make ! src/cpu/sparc/vm/graalGlobals_sparc.hpp ! src/cpu/x86/vm/graalGlobals_x86.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalEnv.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/macros.hpp Changeset: 98d38009bb2b Author: Bernhard Urban Date: 2014-03-07 09:23 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/98d38009bb2b TruffleCompiler: fix corner case in format string ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java Changeset: 85969b1aba78 Author: Gilles Duboscq Date: 2014-03-06 18:13 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/85969b1aba78 Use a forceLog scope for LinearScan.reportFailure. Remove @SuppressWarnings on DebugScope.scope ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugScope.java Changeset: e55082b1e727 Author: Gilles Duboscq Date: 2014-03-06 18:21 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e55082b1e727 During LoopFragment.mergeEarlyExits we need to update the orignal fragement's nodes bitmap ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java Changeset: 6205f565e230 Author: Gilles Duboscq Date: 2014-03-07 11:37 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6205f565e230 Remove useless code in LoopFragment.mergeEarlyExits ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java Changeset: 317bfc1ae64e Author: Gilles Duboscq Date: 2014-03-07 10:27 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/317bfc1ae64e CanonicalizerPhase: cosmetic simplification in performReplacement ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CanonicalizerPhase.java Changeset: 3b7a34962396 Author: Doug Simon Date: 2014-03-07 13:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3b7a34962396 enable C1 + Graal tiered (added Linux and Solaris support) ! make/linux/makefiles/graal.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/graal.make ! make/solaris/makefiles/vm.make Changeset: 2bb17229c0d7 Author: Bernhard Urban Date: 2014-03-07 13:55 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2bb17229c0d7 solaris: exclude gpu if graal is not used ! make/solaris/makefiles/vm.make Changeset: ed7893cae86f Author: Roland Schatz Date: 2014-03-07 19:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ed7893cae86f Check for abstract modifier in NodeIntrinsic verification. ! graal/com.oracle.graal.replacements.verifier/src/com/oracle/graal/replacements/verifier/NodeIntrinsicVerifier.java Changeset: be7ebdf41bea Author: Christian Wimmer Date: 2014-03-07 11:44 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/be7ebdf41bea mx: new command to start c1visualizer; support for IGV download when using a proxy server ! mx/mx_graal.py Changeset: 2b2f0022900f Author: Doug Simon Date: 2014-03-08 10:04 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2b2f0022900f removed unnecessary lookupKlassByName method ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotConstantPool.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 380984cdb29d Author: Doug Simon Date: 2014-03-08 10:05 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/380984cdb29d fixed incorrect test for null ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionProcessor.java Changeset: c1b0b02a6528 Author: Andreas Woess Date: 2014-03-09 20:25 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c1b0b02a6528 windows: enable C1+Graal tiered ! make/windows/makefiles/projectcreator.make Changeset: 158dcef18506 Author: Andreas Woess Date: 2014-03-09 20:26 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/158dcef18506 windows: enable C1+C2 tiered ! make/windows/makefiles/projectcreator.make Changeset: 0ddb3b3665bd Author: Roland Schatz Date: 2014-03-10 11:38 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0ddb3b3665bd Backed out changeset: 38c881305352 ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/MoveResolver.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/PTXFrameMap.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/LIR.java Changeset: 2a7d7da912e1 Author: Roland Schatz Date: 2014-03-10 13:32 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2a7d7da912e1 Don't narrow NarrowableArithmetic by default. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerConvertNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/NarrowNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/SignExtendNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ZeroExtendNode.java Changeset: dc41eab09fe8 Author: Bernhard Urban Date: 2014-03-10 16:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/dc41eab09fe8 gate: add non-tiered bootstrap ! mx/mx_graal.py Changeset: 7ad529321294 Author: Bernhard Urban Date: 2014-03-10 16:26 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7ad529321294 make: remove GRAALVM and introduce COMPILERGRAAL. fix client hosted-mode ! make/bsd/makefiles/graal.make ! make/linux/makefiles/graal.make ! make/solaris/makefiles/graal.make ! make/windows/makefiles/projectcreator.make ! src/cpu/sparc/vm/graalGlobals_sparc.hpp ! src/cpu/x86/vm/graalGlobals_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalGlobals.hpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/macros.hpp From java at stefan-marr.de Mon Mar 10 18:14:48 2014 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 10 Mar 2014 19:14:48 +0100 Subject: TruffleSOM Update and Issues with Splitting In-Reply-To: References: Message-ID: <87F0F53B-48FC-408F-8DC9-46733F4065F8@stefan-marr.de> Hi: After deactivating splitting (see previous mail below), I am finally getting somewhere with the performance of TruffleSOM. See the attached comparison on microbenchmarks, DeltaBlue, and Richards. RTruffleSOM is a simplified version of TruffleSOM ported to RPython. It doesn?t do much of the specialization TruffleSOM includes, but with the meta-tracer it still has an edge. Some of the benchmarks on top of TruffleSOM are still pretty slow. And for the method dispatch for instance, I hope it can still be improved but I don?t have a good idea how to do that yet. I was experimenting before with custom inlining of simple object field reads, returning arguments, or constants, but that is not yet back in this version. Such inlining would avoid many of the nodes for frame initialization. And avoiding them seems to help especially for simple operations such as addition. As an overview of the current status, TruffleSOM includes the following: - message sends are design after SimpleLanguage - reads/writes of frame slots are specialized for int, double, and Object - control structures are optimized with special nodes replacing plain message sends - a subset of the primitive operations is eagerly placed as direct expression nodes in the execution tree to avoid overhead of message sends and general inline caches - lexical scopes are handled via materialized frames - CallNodes are used to realize inlining - frame slots are specialized separately in different method copies - nested methods/blocks are copied as soon as outer method is copied to allow for their specialization in the correct context - loop counts are reported via the LoopCountReceiver interface - primitive operations are specialized using the TruffleDSL and there are probably other things that might be relevant. Now my main question is what other kind of optimizations are typically done in Truffle languages. One issue I am seeing is that the SOM objects are requiring SOM objects to be stored in their fields. I probably could still loosen that requirement, but wonder whether the optimizer will then be able to eliminate unnecessary store and read operations. Currently, it doesn?t seem to do that, and as a result, the FieldRead benchmark is about a magnitude slow than it should be. Are there other interesting optimizations I could still try? Thanks Stefan On 10 Mar 2014, at 12:23, Stefan Marr wrote: > == Execution Tree is not stabilizing with splitting: > > With splitting is enabled, only a handful of benchmarks stabilize. > Things like the simple WhileLoop benchmark, but also Richards and DeltaBlue seem to be ok. > > Highly recursive benchmarks such as Fibonacci seem to be problematic. > After a while, I get for Fibonacci output like the one below [3]. > I don?t see any specialization going on anymore, instead I see those ?inline success? reports perpetually. > I am not sure what to make of that. What exactly is indicated by this message? > Are the tree copies, i.e., splitted copies gradually inlined? Could it indicate that an upper limit on inlining doesn?t trigger while it probably should? > Any hints what that could mean are highly appreciate! > > Thanks > Stefan > > > > [1] https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/nary/EagerBinaryPrimitiveNode.java#L47 > [2] https://github.com/SOM-st/TruffleSOM/commit/3f01afebfbf603e21519c608beff201af3d11a90 > > [3] Output for Fibonacci: > > [truffle] opt done Method Fibonacci>>#$block method:Examples/Benchmarks//Fibonacci.som:38 at 3a507beb |ASTSize 1482 (0/109) |Time 797( 648+149 )ms |Nodes 1246/ 1323 |CodeSize 6768 |Source Examples/Benchmarks//Fibonacci.som:38 > [truffle] inline success Method Fibonacci>>#fibonacci::Examples/Benchmarks//Fibonacci.som:37 at 23877e40 |ASTSize 16 (0/2) |shallowCount 16 |currentCount 54 |inlinedTotalCount 86 |score 0.06 |frequency 1.00 |callCount 1000 > [truffle] inline success Method Fibonacci>>#fibonacci::Examples/Benchmarks//Fibonacci.som:37 at 2ede6d8e |ASTSize 16 (0/2) |shallowCount 16 |currentCount 86 |inlinedTotalCount 118 |score 0.06 |frequency 1.00 |callCount 1000 > [truffle] inline success Method Fibonacci>>#$block method:Examples/Benchmarks//Fibonacci.som:38 at 1fc40e10 |ASTSize 54 (0/1) |shallowCount 54 |currentCount 118 |inlinedTotalCount 226 |score 0.02 |frequency 1.00 |callCount 999 > [truffle] inline success Method Fibonacci>>#fibonacci::Examples/Benchmarks//Fibonacci.som:37 at 7895b698 |ASTSize 16 (0/2) |shallowCount 16 |currentCount 226 |inlinedTotalCount 290 |score 0.06 |frequency 1.00 |callCount 998 > [truffle] inline success Method Fibonacci>>#fibonacci::Examples/Benchmarks//Fibonacci.som:37 at e424bba |ASTSize 16 (0/2) |shallowCount 16 |currentCount 290 |inlinedTotalCount 354 |score 0.06 |frequency 1.00 |callCount 998 > [truffle] inline success Method Fibonacci>>#$block method:Examples/Benchmarks//Fibonacci.som:38 at 89ab152 |ASTSize 54 (0/1) |shallowCount 54 |currentCount 354 |inlinedTotalCount 570 |score 0.02 |frequency 1.00 |callCount 997 > [truffle] inline success Method Fibonacci>>#fibonacci::Examples/Benchmarks//Fibonacci.som:37 at 4203f936 |ASTSize 16 (0/2) |shallowCount 16 |currentCount 570 |inlinedTotalCount 698 |score 0.06 |frequency 1.00 |callCount 996 > [truffle] inline success Method Fibonacci>>#fibonacci::Examples/Benchmarks//Fibonacci.som:37 at 30cd607d |ASTSize 16 (0/2) |shallowCount 16 |currentCount 698 |inlinedTotalCount 826 |score 0.06 |frequency 1.00 |callCount 996 > [truffle] inline success Method Fibonacci>>#$block method:Examples/Benchmarks//Fibonacci.som:38 at c20f79c|ASTSize 15 (0/1) |shallowCount 15 |currentCount 826 |inlinedTotalCount 946 |score NaN |frequency NaN |callCount 0 > [truffle] inline success Method Fibonacci>>#$block method:Examples/Benchmarks//Fibonacci.som:38 at 3a3e575d |ASTSize 54 (0/1) |shallowCount 54 |currentCount 946 |inlinedTotalCount 1054 |score 0.02 |frequency 1.00 |callCount 999 > [truffle] inline success Method Fibonacci>>#fibonacci::Examples/Benchmarks//Fibonacci.som:37 at 32579775 |ASTSize 16 (0/2) |shallowCount 16 |currentCount 1054 |inlinedTotalCount 1118 |score 0.06 |frequency 1.00 |callCount 998 > [truffle] inline success Method Fibonacci>>#fibonacci::Examples/Benchmarks//Fibonacci.som:37 at 4acce36b |ASTSize 16 (0/2) |shallowCount 16 |currentCount 1118 |inlinedTotalCount 1182 |score 0.06 |frequency 1.00 |callCount 998 > [truffle] inline success Method Fibonacci>>#$block method:Examples/Benchmarks//Fibonacci.som:38 at 55766e96|ASTSize 15 (0/1) |shallowCount 15 |currentCount 1182 |inlinedTotalCount 1242 |score NaN |frequency NaN |callCount 0 > [truffle] inline success Method Fibonacci>>#$block method:Examples/Benchmarks//Fibonacci.som:38 at 23d9bebe |ASTSize 54 (0/1) |shallowCount 54 |currentCount 1242 |inlinedTotalCount 1674 |score 0.02 |frequency 1.00 |callCount 995 > [truffle] inline success Method Fibonacci>>#fibonacci::Examples/Benchmarks//Fibonacci.som:37 at 313a51b |ASTSize 16 (0/2) |shallowCount 16 |currentCount 1674 |inlinedTotalCount 1930 |score 0.06 |frequency 1.00 |callCount 994 > [truffle] inline success Method Fibonacci>>#$block method:Examples/Benchmarks//Fibonacci.som:38 at 5c07f072|ASTSize 15 (0/1) |shallowCount 15 |currentCount 1930 |inlinedTotalCount 2170 |score NaN |frequency NaN |callCount 0 > [truffle] opt queued Method Fibonacci>>#$block method:Examples/Benchmarks//Fibonacci.som:38 at 4d27d539 |ASTSize 2170 (0/149) |C/T 1000/ 1001 |L/T 1000/ 1010 |Inval#/Replace# 0/ 38 > [truffle] opt start Method Fibonacci>>#$block method:Examples/Benchmarks//Fibonacci.som:38 at 4d27d539 |ASTSize 2170 (0/149) |C/T 1000/ 1001 |L/T 1000/ 1010 |Inval#/Replace# 0/ 38 > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From doug.simon at oracle.com Tue Mar 11 02:00:05 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 11 Mar 2014 02:00:05 +0000 Subject: hg: graal/graal: implement initial security model for Graal (JBS:GRAAL-22) Message-ID: <201403110200.s2B207io023214@aojmv0008> Changeset: e09829e6680f Author: Doug Simon Date: 2014-03-10 18:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e09829e6680f implement initial security model for Graal (JBS:GRAAL-22) ! graal/com.oracle.graal.api.runtime/src/com/oracle/graal/api/runtime/Graal.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java From bharadwaj.yadavalli at oracle.com Tue Mar 11 15:58:11 2014 From: bharadwaj.yadavalli at oracle.com (S. Bharadwaj Yadavalli) Date: Tue, 11 Mar 2014 11:58:11 -0400 Subject: Moving GPU offload policy into Java sources In-Reply-To: References: <531A347B.4030906@oracle.com> <581921E1-8E90-46FD-9635-A6BDBEE12A8C@oracle.com> <531A380B.7040608@oracle.com> <6ED7D40E-56A8-4EE3-A66D-A2132AB734EE@oracle.com> <531DD592.2050806@oracle.com> Message-ID: <531F3293.5040701@oracle.com> Doug, On 03/10/2014 11:58 AM, Doug Simon wrote: > So, I think we agree on the worthy goal of automatic GPU offload. I just think this is best done within a compilation. Assuming you still think the required analysis is best done outside of compilation, can you describe how it can be done (efficiently) and what mechanisms it would use? I do not yet have the full algorithm / technique chalked out. GPU/non-host offload decision making at runtime is an area that I have been trying to experiment with and have been trying to understand in the context of a JVM. Roughly speaking, the idea is to recognize parallel application of lambda methods and offload such application to GPU - when deemed beneficial. More concretely, I am currently looking at the possibility of recognizing the characteristics of a stream pipeline by the VM runtime (assuming current Streams.parallel() - the parallel streams pipeline - implementation can be rendered for SIMD execution). I would like to see if I can use information such as size of data, composability of functions being applied in the pipeline (may be others, I do not know, yet) can be used to make the offload decision. Bharadwaj From doug.simon at oracle.com Tue Mar 11 16:15:46 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 11 Mar 2014 17:15:46 +0100 Subject: Moving GPU offload policy into Java sources In-Reply-To: <531F3293.5040701@oracle.com> References: <531A347B.4030906@oracle.com> <581921E1-8E90-46FD-9635-A6BDBEE12A8C@oracle.com> <531A380B.7040608@oracle.com> <6ED7D40E-56A8-4EE3-A66D-A2132AB734EE@oracle.com> <531DD592.2050806@oracle.com> <531F3293.5040701@oracle.com> Message-ID: On Mar 11, 2014, at 4:58 PM, S. Bharadwaj Yadavalli wrote: > Doug, > > On 03/10/2014 11:58 AM, Doug Simon wrote: >> So, I think we agree on the worthy goal of automatic GPU offload. I just think this is best done within a compilation. Assuming you still think the required analysis is best done outside of compilation, can you describe how it can be done (efficiently) and what mechanisms it would use? > > I do not yet have the full algorithm / technique chalked out. GPU/non-host offload decision making at runtime is an area that I have been trying to experiment with and have been trying to understand in the context of a JVM. Roughly speaking, the idea is to recognize parallel application of lambda methods and offload such application to GPU - when deemed beneficial. More concretely, I am currently looking at the possibility of recognizing the characteristics of a stream pipeline by the VM runtime (assuming current Streams.parallel() - the parallel streams pipeline - implementation can be rendered for SIMD execution). I would like to see if I can use information such as size of data, composability of functions being applied in the pipeline (may be others, I do not know, yet) can be used to make the offload decision. Thanks for the explanation. So, if I understand correctly, the decision making you describe would be done: 1. in modified library code (i.e., current Sumatra approach), 2. during compilation, or 3. class file loading One place it should not be done is when deciding whether or not to compile a method as it would be too slow and would involve duplicating machinery used by one of the above. As such, we should still proceed with removing the GPU offloading decision logic from the logic of deciding whether or not to compile a method. -Doug From tom.deneau at amd.com Tue Mar 11 20:08:33 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 11 Mar 2014 20:08:33 +0000 Subject: webrev for hsail deoptimization Message-ID: I have placed a webrev up at http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt which we would like to get checked into the graal trunk. This consists of at least the start of support for deoptimization in HSAIL kernels. Although the list of files changed may look long, many of the files have only a few lines changed. Special thanks to Gilles Duboscq and Doug Simon who provided some of the infrastructure that this webrev uses. Below I have described * an overview of the codepaths the data structures * java and hotspot source changes Deoptimization Data Structures and Overview =========================================== At kernel dispatch time, we allocate space for any workitems should want to deopt. To reduce the space requirements, space is only reserved for the maximum number of possible concurrent workitems that could be running on that hsa device. A deopting workitem sets a "deopt happened" flag, and future workitems that see "deopt happened" as true will just set a flag saying they never ran and exit early. Currently the never_ran array is one per workitem. We are looking at ways to make this smaller but HSA devices have a lot of freedom in how they schedule workitems (current hardware and the simulator are quite different). Workitems that deopt atomically bump an index saying where they should store their deopt data. The deopt data consists of * workitemid * deopt actionAndReason * the first HSAILFrame An HSAILFrame consists of * the deoptId or "pc" offset where the deopt occurred * number of s registers * number of d registers * a bitmap indicating which d registers are oops * space for saving the d and s registers Currently we always set num_s_registers to 32 and num_d_registers to 16 but in the hsail code of the kernel we only save the union of the actual registers that are live at any of the infopoints. On return from the GPU, we check if there were any deopts. If not, we just return back to java. If there was at least one deopt then a) for the workitems that finished normally, there is nothing to do b) if there are any deopted workitems, we want to run each deopting workitem thru the interpreter going first thru the special host trampoline code infrastructure that Gilles created. The trampoline host code takes the deoptId and a pointer to the saved hsail frame. We currently do this sequentially although other policies are possible. c) for each never ran workitem, we can just run it from the beginning of the kernel "method", just making sure we pass the arguments and the appropriate workitem id for each one. Again, we currently do this sequentially although other policies are possible. Because running either type b or c above can cause GCs, and because some of our saved d registers are pointers into the java heap, we take care in case any of these saved pointers are affected by GC. The current strategy of using an Object array supplied by the java side will be replaced later with an oops_do type of strategy. Description of source changes in this webrev. ============================================= graal source changes ==================== Assembler, HSAILAssembler minor changes for new instructions needed for saving deopt information GraalKernelTester.java force simulator to run single threaded. KernelTester.java minor changes to handle exceptions which escape the kernel method HSAILLIRGenerator.java support switches with keys of type long HSAILHotSpotBackend.java * compileKernel uses some new optimisticOpts which help generate deopts when needed. Also, we dump the infopoints if Log:CodeGen is on * HSAILNonNullParametersPhase stamps the appropriate parameters as nonNull * installKernel uses the new trampoline infrastructure added by Gilles do produce the host trampoline deopt method and install it. * emitCode adds a little bit of code to the prologue and a lot of code to the epilogue. See description at the bottom for the data structures used by the never-ran path and the deopt path. HSAILHotSpotLIRGenerator.java * code added by Gilles to build the host graph for the host trampoline deopt method. I suppose some of this would be common to any gpu trampoline deopt and should be moved to some hsail-independent location. * code to handle the creation of a DeoptimizeOp for emitting HSAIL code for a deoptimization HSAILHotSpotLoweringProvider.java * refactored to support different strategies for different nodes. UnwindNode strategy is to get replaced by a DeoptimizeNode. HotSpotVMConfig.java * define offets to fields in the deopt data structures VMErrorNode.java * public access to constructor (used by building of host graph for trampoline code) HSAIL.java * some new non-allocatable registers defined (used by deopt paths) HSAILControlFlow.java * code to emit hsail for a deoptimizationNode ComputeProbabilityClosure.java * just using a change that Gilles made in the patch he gave me. mx/projects was affected by the move of ExternalCompilationResult to com.oracle.graal.gpu. In addition, several files had one line import changes from the move of ExternalCompilationResult. hotspot source changes ====================== gpu_hsail.cpp, hpp * the execute_kernel routine pushes an extra parameter where deopt info can be saved * while pushing kernel args, keeps track if any are null and if so sets some new gpu_exception fields in thread structure which gets used when thread returns to java mode * on return from kernel checks if any deopt occurred. If so, * runs any deopting workitems thru the trampoline deopt code which ends up running the kernel method thru the interpreter for that workitem. * runs any never-ran workitems using simple javaCall. gpu_hsail_Frame.hpp * new structure that defines the layout of a physical HSAIL frame hsailArgumentsBase.*, hsailKernelArguments.hpp hsailJavaCallArguments.hpp * refactored to share code between kernel argument setup and javaCall argument setup javaClasses.cpp * contains logic to check the new gpu_exception fields in thread structure and if detected, set as top frame on return graalCompiler.cpp, hpp * logic added by Gilles for external_deopt_i2c javaCalls.cpp, hpp * logic added by Gilles for external_deopt_i2c sharedRuntime.cpp * maybe Gilles can explain why the assert was removed in the patch he gave me (it asserts if I put it back in) thread.cpp, hpp * handle new gpu_exception fields vmStructs.cpp vmStructs_hsail.hpp * handle new hsail deopt structs From doug.simon at oracle.com Tue Mar 11 20:54:17 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 11 Mar 2014 20:54:17 +0000 Subject: hg: graal/graal: 14 new changesets Message-ID: <201403112054.s2BKsZEW007472@aojmv0008> Changeset: 976f44f08fb3 Author: Tom Rodriguez Date: 2014-03-10 13:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/976f44f08fb3 currentThread is not exact ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ThreadSubstitutions.java Changeset: 452bb6e73298 Author: Josef Eisl Date: 2014-03-06 11:00 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/452bb6e73298 BaselineCompiler: fix typo. + graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineCompiler.java - graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaslineCompiler.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java Changeset: d2030fa96c22 Author: Josef Eisl Date: 2014-03-10 18:18 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d2030fa96c22 Compute LinearScanOrder in emitLIR. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/backend/AllocatorTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java Changeset: 9864ae31e1fe Author: Andreas Woess Date: 2014-03-11 13:03 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9864ae31e1fe add @CallerSensitive annotations (JBS:GRAAL-22) ! graal/com.oracle.graal.api.runtime/src/com/oracle/graal/api/runtime/Graal.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java Changeset: 3a30575968cd Author: Andreas Woess Date: 2014-03-11 14:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3a30575968cd Merge - graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaslineCompiler.java Changeset: 2c538e48bb1a Author: Roland Schatz Date: 2014-03-11 17:21 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2c538e48bb1a Fix bug in OSR compilation. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/OnStackReplacementPhase.java Changeset: 5bf75c95ed56 Author: Bernhard Urban Date: 2014-03-11 18:03 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5bf75c95ed56 compileBroker: remove unnecessary code in initialization of compilers ! src/share/vm/compiler/compileBroker.cpp Changeset: d2e4b81fd8f0 Author: Bernhard Urban Date: 2014-03-11 18:36 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d2e4b81fd8f0 mx: support sha1 digest for dependencies ! mx/projects ! mxtool/mx.py Changeset: e71d421370f3 Author: Bernhard Urban Date: 2014-03-11 18:36 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e71d421370f3 mx: proxy SIGQUIT to child process useful to get a jstack like output ! mxtool/mx.py Changeset: ee66410c0679 Author: Bernhard Urban Date: 2014-03-11 17:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ee66410c0679 mx: add option to send sigquit before killing child ! mxtool/mx.py Changeset: 38c0db058dcd Author: Bernhard Urban Date: 2014-03-11 18:10 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/38c0db058dcd mx: check if it's a java process before sending sigquit ! mxtool/mx.py Changeset: aa2920aa838d Author: Doug Simon Date: 2014-03-11 20:29 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/aa2920aa838d inverted security manager check and caller class check (JBS:GRAAL-22) ! graal/com.oracle.graal.api.runtime/src/com/oracle/graal/api/runtime/Graal.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java Changeset: 0b8f4e50e149 Author: Doug Simon Date: 2014-03-11 20:30 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0b8f4e50e149 removed unnecessary cache in HotSpotResolvedJavaField ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java Changeset: 0991bc235152 Author: Doug Simon Date: 2014-03-11 20:35 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0991bc235152 hide Graal.runtime from reflection (JBS:GRAAL-22) ! graal/com.oracle.graal.api.runtime/src/com/oracle/graal/api/runtime/Graal.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java From doug.simon at oracle.com Tue Mar 11 22:03:00 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 11 Mar 2014 23:03:00 +0100 Subject: Possible bug in latest version of clang on Mac OS X Message-ID: <9D6A58F5-C407-4609-A26E-43DD86F0AD23@oracle.com> Since I have automatic updating enabled on my Mac, I was recently updated to the latest version of Xcode (5.1). I have just done my first recompile of HotSpot since this update and am seeing that clang appears to have a rather serious bug. In both disassembled functions below, the third parameter (%rdx) is a jobject that should be resolved via JNIHandles::resolve and then dereferenced *after* adding the fourth parameter (%rcx) to it. clang is inlining the call to JNIHandles::resolve but omitting the null check on the jobject value. If this is really a bug, I?m sure reports about it will start showing up soon. In the meantime, don?t update Xcode. -Doug _Unsafe_GetLong: 0000000000357e59 pushq %rbp 0000000000357e5a movq %rsp, %rbp 0000000000357e5d pushq %r15 0000000000357e5f pushq %r14 0000000000357e61 pushq %r12 0000000000357e63 pushq %rbx 0000000000357e64 subq $0x10, %rsp 0000000000357e68 movq %rcx, %r14 0000000000357e6b movq %rdx, %r15 0000000000357e6e movq %rdi, %rbx 0000000000357e71 movl 0x90(%rbx), %eax 0000000000357e77 addq $-0x1f0, %rbx 0000000000357e7e cmpl $0xdeab, %eax 0000000000357e83 je 0x357e9c 0000000000357e85 movl 0x280(%rbx), %eax 0000000000357e8b cmpl $0xdeac, %eax 0000000000357e90 je 0x357e9c 0000000000357e92 movq %rbx, %rdi 0000000000357e95 callq __ZN10JavaThread18block_if_vm_exitedEv 0000000000357e9a xorl %ebx, %ebx 0000000000357e9c leaq -0x28(%rbp), %r12 0000000000357ea0 movq %r12, %rdi 0000000000357ea3 movq %rbx, %rsi 0000000000357ea6 callq __ZN20ThreadInVMfromNativeC1EP10JavaThread 0000000000357eab movq %rbx, -0x30(%rbp) 0000000000357eaf movq (%r15), %rax 0000000000357eb2 movq (%rax,%r14), %rbx 0000000000357eb6 leaq -0x30(%rbp), %rdi 0000000000357eba callq __ZN17HandleMarkCleanerD1Ev 0000000000357ebf movq %r12, %rdi 0000000000357ec2 callq __ZN20ThreadInVMfromNativeD1Ev 0000000000357ec7 movq %rbx, %rax 0000000000357eca addq $0x10, %rsp 0000000000357ece popq %rbx 0000000000357ecf popq %r12 0000000000357ed1 popq %r14 0000000000357ed3 popq %r15 0000000000357ed5 popq %rbp 0000000000357ed6 ret __Z33c2v_readUnsafeUncompressedPointerP7JNIEnv_P8_jobjectS2_l: 000000000016e261 pushq %rbp 000000000016e262 movq %rsp, %rbp 000000000016e265 pushq %r15 000000000016e267 pushq %r14 000000000016e269 pushq %r12 000000000016e26b pushq %rbx 000000000016e26c subq $0x10, %rsp 000000000016e270 movq %rcx, %r14 000000000016e273 movq %rdx, %r15 000000000016e276 leaq _TraceGraal(%rip), %rax 000000000016e27d cmpq $0x3, (%rax) 000000000016e281 jl 0x16e2ac 000000000016e283 leaq _tty(%rip), %rbx 000000000016e28a movq (%rbx), %rdi 000000000016e28d leaq 0x23de25(%rip), %rsi ## literal pool for: " TraceGraal-3: " 000000000016e294 xorl %eax, %eax 000000000016e296 callq __ZN12outputStream5printEPKcz 000000000016e29b movq (%rbx), %rdi 000000000016e29e leaq 0x23ef0f(%rip), %rsi ## literal pool for: "CompilerToVM::readUnsafeUncompressedPointer" 000000000016e2a5 xorl %eax, %eax 000000000016e2a7 callq __ZN12outputStream8print_crEPKcz 000000000016e2ac leaq __ZN18ThreadLocalStorage13_thread_indexE(%rip), %rax 000000000016e2b3 movslq (%rax), %rdi 000000000016e2b6 callq 0x38a758 ## symbol stub for: _pthread_getspecific 000000000016e2bb movq %rax, %rbx 000000000016e2be leaq -0x28(%rbp), %r12 000000000016e2c2 movq %r12, %rdi 000000000016e2c5 movq %rbx, %rsi 000000000016e2c8 callq __ZN20ThreadInVMfromNativeC1EP10JavaThread 000000000016e2cd movq %rbx, -0x30(%rbp) 000000000016e2d1 movq (%r15), %rax 000000000016e2d4 movq (%rax,%r14), %rdi 000000000016e2d8 callq __ZN10JNIHandles10make_localEP7oopDesc 000000000016e2dd movq %rax, %rbx 000000000016e2e0 leaq -0x30(%rbp), %rdi 000000000016e2e4 callq __ZN17HandleMarkCleanerD1Ev 000000000016e2e9 movq %r12, %rdi 000000000016e2ec callq __ZN20ThreadInVMfromNativeD1Ev 000000000016e2f1 movq %rbx, %rax 000000000016e2f4 addq $0x10, %rsp 000000000016e2f8 popq %rbx 000000000016e2f9 popq %r12 000000000016e2fb popq %r14 000000000016e2fd popq %r15 000000000016e2ff popq %rbp 000000000016e300 ret From christian.thalinger at oracle.com Tue Mar 11 22:11:46 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Mar 2014 15:11:46 -0700 Subject: webrev for hsail deoptimization In-Reply-To: References: Message-ID: <4AFCE83E-65C1-4C31-9191-05848E0AABAF@oracle.com> On Mar 11, 2014, at 1:08 PM, Deneau, Tom wrote: > I have placed a webrev up at > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt > which we would like to get checked into the graal trunk. > > This consists of at least the start of support for deoptimization in > HSAIL kernels. Although the list of files changed may look long, many > of the files have only a few lines changed. Special thanks to Gilles > Duboscq and Doug Simon who provided some of the infrastructure that > this webrev uses. > > Below I have described > > * an overview of the codepaths the data structures > * java and hotspot source changes > > > Deoptimization Data Structures and Overview > =========================================== > > At kernel dispatch time, we allocate space for any workitems should > want to deopt. To reduce the space requirements, space is only > reserved for the maximum number of possible concurrent workitems that > could be running on that hsa device. > > A deopting workitem sets a "deopt happened" flag, and future workitems > that see "deopt happened" as true will just set a flag saying they > never ran and exit early. Currently the never_ran array is one per > workitem. We are looking at ways to make this smaller but HSA devices > have a lot of freedom in how they schedule workitems (current hardware > and the simulator are quite different). > > Workitems that deopt atomically bump an index saying where they should > store their deopt data. The deopt data consists of > * workitemid > * deopt actionAndReason > * the first HSAILFrame > > An HSAILFrame consists of > * the deoptId or "pc" offset where the deopt occurred > * number of s registers > * number of d registers > * a bitmap indicating which d registers are oops > * space for saving the d and s registers > > Currently we always set num_s_registers to 32 and num_d_registers to > 16 but in the hsail code of the kernel we only save the union of the > actual registers that are live at any of the infopoints. > > On return from the GPU, we check if there were any deopts. If not, we > just return back to java. If there was at least one deopt then > > a) for the workitems that finished normally, there is nothing to do > > b) if there are any deopted workitems, we want to run each deopting > workitem thru the interpreter going first thru the special host > trampoline code infrastructure that Gilles created. The > trampoline host code takes the deoptId and a pointer to the > saved hsail frame. We currently do this sequentially although > other policies are possible. > > c) for each never ran workitem, we can just run it from the > beginning of the kernel "method", just making sure we pass the > arguments and the appropriate workitem id for each one. Again, > we currently do this sequentially although other policies are > possible. > > Because running either type b or c above can cause GCs, and because > some of our saved d registers are pointers into the java heap, we take > care in case any of these saved pointers are affected by GC. The > current strategy of using an Object array supplied by the java side > will be replaced later with an oops_do type of strategy. > > > > Description of source changes in this webrev. > ============================================= > graal source changes > ==================== > > Assembler, HSAILAssembler > minor changes for new instructions needed for saving deopt information > > GraalKernelTester.java > force simulator to run single threaded. > > KernelTester.java > minor changes to handle exceptions which escape the kernel method > > HSAILLIRGenerator.java > support switches with keys of type long > > > HSAILHotSpotBackend.java > > * compileKernel uses some new optimisticOpts which help generate > deopts when needed. Also, we dump the infopoints if Log:CodeGen > is on > > * HSAILNonNullParametersPhase stamps the appropriate parameters as > nonNull > > * installKernel uses the new trampoline infrastructure added by > Gilles do produce the host trampoline deopt method and install > it. > > * emitCode adds a little bit of code to the prologue and a lot of > code to the epilogue. See description at the bottom for the data > structures used by the never-ran path and the deopt path. > > HSAILHotSpotLIRGenerator.java > > * code added by Gilles to build the host graph for the host > trampoline deopt method. I suppose some of this would be common > to any gpu trampoline deopt and should be moved to some > hsail-independent location. > > * code to handle the creation of a DeoptimizeOp for emitting HSAIL > code for a deoptimization > > HSAILHotSpotLoweringProvider.java > > * refactored to support different strategies for different nodes. > UnwindNode strategy is to get replaced by a DeoptimizeNode. > > HotSpotVMConfig.java > > * define offets to fields in the deopt data structures > > VMErrorNode.java > > * public access to constructor (used by building of host graph for > trampoline code) > > HSAIL.java > * some new non-allocatable registers defined (used by deopt paths) > > HSAILControlFlow.java > * code to emit hsail for a deoptimizationNode > > ComputeProbabilityClosure.java > * just using a change that Gilles made in the patch he gave me. > > > mx/projects was affected by the move of ExternalCompilationResult to > com.oracle.graal.gpu. In addition, several files had one line import > changes from the move of ExternalCompilationResult. > > > hotspot source changes > ====================== > > gpu_hsail.cpp, hpp > > * the execute_kernel routine pushes an extra parameter where deopt info can be saved > > * while pushing kernel args, keeps track if any are null and if so > sets some new gpu_exception fields in thread structure which gets > used when thread returns to java mode > > * on return from kernel checks if any deopt occurred. If so, > > * runs any deopting workitems thru the trampoline deopt code > which ends up running the kernel method thru the interpreter > for that workitem. > > * runs any never-ran workitems using simple javaCall. > > gpu_hsail_Frame.hpp > * new structure that defines the layout of a physical HSAIL frame > > hsailArgumentsBase.*, hsailKernelArguments.hpp hsailJavaCallArguments.hpp > * refactored to share code between kernel argument setup and > javaCall argument setup > > javaClasses.cpp > > * contains logic to check the new gpu_exception fields in thread > structure and if detected, set as top frame on return > > graalCompiler.cpp, hpp > * logic added by Gilles for external_deopt_i2c > > javaCalls.cpp, hpp > * logic added by Gilles for external_deopt_i2c > > sharedRuntime.cpp > * maybe Gilles can explain why the assert was removed in the patch > he gave me (it asserts if I put it back in) Yeah, that made me suspicious. It?s related to the changes in javaCalls but I couldn?t see (yet) why Gilles made these. > > thread.cpp, hpp > * handle new gpu_exception fields > > vmStructs.cpp > vmStructs_hsail.hpp > * handle new hsail deopt structs > > > From christian.thalinger at oracle.com Tue Mar 11 22:14:40 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Mar 2014 15:14:40 -0700 Subject: Possible bug in latest version of clang on Mac OS X In-Reply-To: <9D6A58F5-C407-4609-A26E-43DD86F0AD23@oracle.com> References: <9D6A58F5-C407-4609-A26E-43DD86F0AD23@oracle.com> Message-ID: <264C27AB-0465-4B1E-90AA-1C697180C0CF@oracle.com> Sigh. Meta-circular FTW! ;-) Did you add a new section like this: # 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 OPT_CFLAGS/graalCompilerToVM.o += -O1 endif for 5.1 in make/bsd/makefiles/gcc.make? On Mar 11, 2014, at 3:03 PM, Doug Simon wrote: > Since I have automatic updating enabled on my Mac, I was recently updated to the latest version of Xcode (5.1). I have just done my first recompile of HotSpot since this update and am seeing that clang appears to have a rather serious bug. In both disassembled functions below, the third parameter (%rdx) is a jobject that should be resolved via JNIHandles::resolve and then dereferenced *after* adding the fourth parameter (%rcx) to it. clang is inlining the call to JNIHandles::resolve but omitting the null check on the jobject value. > > If this is really a bug, I?m sure reports about it will start showing up soon. In the meantime, don?t update Xcode. > > -Doug > > > _Unsafe_GetLong: > 0000000000357e59 pushq %rbp > 0000000000357e5a movq %rsp, %rbp > 0000000000357e5d pushq %r15 > 0000000000357e5f pushq %r14 > 0000000000357e61 pushq %r12 > 0000000000357e63 pushq %rbx > 0000000000357e64 subq $0x10, %rsp > 0000000000357e68 movq %rcx, %r14 > 0000000000357e6b movq %rdx, %r15 > 0000000000357e6e movq %rdi, %rbx > 0000000000357e71 movl 0x90(%rbx), %eax > 0000000000357e77 addq $-0x1f0, %rbx > 0000000000357e7e cmpl $0xdeab, %eax > 0000000000357e83 je 0x357e9c > 0000000000357e85 movl 0x280(%rbx), %eax > 0000000000357e8b cmpl $0xdeac, %eax > 0000000000357e90 je 0x357e9c > 0000000000357e92 movq %rbx, %rdi > 0000000000357e95 callq __ZN10JavaThread18block_if_vm_exitedEv > 0000000000357e9a xorl %ebx, %ebx > 0000000000357e9c leaq -0x28(%rbp), %r12 > 0000000000357ea0 movq %r12, %rdi > 0000000000357ea3 movq %rbx, %rsi > 0000000000357ea6 callq __ZN20ThreadInVMfromNativeC1EP10JavaThread > 0000000000357eab movq %rbx, -0x30(%rbp) > 0000000000357eaf movq (%r15), %rax > 0000000000357eb2 movq (%rax,%r14), %rbx > 0000000000357eb6 leaq -0x30(%rbp), %rdi > 0000000000357eba callq __ZN17HandleMarkCleanerD1Ev > 0000000000357ebf movq %r12, %rdi > 0000000000357ec2 callq __ZN20ThreadInVMfromNativeD1Ev > 0000000000357ec7 movq %rbx, %rax > 0000000000357eca addq $0x10, %rsp > 0000000000357ece popq %rbx > 0000000000357ecf popq %r12 > 0000000000357ed1 popq %r14 > 0000000000357ed3 popq %r15 > 0000000000357ed5 popq %rbp > 0000000000357ed6 ret > > __Z33c2v_readUnsafeUncompressedPointerP7JNIEnv_P8_jobjectS2_l: > 000000000016e261 pushq %rbp > 000000000016e262 movq %rsp, %rbp > 000000000016e265 pushq %r15 > 000000000016e267 pushq %r14 > 000000000016e269 pushq %r12 > 000000000016e26b pushq %rbx > 000000000016e26c subq $0x10, %rsp > 000000000016e270 movq %rcx, %r14 > 000000000016e273 movq %rdx, %r15 > 000000000016e276 leaq _TraceGraal(%rip), %rax > 000000000016e27d cmpq $0x3, (%rax) > 000000000016e281 jl 0x16e2ac > 000000000016e283 leaq _tty(%rip), %rbx > 000000000016e28a movq (%rbx), %rdi > 000000000016e28d leaq 0x23de25(%rip), %rsi ## literal pool for: " TraceGraal-3: " > 000000000016e294 xorl %eax, %eax > 000000000016e296 callq __ZN12outputStream5printEPKcz > 000000000016e29b movq (%rbx), %rdi > 000000000016e29e leaq 0x23ef0f(%rip), %rsi ## literal pool for: "CompilerToVM::readUnsafeUncompressedPointer" > 000000000016e2a5 xorl %eax, %eax > 000000000016e2a7 callq __ZN12outputStream8print_crEPKcz > 000000000016e2ac leaq __ZN18ThreadLocalStorage13_thread_indexE(%rip), %rax > 000000000016e2b3 movslq (%rax), %rdi > 000000000016e2b6 callq 0x38a758 ## symbol stub for: _pthread_getspecific > 000000000016e2bb movq %rax, %rbx > 000000000016e2be leaq -0x28(%rbp), %r12 > 000000000016e2c2 movq %r12, %rdi > 000000000016e2c5 movq %rbx, %rsi > 000000000016e2c8 callq __ZN20ThreadInVMfromNativeC1EP10JavaThread > 000000000016e2cd movq %rbx, -0x30(%rbp) > 000000000016e2d1 movq (%r15), %rax > 000000000016e2d4 movq (%rax,%r14), %rdi > 000000000016e2d8 callq __ZN10JNIHandles10make_localEP7oopDesc > 000000000016e2dd movq %rax, %rbx > 000000000016e2e0 leaq -0x30(%rbp), %rdi > 000000000016e2e4 callq __ZN17HandleMarkCleanerD1Ev > 000000000016e2e9 movq %r12, %rdi > 000000000016e2ec callq __ZN20ThreadInVMfromNativeD1Ev > 000000000016e2f1 movq %rbx, %rax > 000000000016e2f4 addq $0x10, %rsp > 000000000016e2f8 popq %rbx > 000000000016e2f9 popq %r12 > 000000000016e2fb popq %r14 > 000000000016e2fd popq %r15 > 000000000016e2ff popq %rbp > 000000000016e300 ret > > From tom.rodriguez at oracle.com Tue Mar 11 23:01:46 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 11 Mar 2014 16:01:46 -0700 Subject: Possible bug in latest version of clang on Mac OS X In-Reply-To: <264C27AB-0465-4B1E-90AA-1C697180C0CF@oracle.com> References: <9D6A58F5-C407-4609-A26E-43DD86F0AD23@oracle.com> <264C27AB-0465-4B1E-90AA-1C697180C0CF@oracle.com> Message-ID: <2A5E686F-F0D9-43D2-9CCB-BE32FA59268A@oracle.com> So this is a known clang/llvm issue? Has it been reported? tom On Mar 11, 2014, at 3:14 PM, Christian Thalinger wrote: > Sigh. Meta-circular FTW! ;-) > > Did you add a new section like this: > > # 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 > OPT_CFLAGS/graalCompilerToVM.o += -O1 > endif > > for 5.1 in make/bsd/makefiles/gcc.make? > > On Mar 11, 2014, at 3:03 PM, Doug Simon wrote: > >> Since I have automatic updating enabled on my Mac, I was recently updated to the latest version of Xcode (5.1). I have just done my first recompile of HotSpot since this update and am seeing that clang appears to have a rather serious bug. In both disassembled functions below, the third parameter (%rdx) is a jobject that should be resolved via JNIHandles::resolve and then dereferenced *after* adding the fourth parameter (%rcx) to it. clang is inlining the call to JNIHandles::resolve but omitting the null check on the jobject value. >> >> If this is really a bug, I?m sure reports about it will start showing up soon. In the meantime, don?t update Xcode. >> >> -Doug >> >> >> _Unsafe_GetLong: >> 0000000000357e59 pushq %rbp >> 0000000000357e5a movq %rsp, %rbp >> 0000000000357e5d pushq %r15 >> 0000000000357e5f pushq %r14 >> 0000000000357e61 pushq %r12 >> 0000000000357e63 pushq %rbx >> 0000000000357e64 subq $0x10, %rsp >> 0000000000357e68 movq %rcx, %r14 >> 0000000000357e6b movq %rdx, %r15 >> 0000000000357e6e movq %rdi, %rbx >> 0000000000357e71 movl 0x90(%rbx), %eax >> 0000000000357e77 addq $-0x1f0, %rbx >> 0000000000357e7e cmpl $0xdeab, %eax >> 0000000000357e83 je 0x357e9c >> 0000000000357e85 movl 0x280(%rbx), %eax >> 0000000000357e8b cmpl $0xdeac, %eax >> 0000000000357e90 je 0x357e9c >> 0000000000357e92 movq %rbx, %rdi >> 0000000000357e95 callq __ZN10JavaThread18block_if_vm_exitedEv >> 0000000000357e9a xorl %ebx, %ebx >> 0000000000357e9c leaq -0x28(%rbp), %r12 >> 0000000000357ea0 movq %r12, %rdi >> 0000000000357ea3 movq %rbx, %rsi >> 0000000000357ea6 callq __ZN20ThreadInVMfromNativeC1EP10JavaThread >> 0000000000357eab movq %rbx, -0x30(%rbp) >> 0000000000357eaf movq (%r15), %rax >> 0000000000357eb2 movq (%rax,%r14), %rbx >> 0000000000357eb6 leaq -0x30(%rbp), %rdi >> 0000000000357eba callq __ZN17HandleMarkCleanerD1Ev >> 0000000000357ebf movq %r12, %rdi >> 0000000000357ec2 callq __ZN20ThreadInVMfromNativeD1Ev >> 0000000000357ec7 movq %rbx, %rax >> 0000000000357eca addq $0x10, %rsp >> 0000000000357ece popq %rbx >> 0000000000357ecf popq %r12 >> 0000000000357ed1 popq %r14 >> 0000000000357ed3 popq %r15 >> 0000000000357ed5 popq %rbp >> 0000000000357ed6 ret >> >> __Z33c2v_readUnsafeUncompressedPointerP7JNIEnv_P8_jobjectS2_l: >> 000000000016e261 pushq %rbp >> 000000000016e262 movq %rsp, %rbp >> 000000000016e265 pushq %r15 >> 000000000016e267 pushq %r14 >> 000000000016e269 pushq %r12 >> 000000000016e26b pushq %rbx >> 000000000016e26c subq $0x10, %rsp >> 000000000016e270 movq %rcx, %r14 >> 000000000016e273 movq %rdx, %r15 >> 000000000016e276 leaq _TraceGraal(%rip), %rax >> 000000000016e27d cmpq $0x3, (%rax) >> 000000000016e281 jl 0x16e2ac >> 000000000016e283 leaq _tty(%rip), %rbx >> 000000000016e28a movq (%rbx), %rdi >> 000000000016e28d leaq 0x23de25(%rip), %rsi ## literal pool for: " TraceGraal-3: " >> 000000000016e294 xorl %eax, %eax >> 000000000016e296 callq __ZN12outputStream5printEPKcz >> 000000000016e29b movq (%rbx), %rdi >> 000000000016e29e leaq 0x23ef0f(%rip), %rsi ## literal pool for: "CompilerToVM::readUnsafeUncompressedPointer" >> 000000000016e2a5 xorl %eax, %eax >> 000000000016e2a7 callq __ZN12outputStream8print_crEPKcz >> 000000000016e2ac leaq __ZN18ThreadLocalStorage13_thread_indexE(%rip), %rax >> 000000000016e2b3 movslq (%rax), %rdi >> 000000000016e2b6 callq 0x38a758 ## symbol stub for: _pthread_getspecific >> 000000000016e2bb movq %rax, %rbx >> 000000000016e2be leaq -0x28(%rbp), %r12 >> 000000000016e2c2 movq %r12, %rdi >> 000000000016e2c5 movq %rbx, %rsi >> 000000000016e2c8 callq __ZN20ThreadInVMfromNativeC1EP10JavaThread >> 000000000016e2cd movq %rbx, -0x30(%rbp) >> 000000000016e2d1 movq (%r15), %rax >> 000000000016e2d4 movq (%rax,%r14), %rdi >> 000000000016e2d8 callq __ZN10JNIHandles10make_localEP7oopDesc >> 000000000016e2dd movq %rax, %rbx >> 000000000016e2e0 leaq -0x30(%rbp), %rdi >> 000000000016e2e4 callq __ZN17HandleMarkCleanerD1Ev >> 000000000016e2e9 movq %r12, %rdi >> 000000000016e2ec callq __ZN20ThreadInVMfromNativeD1Ev >> 000000000016e2f1 movq %rbx, %rax >> 000000000016e2f4 addq $0x10, %rsp >> 000000000016e2f8 popq %rbx >> 000000000016e2f9 popq %r12 >> 000000000016e2fb popq %r14 >> 000000000016e2fd popq %r15 >> 000000000016e2ff popq %rbp >> 000000000016e300 ret >> >> > From doug.simon at oracle.com Tue Mar 11 23:02:08 2014 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 12 Mar 2014 00:02:08 +0100 Subject: Possible bug in latest version of clang on Mac OS X In-Reply-To: <264C27AB-0465-4B1E-90AA-1C697180C0CF@oracle.com> References: <9D6A58F5-C407-4609-A26E-43DD86F0AD23@oracle.com> <264C27AB-0465-4B1E-90AA-1C697180C0CF@oracle.com> Message-ID: <097B4374-C2C3-4898-BA8C-27B95005D0AB@oracle.com> On Mar 11, 2014, at 11:14 PM, Christian Thalinger wrote: > Sigh. Meta-circular FTW! ;-) Not sure what this has to do with metacircularity. > Did you add a new section like this: > > # 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 > OPT_CFLAGS/graalCompilerToVM.o += -O1 > endif > > for 5.1 in make/bsd/makefiles/gcc.make? Yes, we have that section. I just needed to update it to now also take CC_VER_MINOR == 1 into account - thanks for the pointer. -Doug > On Mar 11, 2014, at 3:03 PM, Doug Simon wrote: > >> Since I have automatic updating enabled on my Mac, I was recently updated to the latest version of Xcode (5.1). I have just done my first recompile of HotSpot since this update and am seeing that clang appears to have a rather serious bug. In both disassembled functions below, the third parameter (%rdx) is a jobject that should be resolved via JNIHandles::resolve and then dereferenced *after* adding the fourth parameter (%rcx) to it. clang is inlining the call to JNIHandles::resolve but omitting the null check on the jobject value. >> >> If this is really a bug, I?m sure reports about it will start showing up soon. In the meantime, don?t update Xcode. >> >> -Doug >> >> >> _Unsafe_GetLong: >> 0000000000357e59 pushq %rbp >> 0000000000357e5a movq %rsp, %rbp >> 0000000000357e5d pushq %r15 >> 0000000000357e5f pushq %r14 >> 0000000000357e61 pushq %r12 >> 0000000000357e63 pushq %rbx >> 0000000000357e64 subq $0x10, %rsp >> 0000000000357e68 movq %rcx, %r14 >> 0000000000357e6b movq %rdx, %r15 >> 0000000000357e6e movq %rdi, %rbx >> 0000000000357e71 movl 0x90(%rbx), %eax >> 0000000000357e77 addq $-0x1f0, %rbx >> 0000000000357e7e cmpl $0xdeab, %eax >> 0000000000357e83 je 0x357e9c >> 0000000000357e85 movl 0x280(%rbx), %eax >> 0000000000357e8b cmpl $0xdeac, %eax >> 0000000000357e90 je 0x357e9c >> 0000000000357e92 movq %rbx, %rdi >> 0000000000357e95 callq __ZN10JavaThread18block_if_vm_exitedEv >> 0000000000357e9a xorl %ebx, %ebx >> 0000000000357e9c leaq -0x28(%rbp), %r12 >> 0000000000357ea0 movq %r12, %rdi >> 0000000000357ea3 movq %rbx, %rsi >> 0000000000357ea6 callq __ZN20ThreadInVMfromNativeC1EP10JavaThread >> 0000000000357eab movq %rbx, -0x30(%rbp) >> 0000000000357eaf movq (%r15), %rax >> 0000000000357eb2 movq (%rax,%r14), %rbx >> 0000000000357eb6 leaq -0x30(%rbp), %rdi >> 0000000000357eba callq __ZN17HandleMarkCleanerD1Ev >> 0000000000357ebf movq %r12, %rdi >> 0000000000357ec2 callq __ZN20ThreadInVMfromNativeD1Ev >> 0000000000357ec7 movq %rbx, %rax >> 0000000000357eca addq $0x10, %rsp >> 0000000000357ece popq %rbx >> 0000000000357ecf popq %r12 >> 0000000000357ed1 popq %r14 >> 0000000000357ed3 popq %r15 >> 0000000000357ed5 popq %rbp >> 0000000000357ed6 ret >> >> __Z33c2v_readUnsafeUncompressedPointerP7JNIEnv_P8_jobjectS2_l: >> 000000000016e261 pushq %rbp >> 000000000016e262 movq %rsp, %rbp >> 000000000016e265 pushq %r15 >> 000000000016e267 pushq %r14 >> 000000000016e269 pushq %r12 >> 000000000016e26b pushq %rbx >> 000000000016e26c subq $0x10, %rsp >> 000000000016e270 movq %rcx, %r14 >> 000000000016e273 movq %rdx, %r15 >> 000000000016e276 leaq _TraceGraal(%rip), %rax >> 000000000016e27d cmpq $0x3, (%rax) >> 000000000016e281 jl 0x16e2ac >> 000000000016e283 leaq _tty(%rip), %rbx >> 000000000016e28a movq (%rbx), %rdi >> 000000000016e28d leaq 0x23de25(%rip), %rsi ## literal pool for: " TraceGraal-3: " >> 000000000016e294 xorl %eax, %eax >> 000000000016e296 callq __ZN12outputStream5printEPKcz >> 000000000016e29b movq (%rbx), %rdi >> 000000000016e29e leaq 0x23ef0f(%rip), %rsi ## literal pool for: "CompilerToVM::readUnsafeUncompressedPointer" >> 000000000016e2a5 xorl %eax, %eax >> 000000000016e2a7 callq __ZN12outputStream8print_crEPKcz >> 000000000016e2ac leaq __ZN18ThreadLocalStorage13_thread_indexE(%rip), %rax >> 000000000016e2b3 movslq (%rax), %rdi >> 000000000016e2b6 callq 0x38a758 ## symbol stub for: _pthread_getspecific >> 000000000016e2bb movq %rax, %rbx >> 000000000016e2be leaq -0x28(%rbp), %r12 >> 000000000016e2c2 movq %r12, %rdi >> 000000000016e2c5 movq %rbx, %rsi >> 000000000016e2c8 callq __ZN20ThreadInVMfromNativeC1EP10JavaThread >> 000000000016e2cd movq %rbx, -0x30(%rbp) >> 000000000016e2d1 movq (%r15), %rax >> 000000000016e2d4 movq (%rax,%r14), %rdi >> 000000000016e2d8 callq __ZN10JNIHandles10make_localEP7oopDesc >> 000000000016e2dd movq %rax, %rbx >> 000000000016e2e0 leaq -0x30(%rbp), %rdi >> 000000000016e2e4 callq __ZN17HandleMarkCleanerD1Ev >> 000000000016e2e9 movq %r12, %rdi >> 000000000016e2ec callq __ZN20ThreadInVMfromNativeD1Ev >> 000000000016e2f1 movq %rbx, %rax >> 000000000016e2f4 addq $0x10, %rsp >> 000000000016e2f8 popq %rbx >> 000000000016e2f9 popq %r12 >> 000000000016e2fb popq %r14 >> 000000000016e2fd popq %r15 >> 000000000016e2ff popq %rbp >> 000000000016e300 ret >> >> > From christian.thalinger at oracle.com Wed Mar 12 01:30:13 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Mar 2014 18:30:13 -0700 Subject: Possible bug in latest version of clang on Mac OS X In-Reply-To: <097B4374-C2C3-4898-BA8C-27B95005D0AB@oracle.com> References: <9D6A58F5-C407-4609-A26E-43DD86F0AD23@oracle.com> <264C27AB-0465-4B1E-90AA-1C697180C0CF@oracle.com> <097B4374-C2C3-4898-BA8C-27B95005D0AB@oracle.com> Message-ID: <8C5EAE95-9F1A-4CA7-A88B-ABB137406E3A@oracle.com> On Mar 11, 2014, at 4:02 PM, Doug Simon wrote: > > On Mar 11, 2014, at 11:14 PM, Christian Thalinger wrote: > >> Sigh. Meta-circular FTW! ;-) > > Not sure what this has to do with metacircularity. Nothing directly. This was obviously a failed attempt to point out that compiling your own code is a good thing. Not that it helps for unsafe.cpp. > >> Did you add a new section like this: >> >> # 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 >> OPT_CFLAGS/graalCompilerToVM.o += -O1 >> endif >> >> for 5.1 in make/bsd/makefiles/gcc.make? > > Yes, we have that section. I just needed to update it to now also take CC_VER_MINOR == 1 into account - thanks for the pointer. > > -Doug > >> On Mar 11, 2014, at 3:03 PM, Doug Simon wrote: >> >>> Since I have automatic updating enabled on my Mac, I was recently updated to the latest version of Xcode (5.1). I have just done my first recompile of HotSpot since this update and am seeing that clang appears to have a rather serious bug. In both disassembled functions below, the third parameter (%rdx) is a jobject that should be resolved via JNIHandles::resolve and then dereferenced *after* adding the fourth parameter (%rcx) to it. clang is inlining the call to JNIHandles::resolve but omitting the null check on the jobject value. >>> >>> If this is really a bug, I?m sure reports about it will start showing up soon. In the meantime, don?t update Xcode. >>> >>> -Doug >>> >>> >>> _Unsafe_GetLong: >>> 0000000000357e59 pushq %rbp >>> 0000000000357e5a movq %rsp, %rbp >>> 0000000000357e5d pushq %r15 >>> 0000000000357e5f pushq %r14 >>> 0000000000357e61 pushq %r12 >>> 0000000000357e63 pushq %rbx >>> 0000000000357e64 subq $0x10, %rsp >>> 0000000000357e68 movq %rcx, %r14 >>> 0000000000357e6b movq %rdx, %r15 >>> 0000000000357e6e movq %rdi, %rbx >>> 0000000000357e71 movl 0x90(%rbx), %eax >>> 0000000000357e77 addq $-0x1f0, %rbx >>> 0000000000357e7e cmpl $0xdeab, %eax >>> 0000000000357e83 je 0x357e9c >>> 0000000000357e85 movl 0x280(%rbx), %eax >>> 0000000000357e8b cmpl $0xdeac, %eax >>> 0000000000357e90 je 0x357e9c >>> 0000000000357e92 movq %rbx, %rdi >>> 0000000000357e95 callq __ZN10JavaThread18block_if_vm_exitedEv >>> 0000000000357e9a xorl %ebx, %ebx >>> 0000000000357e9c leaq -0x28(%rbp), %r12 >>> 0000000000357ea0 movq %r12, %rdi >>> 0000000000357ea3 movq %rbx, %rsi >>> 0000000000357ea6 callq __ZN20ThreadInVMfromNativeC1EP10JavaThread >>> 0000000000357eab movq %rbx, -0x30(%rbp) >>> 0000000000357eaf movq (%r15), %rax >>> 0000000000357eb2 movq (%rax,%r14), %rbx >>> 0000000000357eb6 leaq -0x30(%rbp), %rdi >>> 0000000000357eba callq __ZN17HandleMarkCleanerD1Ev >>> 0000000000357ebf movq %r12, %rdi >>> 0000000000357ec2 callq __ZN20ThreadInVMfromNativeD1Ev >>> 0000000000357ec7 movq %rbx, %rax >>> 0000000000357eca addq $0x10, %rsp >>> 0000000000357ece popq %rbx >>> 0000000000357ecf popq %r12 >>> 0000000000357ed1 popq %r14 >>> 0000000000357ed3 popq %r15 >>> 0000000000357ed5 popq %rbp >>> 0000000000357ed6 ret >>> >>> __Z33c2v_readUnsafeUncompressedPointerP7JNIEnv_P8_jobjectS2_l: >>> 000000000016e261 pushq %rbp >>> 000000000016e262 movq %rsp, %rbp >>> 000000000016e265 pushq %r15 >>> 000000000016e267 pushq %r14 >>> 000000000016e269 pushq %r12 >>> 000000000016e26b pushq %rbx >>> 000000000016e26c subq $0x10, %rsp >>> 000000000016e270 movq %rcx, %r14 >>> 000000000016e273 movq %rdx, %r15 >>> 000000000016e276 leaq _TraceGraal(%rip), %rax >>> 000000000016e27d cmpq $0x3, (%rax) >>> 000000000016e281 jl 0x16e2ac >>> 000000000016e283 leaq _tty(%rip), %rbx >>> 000000000016e28a movq (%rbx), %rdi >>> 000000000016e28d leaq 0x23de25(%rip), %rsi ## literal pool for: " TraceGraal-3: " >>> 000000000016e294 xorl %eax, %eax >>> 000000000016e296 callq __ZN12outputStream5printEPKcz >>> 000000000016e29b movq (%rbx), %rdi >>> 000000000016e29e leaq 0x23ef0f(%rip), %rsi ## literal pool for: "CompilerToVM::readUnsafeUncompressedPointer" >>> 000000000016e2a5 xorl %eax, %eax >>> 000000000016e2a7 callq __ZN12outputStream8print_crEPKcz >>> 000000000016e2ac leaq __ZN18ThreadLocalStorage13_thread_indexE(%rip), %rax >>> 000000000016e2b3 movslq (%rax), %rdi >>> 000000000016e2b6 callq 0x38a758 ## symbol stub for: _pthread_getspecific >>> 000000000016e2bb movq %rax, %rbx >>> 000000000016e2be leaq -0x28(%rbp), %r12 >>> 000000000016e2c2 movq %r12, %rdi >>> 000000000016e2c5 movq %rbx, %rsi >>> 000000000016e2c8 callq __ZN20ThreadInVMfromNativeC1EP10JavaThread >>> 000000000016e2cd movq %rbx, -0x30(%rbp) >>> 000000000016e2d1 movq (%r15), %rax >>> 000000000016e2d4 movq (%rax,%r14), %rdi >>> 000000000016e2d8 callq __ZN10JNIHandles10make_localEP7oopDesc >>> 000000000016e2dd movq %rax, %rbx >>> 000000000016e2e0 leaq -0x30(%rbp), %rdi >>> 000000000016e2e4 callq __ZN17HandleMarkCleanerD1Ev >>> 000000000016e2e9 movq %r12, %rdi >>> 000000000016e2ec callq __ZN20ThreadInVMfromNativeD1Ev >>> 000000000016e2f1 movq %rbx, %rax >>> 000000000016e2f4 addq $0x10, %rsp >>> 000000000016e2f8 popq %rbx >>> 000000000016e2f9 popq %r12 >>> 000000000016e2fb popq %r14 >>> 000000000016e2fd popq %r15 >>> 000000000016e2ff popq %rbp >>> 000000000016e300 ret >>> >>> >> > From christian.thalinger at oracle.com Wed Mar 12 01:30:44 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Mar 2014 18:30:44 -0700 Subject: Possible bug in latest version of clang on Mac OS X In-Reply-To: <2A5E686F-F0D9-43D2-9CCB-BE32FA59268A@oracle.com> References: <9D6A58F5-C407-4609-A26E-43DD86F0AD23@oracle.com> <264C27AB-0465-4B1E-90AA-1C697180C0CF@oracle.com> <2A5E686F-F0D9-43D2-9CCB-BE32FA59268A@oracle.com> Message-ID: <48654091-D15A-4790-8175-0255BCC669D3@oracle.com> On Mar 11, 2014, at 4:01 PM, Tom Rodriguez wrote: > So this is a known clang/llvm issue? Has it been reported? I don?t think so. At least I didn?t do it. > > tom > > On Mar 11, 2014, at 3:14 PM, Christian Thalinger wrote: > >> Sigh. Meta-circular FTW! ;-) >> >> Did you add a new section like this: >> >> # 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 >> OPT_CFLAGS/graalCompilerToVM.o += -O1 >> endif >> >> for 5.1 in make/bsd/makefiles/gcc.make? >> >> On Mar 11, 2014, at 3:03 PM, Doug Simon wrote: >> >>> Since I have automatic updating enabled on my Mac, I was recently updated to the latest version of Xcode (5.1). I have just done my first recompile of HotSpot since this update and am seeing that clang appears to have a rather serious bug. In both disassembled functions below, the third parameter (%rdx) is a jobject that should be resolved via JNIHandles::resolve and then dereferenced *after* adding the fourth parameter (%rcx) to it. clang is inlining the call to JNIHandles::resolve but omitting the null check on the jobject value. >>> >>> If this is really a bug, I?m sure reports about it will start showing up soon. In the meantime, don?t update Xcode. >>> >>> -Doug >>> >>> >>> _Unsafe_GetLong: >>> 0000000000357e59 pushq %rbp >>> 0000000000357e5a movq %rsp, %rbp >>> 0000000000357e5d pushq %r15 >>> 0000000000357e5f pushq %r14 >>> 0000000000357e61 pushq %r12 >>> 0000000000357e63 pushq %rbx >>> 0000000000357e64 subq $0x10, %rsp >>> 0000000000357e68 movq %rcx, %r14 >>> 0000000000357e6b movq %rdx, %r15 >>> 0000000000357e6e movq %rdi, %rbx >>> 0000000000357e71 movl 0x90(%rbx), %eax >>> 0000000000357e77 addq $-0x1f0, %rbx >>> 0000000000357e7e cmpl $0xdeab, %eax >>> 0000000000357e83 je 0x357e9c >>> 0000000000357e85 movl 0x280(%rbx), %eax >>> 0000000000357e8b cmpl $0xdeac, %eax >>> 0000000000357e90 je 0x357e9c >>> 0000000000357e92 movq %rbx, %rdi >>> 0000000000357e95 callq __ZN10JavaThread18block_if_vm_exitedEv >>> 0000000000357e9a xorl %ebx, %ebx >>> 0000000000357e9c leaq -0x28(%rbp), %r12 >>> 0000000000357ea0 movq %r12, %rdi >>> 0000000000357ea3 movq %rbx, %rsi >>> 0000000000357ea6 callq __ZN20ThreadInVMfromNativeC1EP10JavaThread >>> 0000000000357eab movq %rbx, -0x30(%rbp) >>> 0000000000357eaf movq (%r15), %rax >>> 0000000000357eb2 movq (%rax,%r14), %rbx >>> 0000000000357eb6 leaq -0x30(%rbp), %rdi >>> 0000000000357eba callq __ZN17HandleMarkCleanerD1Ev >>> 0000000000357ebf movq %r12, %rdi >>> 0000000000357ec2 callq __ZN20ThreadInVMfromNativeD1Ev >>> 0000000000357ec7 movq %rbx, %rax >>> 0000000000357eca addq $0x10, %rsp >>> 0000000000357ece popq %rbx >>> 0000000000357ecf popq %r12 >>> 0000000000357ed1 popq %r14 >>> 0000000000357ed3 popq %r15 >>> 0000000000357ed5 popq %rbp >>> 0000000000357ed6 ret >>> >>> __Z33c2v_readUnsafeUncompressedPointerP7JNIEnv_P8_jobjectS2_l: >>> 000000000016e261 pushq %rbp >>> 000000000016e262 movq %rsp, %rbp >>> 000000000016e265 pushq %r15 >>> 000000000016e267 pushq %r14 >>> 000000000016e269 pushq %r12 >>> 000000000016e26b pushq %rbx >>> 000000000016e26c subq $0x10, %rsp >>> 000000000016e270 movq %rcx, %r14 >>> 000000000016e273 movq %rdx, %r15 >>> 000000000016e276 leaq _TraceGraal(%rip), %rax >>> 000000000016e27d cmpq $0x3, (%rax) >>> 000000000016e281 jl 0x16e2ac >>> 000000000016e283 leaq _tty(%rip), %rbx >>> 000000000016e28a movq (%rbx), %rdi >>> 000000000016e28d leaq 0x23de25(%rip), %rsi ## literal pool for: " TraceGraal-3: " >>> 000000000016e294 xorl %eax, %eax >>> 000000000016e296 callq __ZN12outputStream5printEPKcz >>> 000000000016e29b movq (%rbx), %rdi >>> 000000000016e29e leaq 0x23ef0f(%rip), %rsi ## literal pool for: "CompilerToVM::readUnsafeUncompressedPointer" >>> 000000000016e2a5 xorl %eax, %eax >>> 000000000016e2a7 callq __ZN12outputStream8print_crEPKcz >>> 000000000016e2ac leaq __ZN18ThreadLocalStorage13_thread_indexE(%rip), %rax >>> 000000000016e2b3 movslq (%rax), %rdi >>> 000000000016e2b6 callq 0x38a758 ## symbol stub for: _pthread_getspecific >>> 000000000016e2bb movq %rax, %rbx >>> 000000000016e2be leaq -0x28(%rbp), %r12 >>> 000000000016e2c2 movq %r12, %rdi >>> 000000000016e2c5 movq %rbx, %rsi >>> 000000000016e2c8 callq __ZN20ThreadInVMfromNativeC1EP10JavaThread >>> 000000000016e2cd movq %rbx, -0x30(%rbp) >>> 000000000016e2d1 movq (%r15), %rax >>> 000000000016e2d4 movq (%rax,%r14), %rdi >>> 000000000016e2d8 callq __ZN10JNIHandles10make_localEP7oopDesc >>> 000000000016e2dd movq %rax, %rbx >>> 000000000016e2e0 leaq -0x30(%rbp), %rdi >>> 000000000016e2e4 callq __ZN17HandleMarkCleanerD1Ev >>> 000000000016e2e9 movq %r12, %rdi >>> 000000000016e2ec callq __ZN20ThreadInVMfromNativeD1Ev >>> 000000000016e2f1 movq %rbx, %rax >>> 000000000016e2f4 addq $0x10, %rsp >>> 000000000016e2f8 popq %rbx >>> 000000000016e2f9 popq %r12 >>> 000000000016e2fb popq %r14 >>> 000000000016e2fd popq %r15 >>> 000000000016e2ff popq %rbp >>> 000000000016e300 ret >>> >>> >> > From doug.simon at oracle.com Wed Mar 12 02:00:05 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 12 Mar 2014 02:00:05 +0000 Subject: hg: graal/graal: 2 new changesets Message-ID: <201403120200.s2C209ip025429@aojmv0008> Changeset: d2c8b553f621 Author: Doug Simon Date: 2014-03-11 23:59 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d2c8b553f621 fixed C++ compiler error reported by clang 5.1 ! src/share/vm/code/relocInfo.hpp Changeset: f97c5ec83832 Author: Doug Simon Date: 2014-03-12 00:00 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f97c5ec83832 apply workaround for clang 5.0 also to clang 5.1 ! make/bsd/makefiles/gcc.make From duboscq at ssw.jku.at Wed Mar 12 10:08:24 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Wed, 12 Mar 2014 11:08:24 +0100 Subject: webrev for hsail deoptimization In-Reply-To: <4AFCE83E-65C1-4C31-9191-05848E0AABAF@oracle.com> References: <4AFCE83E-65C1-4C31-9191-05848E0AABAF@oracle.com> Message-ID: On Tue, Mar 11, 2014 at 11:11 PM, Christian Thalinger wrote: > > On Mar 11, 2014, at 1:08 PM, Deneau, Tom wrote: > >> I have placed a webrev up at >> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt >> which we would like to get checked into the graal trunk. >> >> This consists of at least the start of support for deoptimization in >> HSAIL kernels. Although the list of files changed may look long, many >> of the files have only a few lines changed. Special thanks to Gilles >> Duboscq and Doug Simon who provided some of the infrastructure that >> this webrev uses. >> >> Below I have described >> >> * an overview of the codepaths the data structures >> * java and hotspot source changes >> >> >> Deoptimization Data Structures and Overview >> =========================================== >> >> At kernel dispatch time, we allocate space for any workitems should >> want to deopt. To reduce the space requirements, space is only >> reserved for the maximum number of possible concurrent workitems that >> could be running on that hsa device. >> >> A deopting workitem sets a "deopt happened" flag, and future workitems >> that see "deopt happened" as true will just set a flag saying they >> never ran and exit early. Currently the never_ran array is one per >> workitem. We are looking at ways to make this smaller but HSA devices >> have a lot of freedom in how they schedule workitems (current hardware >> and the simulator are quite different). >> >> Workitems that deopt atomically bump an index saying where they should >> store their deopt data. The deopt data consists of >> * workitemid >> * deopt actionAndReason >> * the first HSAILFrame >> >> An HSAILFrame consists of >> * the deoptId or "pc" offset where the deopt occurred >> * number of s registers >> * number of d registers >> * a bitmap indicating which d registers are oops >> * space for saving the d and s registers >> >> Currently we always set num_s_registers to 32 and num_d_registers to >> 16 but in the hsail code of the kernel we only save the union of the >> actual registers that are live at any of the infopoints. >> >> On return from the GPU, we check if there were any deopts. If not, we >> just return back to java. If there was at least one deopt then >> >> a) for the workitems that finished normally, there is nothing to do >> >> b) if there are any deopted workitems, we want to run each deopting >> workitem thru the interpreter going first thru the special host >> trampoline code infrastructure that Gilles created. The >> trampoline host code takes the deoptId and a pointer to the >> saved hsail frame. We currently do this sequentially although >> other policies are possible. >> >> c) for each never ran workitem, we can just run it from the >> beginning of the kernel "method", just making sure we pass the >> arguments and the appropriate workitem id for each one. Again, >> we currently do this sequentially although other policies are >> possible. >> >> Because running either type b or c above can cause GCs, and because >> some of our saved d registers are pointers into the java heap, we take >> care in case any of these saved pointers are affected by GC. The >> current strategy of using an Object array supplied by the java side >> will be replaced later with an oops_do type of strategy. >> >> >> >> Description of source changes in this webrev. >> ============================================= >> graal source changes >> ==================== >> >> Assembler, HSAILAssembler >> minor changes for new instructions needed for saving deopt information >> >> GraalKernelTester.java >> force simulator to run single threaded. >> >> KernelTester.java >> minor changes to handle exceptions which escape the kernel method >> >> HSAILLIRGenerator.java >> support switches with keys of type long >> >> >> HSAILHotSpotBackend.java >> >> * compileKernel uses some new optimisticOpts which help generate >> deopts when needed. Also, we dump the infopoints if Log:CodeGen >> is on >> >> * HSAILNonNullParametersPhase stamps the appropriate parameters as >> nonNull >> >> * installKernel uses the new trampoline infrastructure added by >> Gilles do produce the host trampoline deopt method and install >> it. >> >> * emitCode adds a little bit of code to the prologue and a lot of >> code to the epilogue. See description at the bottom for the data >> structures used by the never-ran path and the deopt path. >> >> HSAILHotSpotLIRGenerator.java >> >> * code added by Gilles to build the host graph for the host >> trampoline deopt method. I suppose some of this would be common >> to any gpu trampoline deopt and should be moved to some >> hsail-independent location. >> >> * code to handle the creation of a DeoptimizeOp for emitting HSAIL >> code for a deoptimization >> >> HSAILHotSpotLoweringProvider.java >> >> * refactored to support different strategies for different nodes. >> UnwindNode strategy is to get replaced by a DeoptimizeNode. >> >> HotSpotVMConfig.java >> >> * define offets to fields in the deopt data structures >> >> VMErrorNode.java >> >> * public access to constructor (used by building of host graph for >> trampoline code) >> >> HSAIL.java >> * some new non-allocatable registers defined (used by deopt paths) >> >> HSAILControlFlow.java >> * code to emit hsail for a deoptimizationNode >> >> ComputeProbabilityClosure.java >> * just using a change that Gilles made in the patch he gave me. >> >> >> mx/projects was affected by the move of ExternalCompilationResult to >> com.oracle.graal.gpu. In addition, several files had one line import >> changes from the move of ExternalCompilationResult. >> >> >> hotspot source changes >> ====================== >> >> gpu_hsail.cpp, hpp >> >> * the execute_kernel routine pushes an extra parameter where deopt info can be saved >> >> * while pushing kernel args, keeps track if any are null and if so >> sets some new gpu_exception fields in thread structure which gets >> used when thread returns to java mode >> >> * on return from kernel checks if any deopt occurred. If so, >> >> * runs any deopting workitems thru the trampoline deopt code >> which ends up running the kernel method thru the interpreter >> for that workitem. >> >> * runs any never-ran workitems using simple javaCall. >> >> gpu_hsail_Frame.hpp >> * new structure that defines the layout of a physical HSAIL frame >> >> hsailArgumentsBase.*, hsailKernelArguments.hpp hsailJavaCallArguments.hpp >> * refactored to share code between kernel argument setup and >> javaCall argument setup >> >> javaClasses.cpp >> >> * contains logic to check the new gpu_exception fields in thread >> structure and if detected, set as top frame on return >> >> graalCompiler.cpp, hpp >> * logic added by Gilles for external_deopt_i2c >> >> javaCalls.cpp, hpp >> * logic added by Gilles for external_deopt_i2c >> >> sharedRuntime.cpp >> * maybe Gilles can explain why the assert was removed in the patch >> he gave me (it asserts if I put it back in) > > Yeah, that made me suspicious. It?s related to the changes in javaCalls but I couldn?t see (yet) why Gilles made these. If a HSAIL compilation contains a Deopt then we compile some code for the host architecture. This code looks like this: f(int deoptId, HSAILFrame* frame, int reasonAndAction, Object speculation) { switch(deoptId) { case 1: deopt(FrameState1(frame), reasonAndAction, speculation); case 2: deopt(FrameState2(frame), reasonAndAction, speculation); ... default: VM_Error("Error in HSAIL deopt. DeoptId=%d", deoptId); } } Where FrameState1 and FrameState2 build the correct framestate by extracting values from the HSAILFrame based on the HSAIL compilation's debug info. This special host method is installed and associated to the Method* for which we compiled HSAIL code. On deopt, we make a special javaCall to this Method* and in javaCall we make sure it uses our special nmethod and an i2c that is crafted for the special nmethod's signature rather than for the original method's signature. This allows us to get as close as we can to HotSpot's assumption regarding execution, how the stack should look like and how deoptimization works. In particular, there actually is a compiled frame for this Method* on the stack which is triggering the deoptimization and this compiled frame didn't just appear out of the blue but comes from a javaCall. The only divergence here is that the arguments we pass for this javaCall are not what you would expect from the signature of the method. For example even if the method may be virtual, we don't have a receiver. > >> >> thread.cpp, hpp >> * handle new gpu_exception fields >> >> vmStructs.cpp >> vmStructs_hsail.hpp >> * handle new hsail deopt structs >> >> >> > From java at stefan-marr.de Wed Mar 12 13:14:01 2014 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 12 Mar 2014 14:14:01 +0100 Subject: [Truffle] Eliminating Calls to Side-Effect Free Methods? Message-ID: <3C95665C-2888-4D38-9795-953051B3E080@stefan-marr.de> Hi: With the latest changes, TruffleSOM seems to get closer to ideal performance, however, there seem to be some general issues that do not yet work as I would hope/expect. I got a couple of micro benchmarks, which I would expect to be reduced to zero in an ideal situation. For instance the Dispatch benchmark. Essentially, it is two nested loops and a mono-morphic message send to a method that returns it?s argument. It looks more or less like this: benchmark = ( 1 to: 20000 do: [ :i | self method: i ] ) method: argument = ( ^argument ) outerBenchmarkLoop = ( 1 to: innerIterations do: [ self benchmark ] ) Now, the first tricky part is that a self send inside a loop implies the access to the outer lexical scope, and thereby the use of a materialized frame. I experimented a little with it, and it turns out that in the outer loop, the use of the materialized frame seems to be properly eliminated, in the inner loop however, it is not. As shown above, both loops are in separate methods, but are inlined as far as I can see in IGV. That's one of the issues. The other one is the cost of introducing a sequence node. When I increase the number of statements in the inner loop from 1 to 2, my compiler introduces an additional SequenceNode to hold them. I would expect that to be compiled away and not to imply any overhead, but its payload. However, going from 1 to 2 increases the runtime by more than the factor 2. Going to 3 or 4 statements shows then a more linear increase. But again, the main point is that these methods don't do anything but producing heat. So, I would really like to see them eliminated. In order to identify the culprit in IGV, I don't have enough experience yet. There are to many things I cannot really correlate with the input program. Are there perhaps known patterns I could look for to point out further optimization/specialization potential? Thanks a lot Stefan PS: to see the issue, you can do the following: git clone --recursive git at github.com:SOM-st/TruffleSOM.git ant jar mx --vm server vm -G:Dump= -Xbootclasspath/a:build/classes:libs/truffle.jar som.vm.Universe -cp Smalltalk:Examples/Benchmarks/DeltaBlue/ Examples/Benchmarks/BenchmarkHarness.som Dispatch 1000 0 2000 And there, in the output, the method is actually called #innerBenchmarkLoop as part of the benchmark harness. Should be the second to last thing that?s compiled after the benchmark completed. -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From java at stefan-marr.de Wed Mar 12 14:08:08 2014 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 12 Mar 2014 15:08:08 +0100 Subject: [Truffle] Changes to DispatchNodes Message-ID: <30A28D3F-48E3-4413-BA87-2782B08A9FF6@stefan-marr.de> Hi Chris: [cc list] As discussed, I changed the message dispatch of TruffleSOM a bit to simplify it and avoid another bunch of tests/branches at runtime. Now, I got a chain of dispatch nodes, where the first nodes (if available) do just a check for the Java class. [Note, I am using another strategy for boxed and unboxed objects, and I have ?builtin? classes which have Java class representations. So, this part covers already a lot of room.] After those simple cases [1], I have a special check node (introduced when necessary) that makes sure that for all following nodes, the receiver is guaranteed to be a SObject, which got a getSOMClass(.) method [2]. In case that check fails, I continue on a branch to an UninitializedDispatch node, and do the usual thing to introduce a new cached node. If it succeeds, I go on with the cache entries that are proper SObjects and the check does only read the class field and does a reference comparison [3]. The chain is terminated as usual with a Uninitialized node. The change gives up to 30% improvement on the various benchmarks. Especially the more complex ones seem to benefit from the simple tests. Things like Dispatch, which really just measures the method dispatch (and looping) overhead, doesn?t benefit at all. Probably because in those cases the optimizer is still ok with it. [Just guessing] The original motivation for the change was to see whether overall simpler and faster dispatch would avoid the need for early primitive specialization that avoids message sends and inline caching altogether, and well. No, it doesn?t. Fibonacci benefits with a 64% speedup from the early specialization, and even Richards and DeltaBlue still get 5% faster. So, it still seems to be better to avoid the dispatch altogether when possible. So, I am still thinking of changing TruffleDSL for my case to make that nicer. Best regards Stefan [1] https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/dispatch/CachedDispatchSimpleCheckNode.java [2] https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/dispatch/SObjectCheckDispatchNode.java [3] https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/dispatch/CachedDispatchSObjectCheckNode.java -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From chris at chrisseaton.com Wed Mar 12 15:12:45 2014 From: chris at chrisseaton.com (Chris Seaton) Date: Wed, 12 Mar 2014 15:12:45 +0000 Subject: [Truffle] Eliminating Calls to Side-Effect Free Methods? In-Reply-To: <3C95665C-2888-4D38-9795-953051B3E080@stefan-marr.de> References: <3C95665C-2888-4D38-9795-953051B3E080@stefan-marr.de> Message-ID: The problem with SequenceNode might be in the way that you hang onto the final result. That mutable local might be upsetting the PE. @Override @ExplodeLoop public Object executeGeneric(final VirtualFrame frame) { Object last = expressions[0].executeGeneric(frame); for (int i = 1; i < expressions.length; i++) { last = expressions[i].executeGeneric(frame); } return last; } Also, you're calling executeGeneric for all children, when you could executeVoid for all but the last. In excuteVoid you can only do side-effects and avoid producing a value. This is how Ruby does it, and it does go to nothing. @ExplodeLoop @Override public Object execute(VirtualFrame frame) { for (int n = 0; n < body.length - 1; n++) { body[n].executeVoid(frame); } return body[body.length - 1].execute(frame); } @ExplodeLoop @Override public void executeVoid(VirtualFrame frame) { for (int n = 0; n < body.length; n++) { body[n].executeVoid(frame); } } Chris On 12 March 2014 13:14, Stefan Marr wrote: > Hi: > > With the latest changes, TruffleSOM seems to get closer to ideal > performance, > however, there seem to be some general issues that do not yet work as I > would hope/expect. > > I got a couple of micro benchmarks, which I would expect to be reduced to > zero in an ideal situation. > > For instance the Dispatch benchmark. Essentially, it is two nested loops > and a mono-morphic message send to a method that returns it?s argument. > > It looks more or less like this: > > benchmark = ( 1 to: 20000 do: [ :i | self method: i ] ) > method: argument = ( ^argument ) > > outerBenchmarkLoop = ( > 1 to: innerIterations do: [ self benchmark ] > ) > > Now, the first tricky part is that a self send inside a loop implies the > access to the outer lexical scope, and thereby the use of a materialized > frame. I experimented a little with it, and it turns out that in the outer > loop, the use of the materialized frame seems to be properly eliminated, in > the inner loop however, it is not. As shown above, both loops are in > separate methods, but are inlined as far as I can see in IGV. > > That's one of the issues. The other one is the cost of introducing a > sequence node. > When I increase the number of statements in the inner loop from 1 to 2, my > compiler introduces an additional SequenceNode to hold them. I would expect > that to be compiled away and not to imply any overhead, but its payload. > However, going from 1 to 2 increases the runtime by more than the factor 2. > Going to 3 or 4 statements shows then a more linear increase. > > But again, the main point is that these methods don't do anything but > producing heat. So, I would really like to see them eliminated. > > In order to identify the culprit in IGV, I don't have enough experience > yet. There are to many things I cannot really correlate with the input > program. > > Are there perhaps known patterns I could look for to point out further > optimization/specialization potential? > > Thanks a lot > Stefan > > PS: to see the issue, you can do the following: > > git clone --recursive git at github.com:SOM-st/TruffleSOM.git > ant jar > mx --vm server vm -G:Dump= > -Xbootclasspath/a:build/classes:libs/truffle.jar som.vm.Universe -cp > Smalltalk:Examples/Benchmarks/DeltaBlue/ > Examples/Benchmarks/BenchmarkHarness.som Dispatch 1000 0 2000 > > And there, in the output, the method is actually called > #innerBenchmarkLoop as part of the benchmark harness. > Should be the second to last thing that?s compiled after the benchmark > completed. > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > From java at stefan-marr.de Wed Mar 12 15:18:50 2014 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 12 Mar 2014 16:18:50 +0100 Subject: [Truffle] Eliminating Calls to Side-Effect Free Methods? In-Reply-To: References: <3C95665C-2888-4D38-9795-953051B3E080@stefan-marr.de> Message-ID: <1467EB37-D5A5-4355-8406-BC4DDFA7CEE6@stefan-marr.de> Hi Chris: On 12 Mar 2014, at 16:12, Chris Seaton wrote: > This is how Ruby does it, and it does go to nothing. I should have mentioned: I tried that in the morning ;) Well, I did not introduce any executeVoid, because generally everything is an expression with a return value. But I tried to rewrite the SequenceNode based on what I saw in your Ruby implementation. Also, because my pervious not so good experience with @ExplodeLoop. But, the effect was zero. Normally, the PE should see that `last` is never read but at the end. Is the executeVoid an essential thing? Did you notice any difference with having it/not having it? Thanks Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From chris at chrisseaton.com Wed Mar 12 15:20:25 2014 From: chris at chrisseaton.com (Chris Seaton) Date: Wed, 12 Mar 2014 15:20:25 +0000 Subject: [Truffle] Changes to DispatchNodes In-Reply-To: <30A28D3F-48E3-4413-BA87-2782B08A9FF6@stefan-marr.de> References: <30A28D3F-48E3-4413-BA87-2782B08A9FF6@stefan-marr.de> Message-ID: Those nodes look optimal to me. A single reference comparison guard in each - that's what you want to see. The only suggestion would be to have two interfaces AbstractCachedUnboxedDispatchNode and AbstractCachedBoxedDispatchNode. Then you can statically type your executeDispatch to either take Object or SObject and avoid the unsafe cast. I'm surprised that you are still seeing overhead from method calls and needing to specialise early, but you are implementing a different language to me so I'm sure you have different bottlenecks. I'd add the extra note of caution that any future Truffle tooling like profilers, debuggers and so on may expect a Truffle CallTarget boundary for guest language methods to be able to automatically 'read' your guest language. Chris On 12 March 2014 14:08, Stefan Marr wrote: > Hi Chris: > [cc list] > > As discussed, I changed the message dispatch of TruffleSOM a bit to > simplify it and avoid another bunch of tests/branches at runtime. > > Now, I got a chain of dispatch nodes, where the first nodes (if available) > do just a check for the Java class. > [Note, I am using another strategy for boxed and unboxed objects, and I > have ?builtin? classes which have Java class representations. So, this part > covers already a lot of room.] > > After those simple cases [1], I have a special check node (introduced when > necessary) that makes sure that for all following nodes, the receiver is > guaranteed to be a SObject, which got a getSOMClass(.) method [2]. > In case that check fails, I continue on a branch to an > UninitializedDispatch node, and do the usual thing to introduce a new > cached node. > > If it succeeds, I go on with the cache entries that are proper SObjects > and the check does only read the class field and does a reference > comparison [3]. The chain is terminated as usual with a Uninitialized node. > > The change gives up to 30% improvement on the various benchmarks. > Especially the more complex ones seem to benefit from the simple tests. > Things like Dispatch, which really just measures the method dispatch (and > looping) overhead, doesn?t benefit at all. Probably because in those cases > the optimizer is still ok with it. [Just guessing] > > The original motivation for the change was to see whether overall simpler > and faster dispatch would avoid the need for early primitive specialization > that avoids message sends and inline caching altogether, and well. No, it > doesn?t. Fibonacci benefits with a 64% speedup from the early > specialization, and even Richards and DeltaBlue still get 5% faster. So, it > still seems to be better to avoid the dispatch altogether when possible. > So, I am still thinking of changing TruffleDSL for my case to make that > nicer. > > Best regards > Stefan > > [1] > https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/dispatch/CachedDispatchSimpleCheckNode.java > [2] > https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/dispatch/SObjectCheckDispatchNode.java > [3] > https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/dispatch/CachedDispatchSObjectCheckNode.java > > > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > From chris at chrisseaton.com Wed Mar 12 15:29:16 2014 From: chris at chrisseaton.com (Chris Seaton) Date: Wed, 12 Mar 2014 15:29:16 +0000 Subject: [Truffle] Eliminating Calls to Side-Effect Free Methods? In-Reply-To: <1467EB37-D5A5-4355-8406-BC4DDFA7CEE6@stefan-marr.de> References: <3C95665C-2888-4D38-9795-953051B3E080@stefan-marr.de> <1467EB37-D5A5-4355-8406-BC4DDFA7CEE6@stefan-marr.de> Message-ID: Hmm... I'll try actually running your code later and get back to you. Here's one example of where I use executeVoid for a real benefit. The Ruby fannkuch code swaps values using multiple assignment: a, b = b, a This is syntactic sugar for: [a, b] = [b, a] That is, an array assignment. Assignments in Ruby return the assigned value, so the swap expression allocates and swaps an array. I desugar to: t1 = b t2 = a a = t1 b = t2 return Array.new(t1, t2) If we execute that last line, we allocate an Array object on the inner loop of the benchmark. If we executeVoid, we don't. I've wrapped this pattern up into ElidableResultNode. https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/truffle/nodes/control/ElidableResultNode.java https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/truffle/translator/Translator.java#L1322 This has a side-effect producing part (the assignment in this case) and a result producing part (the array allocation in this case). If you executeVoid it doesn't execute the latter. So this is the difference between allocating memory in a benchmark, and not having to allocate memory - obviously a big deal. When you start thinking about it there's a few magic places you can use executeVoid, depending on how your language works. Chris On 12 March 2014 15:18, Stefan Marr wrote: > Hi Chris: > > On 12 Mar 2014, at 16:12, Chris Seaton wrote: > > > This is how Ruby does it, and it does go to nothing. > > I should have mentioned: I tried that in the morning ;) > > Well, I did not introduce any executeVoid, because generally everything is > an expression with a return value. > But I tried to rewrite the SequenceNode based on what I saw in your Ruby > implementation. Also, because my pervious not so good experience with > @ExplodeLoop. But, the effect was zero. > Normally, the PE should see that `last` is never read but at the end. > > Is the executeVoid an essential thing? Did you notice any difference with > having it/not having it? > > Thanks > Stefan > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > From andreas.woess at jku.at Wed Mar 12 15:53:36 2014 From: andreas.woess at jku.at (Andreas Woess) Date: Wed, 12 Mar 2014 16:53:36 +0100 Subject: [Truffle] Eliminating Calls to Side-Effect Free Methods? In-Reply-To: <3C95665C-2888-4D38-9795-953051B3E080@stefan-marr.de> References: <3C95665C-2888-4D38-9795-953051B3E080@stefan-marr.de> Message-ID: <53208300.6000100@jku.at> Hi Stefan, I've looked at a graph in the IGV and found some problems related to methods not being inlined when they could be. I have to investigate whether this is a problem in the partial evaluator. I would be surprised if the sequence node itself introduced any overhead. - andreas On 12.03.2014 14:14, Stefan Marr wrote: > Hi: > > With the latest changes, TruffleSOM seems to get closer to ideal performance, > however, there seem to be some general issues that do not yet work as I would hope/expect. > > I got a couple of micro benchmarks, which I would expect to be reduced to zero in an ideal situation. > > For instance the Dispatch benchmark. Essentially, it is two nested loops and a mono-morphic message send to a method that returns it?s argument. > > It looks more or less like this: > > benchmark = ( 1 to: 20000 do: [ :i | self method: i ] ) > method: argument = ( ^argument ) > > outerBenchmarkLoop = ( > 1 to: innerIterations do: [ self benchmark ] > ) > > Now, the first tricky part is that a self send inside a loop implies the access to the outer lexical scope, and thereby the use of a materialized frame. I experimented a little with it, and it turns out that in the outer loop, the use of the materialized frame seems to be properly eliminated, in the inner loop however, it is not. As shown above, both loops are in separate methods, but are inlined as far as I can see in IGV. > > That's one of the issues. The other one is the cost of introducing a sequence node. > When I increase the number of statements in the inner loop from 1 to 2, my compiler introduces an additional SequenceNode to hold them. I would expect that to be compiled away and not to imply any overhead, but its payload. However, going from 1 to 2 increases the runtime by more than the factor 2. Going to 3 or 4 statements shows then a more linear increase. > > But again, the main point is that these methods don't do anything but producing heat. So, I would really like to see them eliminated. > > In order to identify the culprit in IGV, I don't have enough experience yet. There are to many things I cannot really correlate with the input program. > > Are there perhaps known patterns I could look for to point out further optimization/specialization potential? > > Thanks a lot > Stefan > > PS: to see the issue, you can do the following: > > git clone --recursive git at github.com:SOM-st/TruffleSOM.git > ant jar > mx --vm server vm -G:Dump= -Xbootclasspath/a:build/classes:libs/truffle.jar som.vm.Universe -cp Smalltalk:Examples/Benchmarks/DeltaBlue/ Examples/Benchmarks/BenchmarkHarness.som Dispatch 1000 0 2000 > > And there, in the output, the method is actually called #innerBenchmarkLoop as part of the benchmark harness. > Should be the second to last thing that?s compiled after the benchmark completed. > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From java at stefan-marr.de Wed Mar 12 15:57:21 2014 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 12 Mar 2014 16:57:21 +0100 Subject: [Truffle] Eliminating Calls to Side-Effect Free Methods? In-Reply-To: <53208300.6000100@jku.at> References: <3C95665C-2888-4D38-9795-953051B3E080@stefan-marr.de> <53208300.6000100@jku.at> Message-ID: <6F23FD53-B4DD-46BC-8A99-92773696FFC1@stefan-marr.de> Hi Andreas: On 12 Mar 2014, at 16:53, Andreas Woess wrote: > I've looked at a graph in the IGV and found some problems related to > methods not being inlined when they could be. I have to investigate > whether this is a problem in the partial evaluator. Great, thanks a lot for having a look! At the moment, I am just implementing the evaluateVoid(.). Thinking about it, it seems to be a good way to propagate at least within a method, that all side-effect free executions can be ignored. Let?s see what that gives. Thanks Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From java at stefan-marr.de Wed Mar 12 17:11:00 2014 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 12 Mar 2014 18:11:00 +0100 Subject: [Truffle] Eliminating Calls to Side-Effect Free Methods? In-Reply-To: <6F23FD53-B4DD-46BC-8A99-92773696FFC1@stefan-marr.de> References: <3C95665C-2888-4D38-9795-953051B3E080@stefan-marr.de> <53208300.6000100@jku.at> <6F23FD53-B4DD-46BC-8A99-92773696FFC1@stefan-marr.de> Message-ID: <692B71F5-9F3F-415B-91B3-3E4FF5764632@stefan-marr.de> Hi: On 12 Mar 2014, at 16:57, Stefan Marr wrote: > At the moment, I am just implementing the evaluateVoid(.). > Thinking about it, it seems to be a good way to propagate at least within a method, that all side-effect free executions can be ignored. > > Let?s see what that gives. Looks like Smalltalk just has a too small granularity of methods, and not really the constructs to get big benefits out of executeVoid(). Got only one benchmark showing a little speedup, the rest remains unchanged. I guess, it could still help the partial evaluator but that would mean, I would need callVoid(.) and related to propagate the executeVoid calls through the method calls. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From andreas.woess at jku.at Wed Mar 12 17:24:15 2014 From: andreas.woess at jku.at (Andreas Woess) Date: Wed, 12 Mar 2014 18:24:15 +0100 Subject: [Truffle] Eliminating Calls to Side-Effect Free Methods? In-Reply-To: <6F23FD53-B4DD-46BC-8A99-92773696FFC1@stefan-marr.de> References: <3C95665C-2888-4D38-9795-953051B3E080@stefan-marr.de> <53208300.6000100@jku.at> <6F23FD53-B4DD-46BC-8A99-92773696FFC1@stefan-marr.de> Message-ID: <5320983F.4030106@jku.at> Hi Stefan, find here a proposed fix to the PE: https://gist.github.com/woess/d3276080dc18f8926f2f and here a small patch for TruffleSOM: https://gist.github.com/woess/90ff49f009f182c5276e that gave me a nice speedup on your dispatch benchmark. - andreas On 12.03.2014 16:57, Stefan Marr wrote: > Hi Andreas: > > On 12 Mar 2014, at 16:53, Andreas Woess wrote: > >> I've looked at a graph in the IGV and found some problems related to >> methods not being inlined when they could be. I have to investigate >> whether this is a problem in the partial evaluator. > Great, thanks a lot for having a look! > > At the moment, I am just implementing the evaluateVoid(.). > Thinking about it, it seems to be a good way to propagate at least within a method, that all side-effect free executions can be ignored. > > Let?s see what that gives. > > Thanks > Stefan > > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From java at stefan-marr.de Wed Mar 12 18:42:31 2014 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 12 Mar 2014 19:42:31 +0100 Subject: [Truffle] Eliminating Calls to Side-Effect Free Methods? In-Reply-To: <5320983F.4030106@jku.at> References: <3C95665C-2888-4D38-9795-953051B3E080@stefan-marr.de> <53208300.6000100@jku.at> <6F23FD53-B4DD-46BC-8A99-92773696FFC1@stefan-marr.de> <5320983F.4030106@jku.at> Message-ID: <226B15EF-342B-4F6F-980A-0573FF97D599@stefan-marr.de> Hi Andreas: On 12 Mar 2014, at 18:24, Andreas Woess wrote: > find here a proposed fix to the PE: > https://gist.github.com/woess/d3276080dc18f8926f2f Thanks. Not sure whether that?s your patch, or whether it is something in my code, but most benchmarks break with this error: [truffle] opt fail Method BubbleSort>>#$block method::/home/smarr/.local/SOM/Examples/Benchmarks//BubbleSort.som:34 at 33cb5951|Reason com.oracle.graal.nodes.util.GraphUtil$2: The location argument could not be resolved to a constant. Will try to look into it later tonight. > and here a small patch for TruffleSOM: > https://gist.github.com/woess/90ff49f009f182c5276e > that gave me a nice speedup on your dispatch benchmark. Is applied. Thanks Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From andreas.woess at jku.at Wed Mar 12 19:14:32 2014 From: andreas.woess at jku.at (Andreas Woess) Date: Wed, 12 Mar 2014 20:14:32 +0100 Subject: [Truffle] Eliminating Calls to Side-Effect Free Methods? In-Reply-To: <226B15EF-342B-4F6F-980A-0573FF97D599@stefan-marr.de> References: <3C95665C-2888-4D38-9795-953051B3E080@stefan-marr.de> <53208300.6000100@jku.at> <6F23FD53-B4DD-46BC-8A99-92773696FFC1@stefan-marr.de> <5320983F.4030106@jku.at> <226B15EF-342B-4F6F-980A-0573FF97D599@stefan-marr.de> Message-ID: <5320B218.1010509@jku.at> That's an indicator that a FrameSlot is not truly constant. -G:+DumpOnError should provide more context. My first suspicion would be SBlock.outerSelfSlot. - andreas On 2014-03-12 19:42, Stefan Marr wrote: > Hi Andreas: > > On 12 Mar 2014, at 18:24, Andreas Woess wrote: > >> find here a proposed fix to the PE: >> https://gist.github.com/woess/d3276080dc18f8926f2f > Thanks. Not sure whether that?s your patch, or whether it is something in my code, but most benchmarks break with this error: > > [truffle] opt fail Method BubbleSort>>#$block method::/home/smarr/.local/SOM/Examples/Benchmarks//BubbleSort.som:34 at 33cb5951|Reason com.oracle.graal.nodes.util.GraphUtil$2: The location argument could not be resolved to a constant. > > Will try to look into it later tonight. > >> and here a small patch for TruffleSOM: >> https://gist.github.com/woess/90ff49f009f182c5276e >> that gave me a nice speedup on your dispatch benchmark. > Is applied. > > Thanks > Stefan > > From java at stefan-marr.de Wed Mar 12 23:49:35 2014 From: java at stefan-marr.de (Stefan Marr) Date: Thu, 13 Mar 2014 00:49:35 +0100 Subject: [Truffle] Eliminating Calls to Side-Effect Free Methods? In-Reply-To: <5320B218.1010509@jku.at> References: <3C95665C-2888-4D38-9795-953051B3E080@stefan-marr.de> <53208300.6000100@jku.at> <6F23FD53-B4DD-46BC-8A99-92773696FFC1@stefan-marr.de> <5320983F.4030106@jku.at> <226B15EF-342B-4F6F-980A-0573FF97D599@stefan-marr.de> <5320B218.1010509@jku.at> Message-ID: Hi Andreas: On 12 Mar 2014, at 20:14, Andreas Woess wrote: > That's an indicator that a FrameSlot is not truly constant. > -G:+DumpOnError should provide more context. My first suspicion would be > SBlock.outerSelfSlot. Yes, indeed. I guess a good rule to advocate for would be that FrameSlot should stay with the nodes. With that fixed, you are my hero! (for the moment, there is more to be done ;)) The fix you proposed for the PE gives a massive improvement across the board. Runtime decreases on average by 22% (max. 67%), DeltaBlue down by 43%, Richards down by 31%. http://som-speed.stefan-marr.de/comparison/?exe=9%2BL%2Bmaster%2C11%2BL%2Bmaster&ben=83%2C47%2C106%2C37%2C111%2C85%2C93%2C91%2C94%2C64%2C87%2C97%2C69%2C88%2C105%2C77%2C59%2C74%2C41%2C73%2C110&env=1&hor=true&bas=11%2BL%2Bmaster&chart=normal+bars http://som-speed.stefan-marr.de/changes/?tre=3&rev=c002b9be8bbed2ecf0c7a3fce93f9c108563e73e&exe=9&env=1 This makes TruffleSOM finally competitive with RTruffleSOM. I still need to address the issues with object fields however. Will look at what Chris did for Ruby, I think. The only other remaining strange outlier is the Recurse benchmark. Haven?t had the time to look into it, hope to get to it over the weekend. Thanks again! Stefan PS: I haven?t looked into it further, but I think all the tracing code is terribly fragile. Just from looking at it, it looks strangely hardcoded, and with the changed PE, I get a lot of null pointers, and cast errors when I enable. > > - andreas > > On 2014-03-12 19:42, Stefan Marr wrote: >> Hi Andreas: >> >> On 12 Mar 2014, at 18:24, Andreas Woess wrote: >> >>> find here a proposed fix to the PE: >>> https://gist.github.com/woess/d3276080dc18f8926f2f >> Thanks. Not sure whether that?s your patch, or whether it is something in my code, but most benchmarks break with this error: >> >> [truffle] opt fail Method BubbleSort>>#$block method::/home/smarr/.local/SOM/Examples/Benchmarks//BubbleSort.som:34 at 33cb5951|Reason com.oracle.graal.nodes.util.GraphUtil$2: The location argument could not be resolved to a constant. >> >> Will try to look into it later tonight. >> >>> and here a small patch for TruffleSOM: >>> https://gist.github.com/woess/90ff49f009f182c5276e >>> that gave me a nice speedup on your dispatch benchmark. >> Is applied. >> >> Thanks >> Stefan >> >> > -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From doug.simon at oracle.com Thu Mar 13 02:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 13 Mar 2014 02:00:07 +0000 Subject: hg: graal/graal: 16 new changesets Message-ID: <201403130200.s2D20SEt004432@aojmv0008> Changeset: 4eac66a9b87d Author: Thomas Wuerthinger Date: 2014-03-11 16:16 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4eac66a9b87d Remove reference to graph in LIRGenerator. ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.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/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! 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/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/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/nfi/HotSpotNativeFunctionInterface.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.lir/src/com/oracle/graal/lir/RedundantMoveElimination.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: 8836f566b0bc Author: Thomas Wuerthinger Date: 2014-03-11 16:28 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8836f566b0bc Remove withScope parameter on GraalCompiler.compileGraph. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InfopointReasonTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.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/nfi/HotSpotNativeFunctionInterface.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! graal/com.oracle.graal.java.decompiler.test/src/com/oracle/graal/java/decompiler/test/TestUtil.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: 8bdebcc53d15 Author: Thomas Wuerthinger Date: 2014-03-11 16:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8bdebcc53d15 Remove nodesForBlock mapping in LIR data structure. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIR.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java Changeset: 4ff08c0366ae Author: Thomas Wuerthinger Date: 2014-03-11 16:55 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4ff08c0366ae Encapsulate LIR class fields. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/MoveResolver.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIR.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinterObserver.java Changeset: 59460dd271a5 Author: Thomas Wuerthinger Date: 2014-03-11 17:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/59460dd271a5 Add experimental AbstractBlock interface to make ComputeBlockOrder generic. ! graal/com.oracle.graal.alloc/src/com/oracle/graal/alloc/ComputeBlockOrder.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/AbstractBlock.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/Block.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/NodesToDoubles.java Changeset: 594ee32296ff Author: Thomas Wuerthinger Date: 2014-03-11 17:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/594ee32296ff Fix warning. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java Changeset: ff423834a2dc Author: Josef Eisl Date: 2014-03-11 18:22 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ff423834a2dc Remove NodesToDoubles debug output from emitLIR. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/NodesToDoubles.java Changeset: cf6092d510c6 Author: Josef Eisl Date: 2014-03-12 08:57 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/cf6092d510c6 merge Changeset: 38ca365c09ca Author: Josef Eisl Date: 2014-03-12 09:36 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/38ca365c09ca Fix eclipseformat. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java Changeset: 1a9dca3c3fd7 Author: Roland Schatz Date: 2014-03-12 10:19 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1a9dca3c3fd7 Relax wrong assertion. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/OnStackReplacementPhase.java Changeset: 42013bd831d6 Author: Josef Eisl Date: 2014-03-12 11:06 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/42013bd831d6 Make LinearScan use AbstractBlock. ! graal/com.oracle.graal.alloc/src/com/oracle/graal/alloc/ComputeBlockOrder.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/RegisterVerifier.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIR.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/AbstractBlock.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/BlockMap.java Changeset: e328f28f7401 Author: Christian Wirth Date: 2014-03-12 11:23 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e328f28f7401 fix for mx, did not compile on Windows ! mxtool/mx.py Changeset: e666c172c9aa Author: Bernhard Urban Date: 2014-03-12 11:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e666c172c9aa mx: some cleanup around sha1 digest support ! mxtool/mx.py Changeset: 1ac6195ee586 Author: Bernhard Urban Date: 2014-03-12 11:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1ac6195ee586 mx: use os.sep ! mxtool/mx.py Changeset: 7668297a2e67 Author: Bernhard Urban Date: 2014-03-12 13:36 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7668297a2e67 mx: compute sha1 digest blockwise ! mxtool/mx.py Changeset: 8c4a3d9308a7 Author: twisti Date: 2014-03-12 12:40 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8c4a3d9308a7 fixed FindBugs bugs ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Assumptions.java ! 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/Register.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/VirtualObject.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/AbstractJavaProfile.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ExceptionHandler.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Value.java ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/DebugInfoBuilder.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugHistogramAsciiPrinter.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.hsail/src/com/oracle/graal/hotspot/hsail/ForEachToGraal.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.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/HotSpotForeignCallsProviderImpl.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/HotSpotMetaAccessProvider.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/HotSpotResolvedPrimitiveType.java ! graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/Decompiler.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeDisassembler.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/IntegerTestNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionProcessor.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ValueAnchorCleanupPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/MergeableState.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/StringSubstitutions.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleDebugJavaMethod.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleExpansionLogger.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/ReadEliminationBlockState.java ! mx/projects From tom.deneau at amd.com Thu Mar 13 18:17:11 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 13 Mar 2014 18:17:11 +0000 Subject: nextLastFixed == null in LoweringPhase.process Message-ID: Question from a newbie snippet writer... I have a snippet (for NewInstanceNode replacement) that is calling Deoptimize.deopt conditionally but in the particular simple test case I am running it will generate code that unconditionally takes the deopt path. When I get to this part of the code (LoweringPhase.process) after the replacement of the snippet into the graph, nextLastFixed is null, so we hit a nullPointerException. Does this mean there is something wrong with my snippet or should there be some logic in here to handle the case where nextLastFixed == null? -- Tom if (!nextNode.isAlive()) { // can happen when the rest of the block is killed by lowering // (e.g. by an unconditional deopt) break; } else { Node nextLastFixed = nextNode.predecessor(); if (!(nextLastFixed instanceof FixedWithNextNode)) { // insert begin node, to have a valid last fixed for next lowerable node. // This is about lowering a FixedWithNextNode to a control split while this // FixedWithNextNode is followed by some kind of BeginNode. // For example the when a FixedGuard followed by a loop exit is lowered to a // control-split + deopt. BeginNode begin = node.graph().add(new BeginNode()); nextLastFixed.replaceFirstSuccessor(nextNode, begin); begin.setNext(nextNode); nextLastFixed = begin; } loweringTool.setLastFixedNode((FixedWithNextNode) nextLastFixed); } From andreas.woess at jku.at Thu Mar 13 18:58:36 2014 From: andreas.woess at jku.at (Andreas Woess) Date: Thu, 13 Mar 2014 19:58:36 +0100 Subject: [Truffle] Eliminating Calls to Side-Effect Free Methods? In-Reply-To: References: <3C95665C-2888-4D38-9795-953051B3E080@stefan-marr.de> <53208300.6000100@jku.at> <6F23FD53-B4DD-46BC-8A99-92773696FFC1@stefan-marr.de> <5320983F.4030106@jku.at> <226B15EF-342B-4F6F-980A-0573FF97D599@stefan-marr.de> <5320B218.1010509@jku.at> Message-ID: <5321FFDC.6050500@jku.at> glad to have helped. looking at the comparison, there's still quite some room for improvement. another day... ;) - andreas On 2014-03-13 00:49, Stefan Marr wrote: > Hi Andreas: > > On 12 Mar 2014, at 20:14, Andreas Woess wrote: > >> That's an indicator that a FrameSlot is not truly constant. >> -G:+DumpOnError should provide more context. My first suspicion would be >> SBlock.outerSelfSlot. > Yes, indeed. I guess a good rule to advocate for would be that FrameSlot should stay with the nodes. > > With that fixed, you are my hero! (for the moment, there is more to be done ;)) > > The fix you proposed for the PE gives a massive improvement across the board. > Runtime decreases on average by 22% (max. 67%), DeltaBlue down by 43%, Richards down by 31%. > > http://som-speed.stefan-marr.de/comparison/?exe=9%2BL%2Bmaster%2C11%2BL%2Bmaster&ben=83%2C47%2C106%2C37%2C111%2C85%2C93%2C91%2C94%2C64%2C87%2C97%2C69%2C88%2C105%2C77%2C59%2C74%2C41%2C73%2C110&env=1&hor=true&bas=11%2BL%2Bmaster&chart=normal+bars > > http://som-speed.stefan-marr.de/changes/?tre=3&rev=c002b9be8bbed2ecf0c7a3fce93f9c108563e73e&exe=9&env=1 > > This makes TruffleSOM finally competitive with RTruffleSOM. > I still need to address the issues with object fields however. > Will look at what Chris did for Ruby, I think. > > The only other remaining strange outlier is the Recurse benchmark. > Haven?t had the time to look into it, hope to get to it over the weekend. > > Thanks again! > Stefan > > PS: I haven?t looked into it further, but I think all the tracing code is terribly fragile. Just from looking at it, it looks strangely hardcoded, and with the changed PE, I get a lot of null pointers, and cast errors when I enable. > > >> - andreas >> >> On 2014-03-12 19:42, Stefan Marr wrote: >>> Hi Andreas: >>> >>> On 12 Mar 2014, at 18:24, Andreas Woess wrote: >>> >>>> find here a proposed fix to the PE: >>>> https://gist.github.com/woess/d3276080dc18f8926f2f >>> Thanks. Not sure whether that?s your patch, or whether it is something in my code, but most benchmarks break with this error: >>> >>> [truffle] opt fail Method BubbleSort>>#$block method::/home/smarr/.local/SOM/Examples/Benchmarks//BubbleSort.som:34 at 33cb5951|Reason com.oracle.graal.nodes.util.GraphUtil$2: The location argument could not be resolved to a constant. >>> >>> Will try to look into it later tonight. >>> >>>> and here a small patch for TruffleSOM: >>>> https://gist.github.com/woess/90ff49f009f182c5276e >>>> that gave me a nice speedup on your dispatch benchmark. >>> Is applied. >>> >>> Thanks >>> Stefan >>> >>> From doug.simon at oracle.com Fri Mar 14 02:00:23 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 14 Mar 2014 02:00:23 +0000 Subject: hg: graal/graal: 374 new changesets Message-ID: <201403140205.s2E25a4D006154@aojmv0008> Changeset: 92e34e6121ac Author: Andreas Woess Date: 2014-03-13 09:22 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/92e34e6121ac PartialEvaluator: include materialized frame methods ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java Changeset: 2a4d3ceb7ed3 Author: Josef Eisl Date: 2014-03-13 11:17 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2a4d3ceb7ed3 Fix CFGPrinter printNodes issue. Printing Nodes using the LIR is unsupported since 8bdebcc53d15. ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java Changeset: fd7fcd2d2072 Author: Doug Simon Date: 2014-03-12 21:47 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/fd7fcd2d2072 replaced == with .equals() for comparisons between JavaMethod/JavaField/JavaType values ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Assumptions.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/VirtualObject.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ExceptionHandler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/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/HotSpotResolvedPrimitiveType.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/FrameStateBuilder.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/VerifyOptionsPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ObjectEqualsNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnboxNode.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/MethodCallTargetNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/ObjectStamp.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/VirtualInstanceNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.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/src/com/oracle/graal/truffle/TruffleCache.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/PartialEscapeClosure.java Changeset: f14fb79ab265 Author: Doug Simon Date: 2014-03-12 21:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f14fb79ab265 made it an error to run the client VM on a Mac via mx (since the Mac java launcher translates '-client' to '-server') ! mx/mx_graal.py Changeset: ab1c093f15c2 Author: Doug Simon Date: 2014-03-12 21:50 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ab1c093f15c2 added unit test to ensure all classes in graal.jar comply with select global invariants + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/CheckGraalInvariants.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyUsageWithEquals.java Changeset: 7831c74266a7 Author: Doug Simon Date: 2014-03-12 21:52 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7831c74266a7 removed HotSpotResolvedJavaMethod.currentTask field ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java Changeset: 10e07aaeb54f Author: Doug Simon Date: 2014-03-12 21:55 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/10e07aaeb54f fixed pylint warning ! mx/mx_graal.py Changeset: a1ddf86f5d79 Author: Doug Simon Date: 2014-03-13 01:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a1ddf86f5d79 removed FindBugs annotations and dependency on FindBugs itself ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.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/HotSpotGraphCache.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/StringSubstitutions.java ! mx/projects Changeset: a0c31f940950 Author: Doug Simon Date: 2014-03-13 11:37 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a0c31f940950 use AssertionError subclass for verification errors found by VerifyPhases ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/CheckGraalInvariants.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/AheadOfTimeVerificationPhase.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/VerifyPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyUsageWithEquals.java Changeset: 37f7dfdbd25b Author: Doug Simon Date: 2014-03-13 11:37 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/37f7dfdbd25b Merge. Changeset: b8e62af091ee Author: Doug Simon Date: 2014-03-13 11:53 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b8e62af091ee added more context to CheckGraalInvariants failures ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/CheckGraalInvariants.java Changeset: 1ddbe67f6f77 Author: Doug Simon Date: 2014-03-13 13:27 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1ddbe67f6f77 Merge. Changeset: cdc20b409a9c Author: Doug Simon Date: 2014-03-13 13:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/cdc20b409a9c replaced == with .equals() ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java Changeset: 8c0e92c8c45b Author: Doug Simon Date: 2014-03-13 14:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8c0e92c8c45b more workarounds to support clang 5.1 on Mac OS X ! make/bsd/makefiles/gcc.make ! src/share/vm/opto/node.cpp Changeset: cd22c8dbda4f Author: Doug Simon Date: 2014-03-13 15:36 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/cd22c8dbda4f Made graph caching compilation local ! CHANGELOG.md ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CompilationResult.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.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/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotGraphCache.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/GraphCache.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/GraalOptions.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/HighTierContext.java ! graal/com.oracle.graal.runtime/src/com/oracle/graal/runtime/RuntimeProvider.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 ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalCompiler.hpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalEnv.cpp ! src/share/vm/graal/graalEnv.hpp ! src/share/vm/graal/graalJavaAccess.hpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 068a5117af73 Author: iris Date: 2013-12-12 15:27 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/068a5117af73 Added tag jdk9-b00 for changeset ce2d7e46f3c7 ! .hgtags Changeset: 050a626a8895 Author: iris Date: 2013-12-13 09:35 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/050a626a8895 8030068: Update .jcheck/conf files for JDK 9 Reviewed-by: mr ! .jcheck/conf Changeset: d8d1b22b1809 Author: darcy Date: 2013-12-26 11:16 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/d8d1b22b1809 8030656: Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp Summary: Switched version check to check for greater than or equal to 8, not equal to 8 Reviewed-by: dholmes, kamg ! src/share/vm/classfile/javaClasses.cpp Changeset: eb79bf22508b Author: sla Date: 2013-12-16 11:17 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/eb79bf22508b 8029798: Build warnings in windows/makefiles/sa.make Reviewed-by: sla Contributed-by: francis.andre.kampbell at orange.fr ! make/windows/makefiles/sa.make Changeset: b7cd330fd5b6 Author: zgu Date: 2013-12-16 10:57 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/b7cd330fd5b6 8026300: VM warning: increase O_BUFLEN in ostream.hpp -- output truncated occurs with fastdebug VM when printing flags Summary: Fixed wrong print string format Reviewed-by: sla, ccheung ! src/share/vm/runtime/globals.cpp Changeset: 0f2de9d724a9 Author: sla Date: 2013-12-16 10:34 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0f2de9d724a9 8028737: Remove JVM_AccessVMIntFlag / JVM_AccessVMBooleanFlag / JVM_VMBreakPoint Reviewed-by: dcubed, coleenp ! make/bsd/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-debug ! make/solaris/makefiles/mapfile-vers-debug ! src/share/vm/prims/jvm.cpp Changeset: dbcb1dd0785b Author: sla Date: 2013-12-18 08:39 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/dbcb1dd0785b 8029726: On OS X some dtrace probe names are mismatched with Solaris 8029727: On OS X dtrace probes CallMethodA/CallMethodV are not fired. 8029728: On OS X dtrace probes SetStaticBooleanField are not fired Reviewed-by: kamg, dsamersoff ! src/os/bsd/dtrace/hotspot.d ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp Changeset: 03e9e2e3028b Author: dsamersoff Date: 2013-12-18 20:32 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/03e9e2e3028b 8028408: unused-value warning on forte.cpp when build on Mac Summary: cast argument to void in function type definition Reviewed-by: sla, sspitsyn ! src/share/vm/prims/forte.cpp Changeset: 27c84ba76954 Author: dsamersoff Date: 2013-12-18 23:09 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/27c84ba76954 6969276: minor memory leak detected by cppcheck in agent/src/os/linux/symtab.c Summary: missed free call on error return Reviewed-by: sla, sspitsyn, igerasim ! agent/src/os/linux/symtab.c Changeset: 21db9a1d43ef Author: hseigel Date: 2013-12-23 10:13 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/21db9a1d43ef 8021774: [TESTBUG] Tests failed because of a warning in its output Summary: Remove check for warning Reviewed-by: zgu, mseledtsov Contributed-by: george.triantafillou at oracle.com ! test/runtime/NMT/CommandLineDetail.java ! test/runtime/NMT/CommandLineSummary.java ! test/runtime/NMT/CommandLineTurnOffNMT.java ! test/runtime/NMT/PrintNMTStatistics.java Changeset: 6c583aa36bc9 Author: iignatyev Date: 2013-12-23 20:56 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/6c583aa36bc9 8029070: memory leak in jmm_SetVMGlobal Reviewed-by: kvn, dholmes ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/services/management.cpp Changeset: 5b0fbe224dff Author: iignatyev Date: 2013-12-23 18:39 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/5b0fbe224dff Merge Changeset: a9683a647c9f Author: hseigel Date: 2013-12-23 18:44 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/a9683a647c9f 8023735: [TESTBUG] runtime/XCheckJniJsig/XCheckJSig.java fails on MacOS X Summary: Look for libjsig in correct locations and do not fail if it's not found Reviewed-by: zgu, ccheung ! test/runtime/XCheckJniJsig/XCheckJSig.java Changeset: 23c27f9ae1e8 Author: zgu Date: 2013-12-31 08:58 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/23c27f9ae1e8 6730115: Fastdebug VM crashes with "ExceptionMark destructor expects no pending exceptions" error Summary: Fixed incompatible uses of EXCEPTION_MARK and CHECK macros in AttachListener::init(), handle exception locally. Reviewed-by: minqi, coleenp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/attachListener.hpp Changeset: e89b54bf4e51 Author: hseigel Date: 2014-01-06 08:44 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/e89b54bf4e51 8030955: assert(_prologue != NULL) failed: prologue pointer must be initialized Summary: Allow multiple calls to PerfMemory::destroy() Reviewed-by: zgu, coleenp ! src/share/vm/runtime/perfMemory.cpp + test/runtime/PerfMemDestroy/PerfMemDestroy.java Changeset: 29985fccf378 Author: sla Date: 2014-01-07 10:50 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/29985fccf378 4990369: visibleMethods() and methodsByName() return wrong visible methods Reviewed-by: sspitsyn, coleenp ! agent/src/share/classes/sun/jvm/hotspot/jdi/ArrayTypeImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/ClassTypeImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/InterfaceTypeImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/ReferenceTypeImpl.java Changeset: 1a899ea6b7ed Author: sla Date: 2014-01-07 12:32 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1a899ea6b7ed 8031305: (hotspot) com.sun.management.VMOption is missing the ATTACH_ON_DEMAND origin Reviewed-by: jbachorik, mchung, dholmes ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp Changeset: ce86c36b8921 Author: coleenp Date: 2014-01-07 13:26 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/ce86c36b8921 8029178: Parallel class loading test anonymous-simple gets SIGSEGV in Metaspace::contains Summary: Metaspace::contains cannot look at purged metaspaces while CMS concurrently deallocates them. Reviewed-by: mgerdin, sspitsyn, jmasa ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/runtime/os.cpp Changeset: e9d5e8a38ae3 Author: dcubed Date: 2014-01-08 13:53 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e9d5e8a38ae3 Merge Changeset: ff355e26c78d Author: brutisso Date: 2013-12-16 08:54 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ff355e26c78d 8029524: Remove unsused method CollectedHeap::unsafe_max_alloc() Reviewed-by: pliden, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp Changeset: dd1b266713ea Author: brutisso Date: 2013-12-16 13:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/dd1b266713ea 8027440: DefNew does not log heap change information when a promotion failure occurs Reviewed-by: tamao, jmasa ! src/share/vm/memory/defNewGeneration.cpp + test/gc/defnew/HeapChangeLogging.java Changeset: d41bd7e90661 Author: tschatzl Date: 2014-01-07 13:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d41bd7e90661 8027364: PSScavenge accounts too large code section to StringTable unlink Summary: Correct timing measurement by modifying the scope of the GCTraceTime instance. Reviewed-by: ysr, tamao Contributed-by: Jeremy Manson ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp Changeset: 9982f3b7527b Author: ehelin Date: 2014-01-07 16:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9982f3b7527b Merge Changeset: c8907928a976 Author: ehelin Date: 2014-01-09 16:53 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c8907928a976 Merge Changeset: d49557091d18 Author: anoll Date: 2013-12-17 08:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d49557091d18 8029091: Bug in calculation of code cache sweeping interval Summary: Use signed data type so that no underflow can happen Reviewed-by: kvn, roland ! src/share/vm/runtime/sweeper.cpp Changeset: b8b5791fa045 Author: anoll Date: 2013-12-19 06:09 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b8b5791fa045 8026478: -XX:+VerifyAdapterSharing is broken Summary: Fix by considering all checks in StubRoutines Reviewed-by: kvn, twisti ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 49a31fd8b93d Author: anoll Date: 2013-12-19 14:08 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/49a31fd8b93d 8025277: Add -XX: flag to print code cache sweeper statistics Summary: New diagnostic flag prints statistics about the code cache sweeper Reviewed-by: kvn Contributed-by: tobi.hartmann at gmail.com ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp Changeset: d1af589627d4 Author: anoll Date: 2013-12-20 10:29 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d1af589627d4 8030783: Provide regression test for 8026478: -XX:+VerifyAdapterSharing is broken Summary: Added simple regression test Reviewed-by: iveresov + test/compiler/debug/VerifyAdapterSharing.java Changeset: 655663109d87 Author: anoll Date: 2013-12-20 10:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/655663109d87 8028052: compiler/startup/SmallCodeCacheStartup.java fails there is no 'no space to run compiler' in the output Summary: Weaken test so that configurations that have no C1 compiler pass Reviewed-by: iveresov ! test/compiler/startup/SmallCodeCacheStartup.java Changeset: 3e98456aab94 Author: iveresov Date: 2013-12-26 21:00 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/3e98456aab94 8027388: JVM crashes with SIGSEGV (0xb) at pc=0x00000001077cbbf6 Summary: Make object non-scalarizable if it has field with multiple bases one of which is null Reviewed-by: kvn, twisti ! src/share/vm/opto/escape.cpp Changeset: f9a4b59ae350 Author: iignatyev Date: 2013-12-31 19:26 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/f9a4b59ae350 8028587: New tests development for intrisics for basic operators - add, neg, inc, dec, sub, mul Reviewed-by: twisti Contributed-by: anton.ivanov at oracle.com + test/compiler/intrinsics/mathexact/sanity/AddExactIntTest.java + test/compiler/intrinsics/mathexact/sanity/AddExactLongTest.java + test/compiler/intrinsics/mathexact/sanity/DecrementExactIntTest.java + test/compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java + test/compiler/intrinsics/mathexact/sanity/IncrementExactIntTest.java + test/compiler/intrinsics/mathexact/sanity/IncrementExactLongTest.java + test/compiler/intrinsics/mathexact/sanity/IntrinsicBase.java + test/compiler/intrinsics/mathexact/sanity/MathIntrinsic.java + test/compiler/intrinsics/mathexact/sanity/MultiplyExactIntTest.java + test/compiler/intrinsics/mathexact/sanity/MultiplyExactLongTest.java + test/compiler/intrinsics/mathexact/sanity/NegateExactIntTest.java + test/compiler/intrinsics/mathexact/sanity/NegateExactLongTest.java + test/compiler/intrinsics/mathexact/sanity/SubtractExactIntTest.java + test/compiler/intrinsics/mathexact/sanity/SubtractExactLongTest.java + test/compiler/intrinsics/mathexact/sanity/Verifier.java ! test/compiler/tiered/NonTieredLevelsTest.java ! test/compiler/tiered/TieredLevelsTest.java ! 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: 866fafe5cc33 Author: hseigel Date: 2013-12-04 08:10 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/866fafe5cc33 8027458: VM anonymous classes: wrong context for protected access checks Summary: Use the anonymous class's host class for protected access checks Reviewed-by: acorn, coleenp, lfoltan ! src/share/vm/runtime/reflection.cpp Changeset: 7bc6b6227f14 Author: sla Date: 2013-12-04 14:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7bc6b6227f14 8029395: SA: jstack throws WrongTypeException Summary: SA missed some TLABs Reviewed-by: dsamersoff, mgerdin, brutisso ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java Changeset: e7b58922266b Author: mgronlun Date: 2013-12-05 12:35 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e7b58922266b 8028412: AsyncGetCallTrace() is broken on x86 in JDK 7u40 Reviewed-by: kvn, sspitsyn ! src/cpu/x86/vm/frame_x86.cpp Changeset: 5270f046a962 Author: hseigel Date: 2013-12-06 11:33 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/5270f046a962 8029415: java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java fails on all platforms with hs25-b61 Summary: Check first that a class is not a dynamically-generated bytecode associated with 1.4 reflection implementation, to emitting an ICCE of an invokespecial IMR of a method in an indirect superinterface. Reviewed-by: acorn, hseigel Contributed-by: lois.foltan at oracle.com ! src/share/vm/interpreter/linkResolver.cpp Changeset: 252066a125de Author: hseigel Date: 2013-12-10 16:18 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/252066a125de 8028741: Interface Method Resolution should skip static and non-public methods in j.l.Object Summary: Implementation of JDK 8 JVMS 5.4.3.4 specification change to skip static and non-public methods of java.lang.Object for interface method resolution. Reviewed-by: acorn, coleenp Contributed-by: lois.foltan at oracle.com ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! test/runtime/8024804/RegisterNatives.java Changeset: 46e2a5b0c076 Author: ehelin Date: 2013-12-09 08:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/46e2a5b0c076 8029326: G1 does not check if threads gets created Reviewed-by: brutisso, jmasa, jwilhelm ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 397385cc2c83 Author: sjohanss Date: 2013-12-10 10:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/397385cc2c83 8028993: Full collections with ParallelScavenge slower in JDK 8 compared to 7u40 Summary: Reducing the number of calls to follow_class_loader to speed up the marking phase. Also removed some unnecessary calls to adjust_klass. Reviewed-by: stefank, jmasa, mgerdin ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/oops/instanceClassLoaderKlass.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceMirrorKlass.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp Changeset: a2a3f08b96fa Author: stefank Date: 2013-12-09 10:03 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a2a3f08b96fa 8029106: JVM crashes in Metachunk::Metachunk during parallel class redefinition (PrivateMLetController, anonymous-simple_copy_1) Summary: Fixed overflow bug in VirtualSpaceNode::is_available Reviewed-by: mgerdin, brutisso, coleenp, jmasa ! src/share/vm/memory/metaspace.cpp Changeset: 22ae97935e05 Author: kvn Date: 2013-12-06 12:11 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/22ae97935e05 8028107: Kitchensink crashed with EAV Summary: check the state of caller and callee nmethods and skip call site patching if any of them is not alive Reviewed-by: jrose, twisti ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 6c4c27c5cc9a Author: twisti Date: 2013-12-06 16:43 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/6c4c27c5cc9a 8029366: ShouldNotReachHere error when creating an array with component type of void Reviewed-by: kvn ! src/share/vm/opto/memnode.cpp + test/compiler/reflection/ArrayNewInstanceOfVoid.java Changeset: 7683a2f8d7d4 Author: iignatyev Date: 2013-12-11 01:04 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/7683a2f8d7d4 8028122: [TESTBUG] compiler/regalloc/C1ObjectSpillInLogicOp.java Reviewed-by: kvn, twisti ! test/compiler/regalloc/C1ObjectSpillInLogicOp.java Changeset: 567455579fe4 Author: iignatyev Date: 2013-12-11 01:09 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/567455579fe4 8029153: [TESTBUG] test/compiler/7141637/SpreadNullArg.java fails because it expects NullPointerException Reviewed-by: twisti ! test/compiler/7141637/SpreadNullArg.java Changeset: cca85d826c8f Author: jprovino Date: 2013-12-11 13:51 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/cca85d826c8f 8029566: PPC: OrderAccess::load_acquire(julong) is broken Summary: JFR needs this fix to run on PPC Reviewed-by: sla, mikael ! src/share/vm/utilities/globalDefinitions_gcc.hpp Changeset: f3e0bcfff3ab Author: iveresov Date: 2013-12-12 11:25 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/f3e0bcfff3ab 8029668: Kithcensink crashed with guarantee(Assembler::is_simm13(disp)) failed: Do not match large constant offsets Summary: Bailout if we try to reference a stack location that we can't encode Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad Changeset: 8379a22ac89d Author: iignatyev Date: 2013-12-13 00:34 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/8379a22ac89d 8026941: [TESTBUG] java.lang.ClassNotFoundException: java.lang.invoke.InvokeGeneric Reviewed-by: kvn, vlivanov ! test/compiler/jsr292/ConcurrentClassLoadingTest.java Changeset: 9ae5189791f4 Author: drchase Date: 2013-12-12 15:11 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/9ae5189791f4 8029351: assert(bt != T_OBJECT) failed: Guard is incorrect in VM:defmeth Summary: replace test condition with reference to the proper predicate, encode folk wisdom into an assert Reviewed-by: twisti, coleenp ! src/share/vm/oops/generateOopMap.cpp Changeset: f9508a2fd4d8 Author: roland Date: 2013-12-13 09:25 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f9508a2fd4d8 8029383: assert(counter_changed) failed: failed dependencies, but counter didn't change Summary: no call to SystemDictionary::notice_modification() when class is defined through Unsafe.defineAnonymousClass() can caused missed dependency change. Reviewed-by: kvn, twisti ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 2353011244bd Author: hseigel Date: 2013-12-16 08:24 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/2353011244bd 8027804: JCK resolveMethod test fails expecting AbstractMethodError Summary: Create AME overpass methods and fix method search logic Reviewed-by: kamg, acorn, lfoltan, coleenp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp Changeset: e9b6b2aa5125 Author: coleenp Date: 2013-12-19 20:28 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/e9b6b2aa5125 8030633: nsk/jvmti/RedefineClasses/StressRedefine failed invalid method ordering length on Solaris Summary: A method with no declared methods was getting an AME overpass method with the latest change. The method_ordering array was not updated for the new methods. Reviewed-by: dcubed, acorn, dsamersoff, lfoltan, hseigel ! src/share/vm/classfile/defaultMethods.cpp Changeset: de6a9e811145 Author: mikael Date: 2013-12-24 11:48 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/de6a9e811145 8029233: Update copyright year to match last edit in jdk8 hotspot repository for 2013 Summary: Copyright year updated for files modified during 2013 Reviewed-by: twisti, iveresov ! agent/make/Makefile ! agent/src/os/linux/libproc.h ! agent/src/os/linux/salibelf.c ! agent/src/os/linux/symtab.c ! agent/src/os/solaris/proc/saproc.cpp ! agent/src/os/win32/windbg/sawindbg.cpp ! agent/src/share/classes/sun/jvm/hotspot/CLHSDB.java ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HSDB.java ! agent/src/share/classes/sun/jvm/hotspot/LinuxVtblAccess.java ! agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciEnv.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/CompileTask.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxOopHandle.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/x86/LinuxX86CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgCDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windows/amd64/WindowsAMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windows/x86/WindowsX86CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/JVMTIThreadState.java ! agent/src/share/classes/sun/jvm/hotspot/memory/CMSCollector.java ! agent/src/share/classes/sun/jvm/hotspot/memory/DictionaryEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodCounters.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_amd64/BsdAMD64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FlagDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JSnap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/ObjectHistogram.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/StackTrace.java ! agent/src/share/classes/sun/jvm/hotspot/tools/SysPropsDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/JSDB.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/ui/SAPanel.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapGXLWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaInstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/minimal1.make ! make/hotspot.script ! make/linux/makefiles/adlc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/minimal1.make ! make/linux/makefiles/saproc.make ! make/sa.files ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/gcc.make ! make/windows/build_vm_def.sh ! make/windows/makefiles/adlc.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/product.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sa.make ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/c1_globals_sparc.hpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/c2_init_sparc.cpp ! src/cpu/sparc/vm/disassembler_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/sparc/vm/globalDefinitions_sparc.hpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/register_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/sparc/vm/vmStructs_sparc.hpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/c1_globals_x86.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/globalDefinitions_x86.hpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86.hpp ! src/cpu/x86/vm/vmStructs_x86.hpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/entryFrame_zero.hpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/globals_zero.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/jni_zero.h ! 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/sharkFrame_zero.hpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/cpu/zero/vm/vmStructs_zero.hpp ! src/cpu/zero/vm/vtableStubs_zero.cpp ! src/os/bsd/dtrace/jvm_dtrace.c ! src/os/posix/vm/os_posix.hpp ! src/os/solaris/dtrace/jvm_dtrace.c ! src/os/solaris/vm/globals_solaris.hpp ! src/os/windows/vm/decoder_windows.hpp ! src/os_cpu/bsd_x86/vm/bsd_x86_32.s ! src/os_cpu/bsd_x86/vm/bsd_x86_64.s ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp ! src/os_cpu/bsd_zero/vm/vmStructs_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp ! src/os_cpu/linux_sparc/vm/linux_sparc.s ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/vmStructs_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/linux_x86/vm/linux_x86_64.s ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp ! src/os_cpu/linux_x86/vm/vmStructs_linux_x86.hpp ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/linux_zero/vm/vmStructs_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.il ! src/os_cpu/solaris_sparc/vm/solaris_sparc.s ! src/os_cpu/solaris_sparc/vm/vmStructs_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.s ! src/os_cpu/solaris_x86/vm/solaris_x86_64.s ! src/os_cpu/solaris_x86/vm/vmStructs_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp ! src/os_cpu/windows_x86/vm/vmStructs_windows_x86.hpp ! 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/tools/ProjectCreator/WinGammaPlatformVC7.java ! src/share/tools/hsdis/hsdis.c ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/dfa.cpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/macroAssembler.hpp ! src/share/vm/asm/macroAssembler.inline.hpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_Compiler.hpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_RangeCheckElimination.cpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/c1/c1_ValueMap.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/c1/c1_globals.cpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp ! src/share/vm/ci/ciArray.cpp ! src/share/vm/ci/ciArray.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciConstant.hpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciFlags.hpp ! src/share/vm/ci/ciInstance.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/ci/ciKlass.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObjArrayKlass.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciType.cpp ! src/share/vm/ci/ciType.hpp ! src/share/vm/ci/ciTypeArray.cpp ! src/share/vm/ci/ciTypeArrayKlass.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/ci/ciUtilities.hpp ! src/share/vm/classfile/bytecodeAssembler.cpp ! src/share/vm/classfile/classFileStream.cpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/classLoaderData.inline.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/code/compressedStream.cpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/icBuffer.hpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/abstractCompiler.cpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/compiler/compileLog.hpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! 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/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.hpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_implementation/shared/allocationStats.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/gcAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/shared/immutableSpace.cpp ! src/share/vm/gc_implementation/shared/isGCActiveMark.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/shared/spaceCounters.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/gc_interface/gcCause.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/cppInterpreter.hpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/freeList.hpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/genRemSet.cpp ! src/share/vm/memory/genRemSet.hpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/generationSpec.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/specialized_oop_closures.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/tenuredGeneration.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/oops/compiledICHolder.cpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/oops/instanceClassLoaderKlass.cpp ! src/share/vm/oops/instanceClassLoaderKlass.hpp ! src/share/vm/oops/instanceMirrorKlass.cpp ! src/share/vm/oops/instanceOop.hpp ! src/share/vm/oops/instanceRefKlass.hpp ! src/share/vm/oops/klassPS.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/objArrayKlass.inline.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp ! src/share/vm/oops/oop.psgc.inline.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.hpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/c2compiler.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/classes.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/coalesce.hpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/live.hpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/multnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/optoreg.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/regalloc.cpp ! src/share/vm/opto/regalloc.hpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/subnode.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiEnvThreadState.cpp ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp ! src/share/vm/prims/jvmtiTrace.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/perf.cpp ! src/share/vm/prims/wbtestmethods/parserTests.hpp ! src/share/vm/prims/whitebox.hpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/perfData.hpp ! src/share/vm/runtime/reflection.hpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/synchronizer.hpp ! src/share/vm/runtime/unhandledOops.hpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframe.hpp ! src/share/vm/runtime/vframeArray.hpp ! src/share/vm/runtime/virtualspace.hpp ! src/share/vm/runtime/vm_version.hpp ! src/share/vm/services/classLoadingService.hpp ! src/share/vm/services/dtraceAttacher.cpp ! src/share/vm/services/g1MemoryPool.hpp ! src/share/vm/services/memReporter.cpp ! src/share/vm/services/memReporter.hpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp ! src/share/vm/services/memoryUsage.hpp ! src/share/vm/services/psMemoryPool.hpp ! src/share/vm/services/threadService.hpp ! src/share/vm/shark/sharkBlock.cpp ! src/share/vm/shark/sharkBuilder.cpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkCompiler.hpp ! src/share/vm/shark/sharkConstant.cpp ! src/share/vm/shark/sharkFunction.cpp ! src/share/vm/shark/sharkInliner.cpp ! src/share/vm/shark/sharkInvariants.hpp ! src/share/vm/shark/sharkTopLevelBlock.cpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/bitMap.hpp ! src/share/vm/utilities/bitMap.inline.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/globalDefinitions.cpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/growableArray.hpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/numberSeq.cpp ! src/share/vm/utilities/ostream.hpp ! src/share/vm/utilities/top.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! test/Makefile ! test/TEST.ROOT ! test/compiler/5091921/Test7005594.sh ! test/compiler/6431242/Test.java ! test/compiler/6589834/Test_ia32.java ! test/compiler/6636138/Test1.java ! test/compiler/6636138/Test2.java ! test/compiler/6795161/Test.java ! test/compiler/6857159/Test6857159.sh ! test/compiler/7068051/Test7068051.sh ! test/compiler/7070134/Test7070134.sh ! test/compiler/7200264/Test7200264.sh ! test/compiler/8000805/Test8000805.java ! test/compiler/8005419/Test8005419.java ! test/gc/6941923/Test6941923.java ! test/gc/g1/TestHumongousAllocInitialMark.java ! test/runtime/6626217/Test6626217.sh ! test/runtime/7110720/Test7110720.sh ! test/runtime/7162488/Test7162488.sh ! test/runtime/RedefineObject/Agent.java ! test/runtime/RedefineObject/TestRedefineObject.java Changeset: a7e8ff4a1838 Author: twisti Date: 2014-01-06 15:35 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/a7e8ff4a1838 8031199: _MSC_VER is only defined on _WIN32 Reviewed-by: kvn, iveresov ! src/share/vm/adlc/adlc.hpp Changeset: 16e101c8691f Author: twisti Date: 2014-01-06 17:23 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/16e101c8691f 8029305: add type tag to AbstractCompiler Reviewed-by: iveresov, kvn ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_Compiler.hpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/opto/c2compiler.hpp ! src/share/vm/shark/sharkCompiler.cpp Changeset: 1891b98ded49 Author: roland Date: 2014-01-07 12:38 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1891b98ded49 8028536: Test cases to cover type system fixes pushed with 8024070 Summary: extra test cases for type speculation Reviewed-by: kvn ! test/compiler/types/TypeSpeculation.java Changeset: 1128e5fec05f Author: roland Date: 2014-01-07 14:36 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1128e5fec05f 8028064: tiered may collect wrong receiver type at virtual call Summary: when unique callee is known at compile time, recorded class may be wrong Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: e045e1876610 Author: roland Date: 2014-01-07 16:02 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e045e1876610 8027571: fatal error: meet not symmetric Summary: meet of one constant array and one exact array not symmetric. Reviewed-by: kvn ! src/share/vm/opto/type.cpp + test/compiler/types/TestMeetTopArrayExactConstantArray.java Changeset: d16be2b85802 Author: twisti Date: 2014-01-07 14:26 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/d16be2b85802 8022263: use same Clang warnings on BSD as on Linux Reviewed-by: kvn, iveresov ! make/bsd/makefiles/gcc.make ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/main.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/prims/forte.cpp Changeset: b9b6934ad75c Author: roland Date: 2014-01-08 09:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b9b6934ad75c 8029873: compiler/uncommontrap/TestStackBangRbp.java crashes with SIGSEGV Summary: May end up in uncommon trap blob/deopt blob with unguarded stack Reviewed-by: kvn, twisti ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/sharedRuntime.cpp + test/compiler/uncommontrap/StackOverflowGuardPagesOff.java Changeset: 303c352ba1a8 Author: adlertz Date: 2014-01-08 12:05 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/303c352ba1a8 8029446: assert(_cfg.get_block_for_node(proj) == borig) failed: incorrect block for kill projections Summary: Added loadConP0 projection node to block in case of re-materialization of the loadConP0. x86_64 only. Reviewed-by: kvn ! src/share/vm/opto/chaitin.cpp Changeset: 183bd5c00828 Author: kvn Date: 2014-01-08 10:25 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/183bd5c00828 8028468: Add inlining information into ciReplay Summary: Allow dump and replay inlining for specified method during a program execution. Reviewed-by: roland, twisti ! agent/src/share/classes/sun/jvm/hotspot/ci/ciEnv.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Compile.java ! agent/src/share/classes/sun/jvm/hotspot/opto/InlineTree.java ! agent/src/share/classes/sun/jvm/hotspot/opto/JVMState.java ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/ci/ciReplay.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 1f480770a1d4 Author: adlertz Date: 2014-01-09 10:47 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1f480770a1d4 8011391: C1: assert(code_offset() - offset == NativeInstruction::nop_instruction_size) failed: only one instruction can go in a delay slot Summary: Remove the VerifyOopMaps flag which doesn't work for tiered or for C1 with more compiler threads than one. Reviewed-by: twisti, drchase, iveresov ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_globals.hpp Changeset: 68343762fd63 Author: iignatyev Date: 2014-01-09 19:03 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/68343762fd63 8031115: intrinsics for Math.decrementExact(J) and incrementExact(J) don't work Reviewed-by: kvn, twisti ! src/share/vm/classfile/vmSymbols.hpp Changeset: 933c8a58c9dc Author: twisti Date: 2014-01-09 18:09 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/933c8a58c9dc 8026413: ScopeDesc::is_equal is declared in header file but not implemented Reviewed-by: kvn ! src/share/vm/code/scopeDesc.hpp Changeset: 7c0122ed05fb Author: anoll Date: 2014-01-10 06:36 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7c0122ed05fb 8022494: Make compilation IDs sequential Summary: Use atomic operations to provide sequential compilation IDs Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: db1ff6781ab4 Author: morris Date: 2014-01-10 12:54 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/db1ff6781ab4 Merge ! agent/src/os/linux/symtab.c ! make/windows/makefiles/sa.make ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp Changeset: d3a3fc905c7e Author: coleenp Date: 2013-09-05 10:29 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/d3a3fc905c7e 8021266: Better life cycle for objects Summary: Improve life cycle for objects Reviewed-by: art, hseigel Contributed-by: gerard.ziemski at oracle.com ! src/share/vm/runtime/os.cpp Changeset: c4b78cbea876 Author: jrose Date: 2013-12-05 00:36 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/c4b78cbea876 8029507: Enhance JVM method processing Summary: update MemberName.clazz correctly in MemberName.resolve; also pass lookupClass to MethodHandles::resolve_MemberName Reviewed-by: acorn, vlivanov ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: e8d4d0db1f06 Author: henryjen Date: 2014-01-21 20:07 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e8d4d0db1f06 8028407: adjust-mflags.sh failed build with GNU Make 4.0 with -I Reviewed-by: erikj ! make/bsd/makefiles/adjust-mflags.sh ! make/linux/makefiles/adjust-mflags.sh ! make/solaris/makefiles/adjust-mflags.sh Changeset: 715bc50198c1 Author: sla Date: 2014-01-08 08:34 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/715bc50198c1 8031376: TraceClassLoading expects there to be a (Java) caller when you load a class with the bootstrap class loader Reviewed-by: sla, dholmes Contributed-by: jeremymanson at google.com ! src/share/vm/classfile/classFileParser.cpp Changeset: 6ffbf4c1c98c Author: sla Date: 2014-01-08 13:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6ffbf4c1c98c 8030184: Remove unneeded "content_type" declarations from tracetypes.xml Reviewed-by: dholmes, jbachorik, egahlin, mgronlun ! src/share/vm/trace/tracetypes.xml Changeset: 2cfad8cc3bab Author: zgu Date: 2014-01-09 14:06 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/2cfad8cc3bab 7012961: runtime/jni/WindowsExceptionFilter/WindowsExceptionFilter01 crashes on windows-amd64 Summary: VM needs to handle EXCEPTION_FLT_* exceptions on Win64 Reviewed-by: coleenp, ccheung ! src/os/windows/vm/os_windows.cpp Changeset: d85f79f0c476 Author: ccheung Date: 2014-01-09 15:48 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/d85f79f0c476 8022301: [TESTBUG] runtime/jsig/Test8017498.sh incorrectly compiles native code Summary: added the '-m32' compile option and the '-z noexecstack' link option Reviewed-by: mseledtsov, zgu ! test/runtime/jsig/Test8017498.sh Changeset: 768421ed8211 Author: hseigel Date: 2014-01-13 18:30 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/768421ed8211 Merge Changeset: afa21611f918 Author: farvidsson Date: 2014-01-14 15:27 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/afa21611f918 8031304: Add dcmd to print all loaded dynamic libraries. Summary: Adding VM.dynlibs as a dcmd to dump all loaded dynamic libraries. Reviewed-by: sla, fparain, mgronlun, dsamersoff ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! test/TEST.groups + test/serviceability/dcmd/DcmdUtil.java + test/serviceability/dcmd/DynLibDcmdTest.java Changeset: 2e96b2d61686 Author: zgu Date: 2014-01-13 10:05 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/2e96b2d61686 8031530: [TESTBUG] Enable test runtime/LoadClass/LoadClassNegative.java Summary: Re-enabled the test. The issue that prevents this test from running was fixed by 8020675 Reviewed-by: sla, ccheung ! test/runtime/LoadClass/LoadClassNegative.java Changeset: 8bca494530d3 Author: hseigel Date: 2014-01-14 13:51 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/8bca494530d3 8028398: [TESTBUG]: test/runtime/memory/ReadFromNoaccessArea.java failed with EXCEPTION_ACCESS_VIOLATION Summary: Remove ignore label Reviewed-by: sla, mseledtsov Contributed-by: george.triantafillou at oracle.com ! test/runtime/memory/ReadFromNoaccessArea.java Changeset: 78468e5dc6fc Author: hseigel Date: 2014-01-14 16:27 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/78468e5dc6fc 8031059: invokestatic: ICCE trying to invoke static method when it clashes with an abstract method inherited from an interface Summary: Do not create AME overpass if there is a matching static method Reviewed-by: lfoltan, coleenp, kamg ! src/share/vm/classfile/defaultMethods.cpp Changeset: 19682558f2e1 Author: dsamersoff Date: 2014-01-15 02:02 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/19682558f2e1 8030941: Darwin mapfile-vers doesnt work for other BSDs Summary: Changed makefile to use generic mapfile for non Darwin BSDs Reviewed-by: dholmes, sla ! make/bsd/makefiles/debug.make ! make/bsd/makefiles/fastdebug.make + make/bsd/makefiles/mapfile-vers-darwin-debug + make/bsd/makefiles/mapfile-vers-darwin-product ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/bsd/makefiles/optimized.make ! make/bsd/makefiles/product.make Changeset: b3a9c629e2d5 Author: dsamersoff Date: 2014-01-14 22:13 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/b3a9c629e2d5 Merge Changeset: fbc1677398c0 Author: pliden Date: 2014-01-10 09:53 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/fbc1677398c0 8029255: G1: Reference processing should not enqueue references on the shared SATB queue Reviewed-by: brutisso, tschatzl ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp Changeset: 89ac31a5a7a7 Author: pliden Date: 2014-01-10 09:54 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/89ac31a5a7a7 8029162: G1: Shared SATB queue never enabled Reviewed-by: brutisso, mgerdin, tschatzl ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp Changeset: 42fcf9b2120e Author: ehelin Date: 2014-01-14 14:26 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/42fcf9b2120e Merge Changeset: e4e941b83466 Author: ehelin Date: 2014-01-16 17:22 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e4e941b83466 8031779: Assert in MetaspaceGC is always true Reviewed-by: jmasa, jwilhelm ! src/share/vm/memory/metaspace.cpp Changeset: 99331f31a971 Author: ehelin Date: 2014-01-17 09:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/99331f31a971 Merge Changeset: f7eeaff95a25 Author: roland Date: 2014-01-13 16:16 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/f7eeaff95a25 8029464: assert(ft == ttkp->cast_to_ptr_type(jtkp->ptr()) || ft->isa_narrowoop() Summary: Fix the assert check for narrow klass pointer. Reviewed-by: twisti, kvn ! src/share/vm/opto/cfgnode.cpp Changeset: 9bcf7b329013 Author: roland Date: 2014-01-14 09:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9bcf7b329013 8028764: dtrace/hotspot_jni/ALL/ALL001 crashes the vm on Solaris-amd64, SIGSEGV in MarkSweep::follow_stack()+0x8a Summary: C1 generates code to encode compressed oop into tmp register before runtime call for patching where GC may happen Reviewed-by: iveresov, twisti, kvn Contributed-by: mgerdin ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: ee5727365ce5 Author: roland Date: 2014-01-14 12:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ee5727365ce5 8030662: "assert(counter_changed) failed: failed dependencies, but counter didn't change" still fails Summary: Erroneously removed call to SystemDictionary::notice_modification() from jvmti with fix for 8029383 Reviewed-by: iveresov, twisti, kvn ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 8cdf3f43f63e Author: roland Date: 2014-01-14 14:51 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8cdf3f43f63e 8026253: New type profiling points: sparc support Summary: c1 and interpreter support for new type profiling on sparc Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 00f5eff62d18 Author: kvn Date: 2014-01-14 17:46 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/00f5eff62d18 8002074: Support for AES on SPARC Summary: Add intrinsics/stub routines support for single-block and multi-block (as used by Cipher Block Chaining mode) AES encryption and decryption operations on the SPARC platform. Reviewed-by: kvn, roland Contributed-by: shrinivas.joshi at oracle.com ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/x86.ad ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/runtime.cpp ! test/compiler/7184394/TestAESMain.java Changeset: 3aaa4b9966f6 Author: anoll Date: 2014-01-15 06:16 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3aaa4b9966f6 7194669: CodeCache::mark_for_deoptimization should avoid verifying dependencies multiple times Summary: Avoid verifying dependencies multiple times by caching verified dependencies Reviewed-by: kvn, twisti, roland ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/dependencies.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp Changeset: 30f8cd8b43dd Author: anoll Date: 2014-01-14 21:33 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/30f8cd8b43dd Merge Changeset: 4d7678fb8a27 Author: twisti Date: 2014-01-16 16:18 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/4d7678fb8a27 8022395: java.util.zip.ZipException: Not in GZIP format in JT_JDK/test/java/util/zip/GZIP tests Reviewed-by: kvn, iveresov ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Changeset: 3e2b76368121 Author: morris Date: 2014-01-17 10:43 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/3e2b76368121 Merge ! src/share/vm/code/dependencies.cpp Changeset: 6fe23366ce0b Author: amurillo Date: 2014-01-23 10:35 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/6fe23366ce0b Merge Changeset: 239f9b9c86e3 Author: katleman Date: 2014-01-21 18:16 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/239f9b9c86e3 Added tag jdk9-b01 for changeset 050a626a8895 ! .hgtags Changeset: b188446de75b Author: lana Date: 2014-01-27 21:00 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/b188446de75b Merge Changeset: 2a8891e0a082 Author: lana Date: 2014-01-28 11:21 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/2a8891e0a082 Merge Changeset: 9918c6fb4770 Author: iveresov Date: 2014-01-17 18:09 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/9918c6fb4770 8032207: C2: assert(VerifyOops || MachNode::size(ra_) <= (3+1)*4) failed: bad fixed size Summary: Fix the sizing of loadUS2L_immI16 and loadI2L_immI Reviewed-by: kvn, azeemj ! src/cpu/sparc/vm/sparc.ad + test/compiler/codegen/LoadWithMask.java Changeset: 7e8bd81ce93e Author: iveresov Date: 2014-01-21 20:05 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/7e8bd81ce93e 8031743: C2: loadI2L_immI broken for negative memory values Summary: Restrict loadI2L_imm optimizations to positive values of mask Reviewed-by: kvn, dlong ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad + test/compiler/codegen/LoadWithMask2.java Changeset: 757ec609d8d5 Author: vlivanov Date: 2014-01-23 01:23 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/757ec609d8d5 8031695: CHA ignores default methods during analysis leading to incorrect code generation Reviewed-by: jrose, acorn, hseigel, lfoltan ! src/share/vm/code/dependencies.cpp + test/compiler/inlining/DefaultAndConcreteMethodsCHA.java Changeset: cb0dc98c287d Author: kvn Date: 2014-01-24 09:04 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/cb0dc98c287d Merge ! src/share/vm/code/dependencies.cpp Changeset: e0035752234f Author: dsimms Date: 2014-01-15 11:46 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e0035752234f 6945460: [TESTBUG] runtime/6929067/Test6929067.sh Summary: Change link order for the test Reviewed-by: coleenp, mgerdin ! test/runtime/6929067/Test6929067.sh Changeset: efc27a069897 Author: mseledtsov Date: 2014-01-15 19:12 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/efc27a069897 8031151: Add basic CDS tests Summary: Added new tests to cover missing CDS basic funtions Reviewed-by: zgu, hseigel + test/runtime/SharedArchiveFile/ArchiveDoesNotExist.java + test/runtime/SharedArchiveFile/CdsWriteError.java + test/runtime/SharedArchiveFile/DefaultUseWithClient.java Changeset: 234d576115b5 Author: ccheung Date: 2014-01-16 10:51 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/234d576115b5 8027314: Java should recognize Diagnostic options if -XX:+UnlockDiagnosticVMOptions is not specified and print an informative message Summary: clarifying the error messages associated with vm options of type diagnostic, experimental, develop, and notproduct Reviewed-by: kvn, twisti, ctornqvi ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! test/runtime/CommandLine/CompilerConfigFileWarning.java ! test/runtime/CommandLine/ConfigFileWarning.java + test/runtime/CommandLine/VMOptionWarning.java Changeset: 3bee68af0296 Author: sspitsyn Date: 2014-01-17 02:13 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/3bee68af0296 8030027: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Linux-amd64: SIGSEGV in JavaThread::last_java_vframe(RegisterMap*)+0xfa Summary: Add a safe guard to VMOp_GetCurrentLocation against non-walkable stack of target thread exiting from Java execution Reviewed-by: mgronlun, dholmes, sla, dcubed Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiEnvThreadState.cpp Changeset: a3ba776d6ab6 Author: sla Date: 2014-01-16 20:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a3ba776d6ab6 8030812: Change the solaris DTrace implementation to use USDT2 instead of USDT1 Reviewed-by: coleenp, sspitsyn, dsamersoff ! make/bsd/makefiles/dtrace.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/top.make ! src/os/bsd/dtrace/hotspot.d ! src/os/solaris/dtrace/hotspot.d ! src/os/solaris/dtrace/hotspot_jni.d ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/utilities/dtrace.hpp Changeset: 7e072af80503 Author: hseigel Date: 2014-01-17 09:39 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/7e072af80503 8031045: Access checks should precede additional per-instruction checks Summary: Move access check above the check for non-static method Reviewed-by: lfoltan, coleenp ! src/share/vm/interpreter/linkResolver.cpp Changeset: d471b8a6765c Author: hseigel Date: 2014-01-17 09:47 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/d471b8a6765c Merge Changeset: 00c48a8ca160 Author: coleenp Date: 2014-01-17 11:21 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/00c48a8ca160 8032024: Test not added for bug 8025937: assert(existing_f1 == NULL || existing_f1 == f1) failed: illegal field,change Summary: Test didn't get hg added with original bug fix Reviewed-by: jrose, hseigel, lfoltan + test/runtime/lambda-features/InvokespecialInterface.java Changeset: 8254553994b9 Author: hseigel Date: 2014-01-19 20:23 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/8254553994b9 Merge ! src/share/vm/runtime/arguments.cpp Changeset: baa7d4400c62 Author: kevinw Date: 2014-01-17 18:39 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/baa7d4400c62 8028623: SA: hash codes in SymbolTable mismatching java_lang_String::hash_code for extended characters. Reviewed-by: sla, dsamersoff ! agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java + test/serviceability/sa/jmap-hashcode/Test8028623.java Changeset: ce3b1e29425a Author: kevinw Date: 2014-01-20 09:56 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/ce3b1e29425a Merge Changeset: 20e2bd0e84bf Author: sla Date: 2014-01-23 08:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/20e2bd0e84bf 8032250: Add trace event for VM flag changes Reviewed-by: coleenp, ehelin, egahlin, mgronlun ! src/share/vm/runtime/globals.cpp ! src/share/vm/trace/trace.xml ! src/share/vm/trace/tracetypes.xml Changeset: c250880a6673 Author: sla Date: 2014-01-23 09:06 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c250880a6673 8031968: Mac OS X: VM starts the agent by calling both Agent_OnAttach and Agent_OnAttach_L functions if its agent library is dynamically linked. Summary: Make sure we only look for statically linked agents in the main process image Reviewed-by: dsamersoff, bpittore, dcubed ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/vm/os_solaris.cpp Changeset: 0129aea3736a Author: kevinw Date: 2014-01-23 09:33 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/0129aea3736a 8032466: serviceability/sa/jmap-hashcode/Test8028623.java fails with compilation errors Reviewed-by: dsamersoff, sla ! test/serviceability/sa/jmap-hashcode/Test8028623.java Changeset: ab67ce0bfae2 Author: minqi Date: 2014-01-23 09:40 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/ab67ce0bfae2 6651256: jstack: DeleteGlobalRef method call doesn't lead to descreasing of global refs count shown by jstack Summary: jni_DeleteGlobalRef does not really release the jni handle, instead, set the handle point to JNIHandles::_deleted_handle which holds an oop instance (java/lang/Object) in Java heap and never be GC'ed. When counting number of global reference, it counts all the handles on the chain list, which includes the already deleted ones. Reviewed-by: zgu, sla, coleenp Contributed-by: yumin.qi at oracle.com ! src/share/vm/runtime/jniHandles.cpp Changeset: 7444c21b8b71 Author: minqi Date: 2014-01-23 09:45 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/7444c21b8b71 Merge Changeset: d050fbf914d8 Author: gdub Date: 2014-01-23 16:02 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/d050fbf914d8 8031427: AllocObject and Unsafe.allocateInstance segfault for primitive types Summary: The fix just throws an InstantiationException if the Klass is NULL. Reviewed-by: coleenp, twisti, jrose Contributed-by: gdub ! src/share/vm/prims/jni.cpp Changeset: 5944dba4badc Author: dsimms Date: 2014-01-24 09:28 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5944dba4badc 8028280: ParkEvent leak when running modified runThese which only loads classes Summary: Use spin lock to manage ParkEvent and PlatformEvent free lists. Reviewed-by: dholmes, fparain ! 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/runtime/os.hpp ! src/share/vm/runtime/park.cpp ! src/share/vm/runtime/thread.cpp Changeset: 2e7b5143763f Author: hseigel Date: 2014-01-24 08:13 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/2e7b5143763f 8028553: The JVM should not throw VerifyError when 'overriding' a static final method in a superclass. Summary: Check if method is static before throwing exception. Reviewed-by: kamg, coleenp, lfoltan, fparain ! src/share/vm/classfile/classFileParser.cpp + test/runtime/finalStatic/FinalStatic.java Changeset: 7327ec5e661e Author: hseigel Date: 2014-01-24 08:31 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/7327ec5e661e Merge Changeset: b8a500a7b9bf Author: dsamersoff Date: 2014-01-27 13:46 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/b8a500a7b9bf 8032247: SA: Constantpool lookup for invokedynamic is not implemented Summary: implement constant pool lookup for invokedynamic Reviewed-by: sla, sspitsyn ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java Changeset: 4c241e42a3e4 Author: sla Date: 2014-01-27 10:57 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4c241e42a3e4 8032662: test/compiler/ciReplay/TestSA.sh should report ulimit issues Reviewed-by: kvn, iignatyev Contributed-by: stefan.sarne at oracle.com ! test/compiler/ciReplay/common.sh Changeset: 50bb249de889 Author: gziemski Date: 2014-01-21 16:45 -0600 URL: http://hg.openjdk.java.net/graal/graal/rev/50bb249de889 7015395: [TESTBUG] runtime/6626217/Test6626217.sh fails if compilation happens fast enough for timestamps to be equal. Summary: Insert 2 second sleep between copying of the src files and the compilation, to make sure the timestamps of *.class files are in the future of *.java files. Reviewed-by: coleenp, fparain ! test/runtime/6626217/Test6626217.sh Changeset: febc6428bc79 Author: coleenp Date: 2014-01-27 23:12 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/febc6428bc79 8028275: Metaspace ShrinkGrowTest causes fatal error if run with JFR Summary: Clean up initialization from Threads::create_vm() so that exceptions cause vm_exit_during_initialzation without an exception mark. Reviewed-by: dholmes, hseigel ! src/share/vm/oops/constantPool.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/utilities/exceptions.hpp Changeset: 4fe850c65ed1 Author: dsamersoff Date: 2014-01-28 14:45 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/4fe850c65ed1 7010732: SA_ALTROOT only works if running the SA tools from their build directory. Summary: fixed SA packaging scripts Reviewed-by: sla, kevinw ! agent/make/mkinstall ! agent/make/saenv.sh ! agent/make/saenv64.sh Changeset: dbcbdca5dc04 Author: dsamersoff Date: 2014-01-28 11:42 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/dbcbdca5dc04 Merge Changeset: d5b8799dfbd7 Author: zgu Date: 2014-01-28 08:55 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/d5b8799dfbd7 8032827: NMT: missing virtual memory tagging in os::workaround_expand_exec_shield_cs_limit() Summary: Fixed missing virtual memory type tagging in os::workaround_expand_exec_shield_cs_limit() function Reviewed-by: hseigel, coleenp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp Changeset: ceddae1a16c9 Author: zgu Date: 2014-01-28 06:26 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/ceddae1a16c9 Merge Changeset: 1fb56cbac3a1 Author: hseigel Date: 2014-01-29 19:54 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/1fb56cbac3a1 Merge Changeset: 893ce66f7473 Author: tschatzl Date: 2014-01-20 11:47 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/893ce66f7473 8027476: Improve performance of Stringtable unlink 8027455: Improve symbol table scan times during gc pauses Summary: Parallelize string table and symbol table scan during remark and full GC. Some additional statistics output if the experimental flag G1TraceStringSymbolTableScrubbing is set. Reviewed-by: mgerdin, coleenp, brutisso ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! 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/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp + test/gc/g1/TestStringSymbolTableStats.java Changeset: a2866d45e99e Author: tschatzl Date: 2014-01-20 11:47 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a2866d45e99e 8027454: Do not traverse string table during G1 remark when treating them as strong roots during initial mark Summary: Do not try to unlink string table entries unconditionally during remark. This is without side effects as the preceding initial mark always uses the string table as strong roots. Needs to be fixed with class unloading during concurrent mark. Reviewed-by: brutisso, mgerdin ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: c685ef164975 Author: tschatzl Date: 2014-01-20 11:47 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c685ef164975 8027746: Remove do_gen_barrier template parameter in G1ParCopyClosure Summary: Remove the above mentioned template parameter and related unused code. Also remove some classes that are never used. Reviewed-by: stefank, mgerdin, jwilhelm ! src/share/vm/gc_implementation/g1/bufferingOopClosure.hpp ! 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/g1_specialized_oop_closures.hpp Changeset: 284953caf7aa Author: ehelin Date: 2014-01-20 17:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/284953caf7aa 8031776: Remove the unnecessary enum GenRemSet::Name Reviewed-by: stefank, tschatzl, jwilhelm ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genOopClosures.inline.hpp ! src/share/vm/memory/genRemSet.cpp ! src/share/vm/memory/genRemSet.hpp Changeset: 7ab52431bc9f Author: sjohanss Date: 2014-01-20 12:56 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7ab52431bc9f 8020277: Young GC could be extremely slow due to assertion in ObjectStartArray::object_starts_in_range 8009462: Young GC's (ParNewGC and SerialGC) have unexpected variances. Summary: Removed the assertion slowing down GC. Reviewed-by: stefank, mgerdin ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.cpp Changeset: 870aedf4ba4f Author: mgerdin Date: 2014-01-14 16:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/870aedf4ba4f 8032379: Remove the is_scavenging flag to process_strong_roots Summary: Refactor the strong root processing to avoid using a boolean in addition to the ScanOption enum. Reviewed-by: stefank, tschatzl, ehelin, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! 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/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp Changeset: 63a4eb8bcd23 Author: jwilhelm Date: 2014-01-23 14:47 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/63a4eb8bcd23 8025856: Fix typos in the GC code Summary: Fix about 440 typos in comments in the VM code Reviewed-by: mgerdin, tschatzl, coleenp, kmo, jcoomes ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsGCAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.inline.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp ! src/share/vm/gc_implementation/g1/bufferingOopClosure.hpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1AllocRegion.inline.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.hpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psGCAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/gcUtil.cpp ! src/share/vm/gc_implementation/shared/gcUtil.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.hpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/shared/spaceDecorator.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_interface/gcCause.hpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/blockOffsetTable.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genRemSet.hpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/modRefBarrierSet.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/advancedThresholdPolicy.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/deoptimization.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/jniHandles.hpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/mutex.hpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/orderAccess.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/park.cpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/perfData.hpp ! src/share/vm/runtime/perfMemory.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp ! src/share/vm/runtime/registerMap.hpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/sharedRuntimeTrans.cpp ! src/share/vm/runtime/sharedRuntimeTrig.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/statSampler.cpp ! src/share/vm/runtime/stubCodeGenerator.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/synchronizer.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/unhandledOops.hpp ! src/share/vm/runtime/vframeArray.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 1e1c8d358b52 Author: brutisso Date: 2014-01-27 13:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1e1c8d358b52 8030177: G1: Enable TLAB resizing Reviewed-by: tschatzl, stefank, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.hpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/memory/universe.cpp Changeset: e9fc29d2e8ae Author: sjohanss Date: 2014-01-20 10:55 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e9fc29d2e8ae 8031686: G1: assert(_hrs.max_length() == _expansion_regions) failed Summary: Using pointer_delta to avoid overflowing pointer calculation. Reviewed-by: jmasa, tschatzl ! src/share/vm/gc_implementation/g1/g1BiasedArray.hpp + test/gc/g1/Test2GbHeap.java Changeset: 73b1030c6253 Author: jmasa Date: 2014-01-15 07:20 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/73b1030c6253 8031290: Adjust call to getisax() for additional words returned Reviewed-by: kvn, iveresov, twisti ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp Changeset: 44315152d434 Author: jwilhelm Date: 2014-01-29 23:17 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/44315152d434 8028391: Make the Min/MaxHeapFreeRatio flags manageable Summary: Made the flags Min- and MaxHeapFreeRatio manageable, and implemented support for these flags in ParallalGC. Reviewed-by: sla, mgerdin, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/management.cpp Changeset: 2c95095271e9 Author: ehelin Date: 2014-01-30 14:01 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2c95095271e9 Merge ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/park.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: ad29d183df7c Author: amurillo Date: 2014-02-05 08:57 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/ad29d183df7c Merge Changeset: c888354aaa35 Author: jbachorik Date: 2014-01-30 09:41 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c888354aaa35 6656031: SA: jmap -permstat number of classes is off by 1 Reviewed-by: sla, dholmes ! agent/src/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java Changeset: b59507f713e0 Author: rdurbin Date: 2014-01-30 14:12 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/b59507f713e0 8027113: decouple the '-XXaltjvm=' option from the gamma launcher Summary: decoupled the '-XXaltjvm=' option from the gamma launcher. Clearing the way for removing the remaining cruft associated with the previously removed gamma launcher. Reviewed-by: dcubed, dholmes ! make/Makefile ! make/hotspot.script ! 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/tools/ProjectCreator/WinGammaPlatformVC10.java ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 1020b892787b Author: hseigel Date: 2014-02-02 15:31 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/1020b892787b Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: a00b8f42c4c4 Author: sla Date: 2014-02-03 13:41 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a00b8f42c4c4 8032462: Change the linux SDT implementation to use USDT2 instead of USDT1 Reviewed-by: coleenp, sspitsyn, kamg ! make/bsd/makefiles/dtrace.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/dtrace.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/dtrace.make - src/os/bsd/dtrace/hotspot.d - src/os/bsd/dtrace/hotspot_jni.d - src/os/bsd/dtrace/hs_private.d + src/os/posix/dtrace/hotspot.d + src/os/posix/dtrace/hotspot_jni.d + src/os/posix/dtrace/hs_private.d - src/os/solaris/dtrace/hotspot.d - src/os/solaris/dtrace/hotspot_jni.d - src/os/solaris/dtrace/hs_private.d ! src/share/vm/utilities/dtrace.hpp Changeset: 602e80a36dfb Author: sla Date: 2014-02-03 15:24 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/602e80a36dfb 8033126: Can't call default methods from JNI Reviewed-by: dholmes, acorn, kamg ! src/share/vm/prims/jni.cpp Changeset: e4062d6c5f22 Author: sspitsyn Date: 2014-02-04 19:41 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e4062d6c5f22 8032223: nsk/regression/b4663146 gets assert(SafepointSynchronize::is_at_safepoint() || JvmtiEnv::is_thread_fully_suspended(get_thread(), false, &debug_bits)) Summary: It is better to calculate frame count for suspended threads at a safepoint Reviewed-by: twisti, dsamersoff, sla, dholmes, dcubed Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp Changeset: f3959a2e0eee Author: ccheung Date: 2014-02-05 15:14 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/f3959a2e0eee 8032010: Attempt to resolve abstract method in concrete class fails with AbstractMethodError Summary: removing a check in LinkResolver::resolve_method() to conform with a change in JVMS-8 5.4.3.3. Method Resolution Reviewed-by: coleenp, lfoltan ! src/share/vm/interpreter/linkResolver.cpp + test/runtime/lambda-features/TestConcreteClassWithAbstractMethod.java Changeset: d2954f85a366 Author: amurillo Date: 2014-02-07 09:41 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/d2954f85a366 Merge - src/os/bsd/dtrace/hotspot.d - src/os/bsd/dtrace/hotspot_jni.d - src/os/bsd/dtrace/hs_private.d - src/os/solaris/dtrace/hotspot.d - src/os/solaris/dtrace/hotspot_jni.d - src/os/solaris/dtrace/hs_private.d Changeset: c86519f8d826 Author: henryjen Date: 2014-02-05 21:24 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/c86519f8d826 8033289: clang: clean up unused function warning Reviewed-by: coleenp, dholmes, mgerdin ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/runtime/mutex.cpp Changeset: 4f0acb75c921 Author: coleenp Date: 2014-02-06 18:57 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/4f0acb75c921 8028735: runtime/RedefineObject/TestRedefineObject.java interrupted (timed out?) on solaris_sparcv9-fastdebug-c2-runtime and solaris_x64-debugOpen-c2-runtime Summary: Change GC loop counter to 100 which is enough to test the original problem but doesn't timeout the test. Reviewed-by: ctornqvi, lfoltan, mseledtsov, sla ! test/runtime/RedefineObject/Agent.java Changeset: e7d8cbe4db3b Author: fparain Date: 2014-02-06 17:59 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/e7d8cbe4db3b 8030808: dtrace/hotspot/Monitors/Monitors001 fails in product builds on solaris-sparc Reviewed-by: sspitsyn, dcubed, kamg, dholmes ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/synchronizer.hpp Changeset: c09d6af75fd9 Author: fparain Date: 2014-02-06 14:51 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/c09d6af75fd9 Merge Changeset: 2c2a99f6cf83 Author: coleenp Date: 2014-02-06 14:28 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/2c2a99f6cf83 8029775: Solaris code cleanup 8033464: Linux code cleanup Summary: cleaned up warnings in solaris and linux specific os code. Reviewed-by: coleenp, fparain, dcubed Contributed-by: gerald.thornbrugh at oracle.com ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp Changeset: 260ff1b76790 Author: coleenp Date: 2014-02-06 20:32 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/260ff1b76790 Merge Changeset: 9341a9963d36 Author: sspitsyn Date: 2014-02-06 20:13 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/9341a9963d36 8025841: JVMTI: "vtable stub" dynamic code notification is misplaced Summary: Generate correct "vtable stub" dynamic code notifications Reviewed-by: sspitsyn, kvn, coleenp Contributed-by: oleg.mazurov at oracle.com ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp Changeset: 67d6392ed21e Author: dcubed Date: 2014-02-07 09:03 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/67d6392ed21e 8033714: hotspot 'install_jvm' bld target broken with ZIP_DEBUGINFO_FILES=0 Summary: fixed faulty logic in makefiles when compressed FDS builds are disabled Reviewed-by: rdurbin, dholmes, never, dnsimon, tbell ! make/bsd/makefiles/jsig.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/vm.make Changeset: c2626e4f0c80 Author: dcubed Date: 2014-02-07 11:47 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/c2626e4f0c80 8033931: Several nightly tests failing with assert(imin < imax) failed: Unexpected page size Summary: Loosen new assert() in get_stack_commited_bottom() Reviewed-by: dcubed, coleenp, dsamersoff, hseigel Contributed-by: gerald.thornbrugh at oracle.com ! src/os/linux/vm/os_linux.cpp Changeset: 26c3b944dc35 Author: coleenp Date: 2014-02-07 18:30 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/26c3b944dc35 8033528: assert(0 <= i && i < length()) failed: index out of bounds Summary: Restoring bytecodes for invokedynamic had wrong index calculation added testing stress option. Reviewed-by: twisti, hseigel ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/array.hpp ! test/runtime/lambda-features/InvokespecialInterface.java Changeset: 0e5d1eefe3af Author: hseigel Date: 2014-02-09 13:28 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/0e5d1eefe3af Merge Changeset: 4802ce6fbff6 Author: ctornqvi Date: 2014-02-10 17:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4802ce6fbff6 8016644: Improve UnsupportedClassVersionError message Summary: Improved the UnsupportedClassVersionError message to hopefully be more user friendly Reviewed-by: coleenp, dholmes, twisti ! src/share/vm/classfile/classFileParser.cpp + test/runtime/ClassFile/UnsupportedClassFileVersion.java ! test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java Changeset: c025990068c4 Author: dcubed Date: 2014-02-10 12:48 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/c025990068c4 8028073: race condition in ObjectMonitor implementation causing deadlocks Summary: Move redo of ParkEvent.unpark() after JVMTI_EVENT_MONITOR_WAITED event handler is called. Reviewed-by: dholmes, sspitsyn, dice, acorn ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/objectMonitor.cpp Changeset: 5eee9a9aeb7a Author: rdurbin Date: 2014-02-10 12:38 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/5eee9a9aeb7a 8005262: possible gamma launcher issues Summary: Cleaned out make targets and comments associated with the previously removed gamma launcher Reviewed-by: dcubed, stefank ! make/bsd/makefiles/optimized.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/top.make ! make/linux/makefiles/optimized.make ! make/linux/makefiles/product.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/top.make Changeset: 7865629d6f22 Author: dcubed Date: 2014-02-10 12:58 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/7865629d6f22 Merge Changeset: 9bfa5faf122e Author: dcubed Date: 2014-02-10 14:07 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/9bfa5faf122e Merge Changeset: cd6b3f1a94ff Author: minqi Date: 2014-02-10 21:29 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/cd6b3f1a94ff 8033792: AltHashing used jint for imprecise bit shifting Summary: AltHashing used jint the way of juint in bit shifting which could lead loss of precision. Fix by change _seed defined as juint. Reviewed-by: coleenp, ccheung Contributed-by: yumin.qi at oracle.com ! src/share/vm/classfile/altHashing.cpp ! src/share/vm/classfile/altHashing.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/metadata.hpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: ad3f8397fe37 Author: iklam Date: 2014-02-11 08:43 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/ad3f8397fe37 7182040: volano29 limited by os resource on Linux - need better diagnostic message Summary: Changed message to "unable to create native thread: possibly out of memory or process/resource limits reached" Reviewed-by: dholmes, sla ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/serviceThread.cpp ! src/share/vm/services/attachListener.cpp Changeset: 78fde43dc07d Author: iklam Date: 2014-02-11 10:05 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/78fde43dc07d Merge ! src/share/vm/prims/jvm.cpp Changeset: 05ede1d98e1e Author: tschatzl Date: 2014-01-31 09:55 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/05ede1d98e1e 8032771: The flag VerifySilently misses a test case Summary: Add test case for the VerifySilently flag. Reviewed-by: brutisso + test/gc/TestVerifySilently.java Changeset: bec0ef450ead Author: tschatzl Date: 2014-01-31 09:57 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bec0ef450ead 6991197: G1: specialize deal_with_reference() for narrowOop* Summary: Clean up and slightly optimize reference handling from the GC reference task queue. Since we never push partial array chunks as narrowOop* we can manually specialize the code so that some code can be optimized away. Reviewed-by: tonyp, brutisso, stefank ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp Changeset: 2edf6f3e191d Author: tschatzl Date: 2014-01-31 09:58 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2edf6f3e191d 8033106: Wrong predicate for checking whether the correct amount of symbol table entries have been processed in G1 Summary: The change fixes the predicate check. Reviewed-by: jmasa, tonyp, stefank ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 8a3eb09ed131 Author: jmasa Date: 2014-01-16 13:25 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/8a3eb09ed131 8024366: Make UseNUMA enable UseNUMAInterleaving Reviewed-by: brutisso, tschatzl Contributed-by: shrinivas.joshi at oracle.com ! src/share/vm/runtime/arguments.cpp Changeset: 47ee29d0e3f7 Author: ehelin Date: 2014-02-03 10:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/47ee29d0e3f7 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 6827d470020d Author: ehelin Date: 2014-02-05 10:09 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6827d470020d 8028254: gc/arguments/TestMinInitialErgonomics.java failed with unexpected initial heap size Reviewed-by: brutisso, tschatzl, sjohanss ! src/share/vm/prims/whitebox.cpp ! test/gc/arguments/TestMaxHeapSizeTools.java Changeset: 06dfb0e4dcb8 Author: tonyp Date: 2014-02-05 12:47 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/06dfb0e4dcb8 8033601: G1: Make array chunking use the same length field as the other young GCs Summary: Use the old copy length instead of the length of the forwarded object for chunked arrays. Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 990d7aa2f325 Author: tschatzl Date: 2014-02-05 14:29 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/990d7aa2f325 8033443: Test8000311 fails after latest changes to parallelize string and symbol table unlink Summary: When string and symbol table unlink are not performed in parallel, the claim index we check is not updated, and so a guarantee fails. Take this into account when checking the guarantee. Reviewed-by: brutisso, jwilhelm ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 2cff20331ca2 Author: pliden Date: 2014-02-06 14:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2cff20331ca2 8031703: Missing post-barrier in ReferenceProcessor Reviewed-by: tonyp, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp Changeset: 3dc1055f4e87 Author: tschatzl Date: 2014-02-06 17:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3dc1055f4e87 8033545: Missing volatile specifier in Bitmap::par_put_range_within_word Summary: The method Bitmap::par_put_range_within_word reloads the original value during a CAS, which may be optimized away. Instead of reloading, use the value returned by Atomic::cmpxchg_ptr() for further processing. Reviewed-by: tschatzl, brutisso, tonyp Contributed-by: Matthias Braun ! src/share/vm/utilities/bitMap.cpp Changeset: 7c41aaa3929b Author: brutisso Date: 2014-02-07 13:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7c41aaa3929b 8033922: G1: Back out 8033601 and go back to use the to-obj for chunked arrays. Reviewed-by: stefank, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 5e1086b5b726 Author: ehelin Date: 2014-02-10 13:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5e1086b5b726 Merge - src/os/bsd/dtrace/hotspot.d - src/os/bsd/dtrace/hotspot_jni.d - src/os/bsd/dtrace/hs_private.d - src/os/solaris/dtrace/hotspot.d - src/os/solaris/dtrace/hotspot_jni.d - src/os/solaris/dtrace/hs_private.d ! src/share/vm/runtime/arguments.cpp Changeset: 937cf56dede6 Author: stefank Date: 2014-02-10 12:51 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/937cf56dede6 8033764: Remove the usage of StarTask from BufferingOopClosure Reviewed-by: mgerdin, brutisso, tschatzl + src/share/vm/gc_implementation/g1/bufferingOopClosure.cpp ! src/share/vm/gc_implementation/g1/bufferingOopClosure.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/prims/jni.cpp Changeset: 553d15cdfec5 Author: ehelin Date: 2014-02-10 14:37 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/553d15cdfec5 Merge ! src/share/vm/prims/jni.cpp Changeset: 79aa45434291 Author: stefank Date: 2014-02-10 12:58 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/79aa45434291 8033923: Use BufferingOopClosure for G1 code root scanning Reviewed-by: mgerdin, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: e5d78f318aec Author: jwilhelm Date: 2013-12-10 15:11 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e5d78f318aec 8026849: Fix typos in the GC code, part 2 Summary: Fixed typos in assert messages, flag descriptions and verbose messages Reviewed-by: stefank, tschatzl ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/virtualspace.cpp Changeset: f7f0c6a77d6d Author: sjohanss Date: 2014-02-05 11:05 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f7f0c6a77d6d 8033426: Scale initial NewSize using NewRatio if not set on command line Summary: Now using NewRatio to size initial NewSize if not specified on commandline. Reviewed-by: jmasa, jwilhelm ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/prims/jni.cpp Changeset: e8ef156f0bc9 Author: ehelin Date: 2014-02-13 17:57 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e8ef156f0bc9 Merge ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp Changeset: 9a48187fef5e Author: jeff Date: 2014-01-13 14:42 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/9a48187fef5e 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: 53ea3def1ed5 Author: jeff Date: 2014-01-28 20:09 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/53ea3def1ed5 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README Changeset: 4c8bda53850f Author: katleman Date: 2014-02-06 13:08 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/4c8bda53850f Added tag jdk9-b02 for changeset b188446de75b ! .hgtags Changeset: b2fee789d23f Author: lana Date: 2014-02-11 11:26 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/b2fee789d23f Merge Changeset: 9b30c71e00d0 Author: lana Date: 2014-02-20 19:59 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/9b30c71e00d0 Merge Changeset: 7907932bdd99 Author: henryjen Date: 2014-02-11 21:32 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/7907932bdd99 8033215: clang: node.cpp:284 IDX_INIT macro use uninitialized field _out Reviewed-by: twisti, kvn ! src/share/vm/opto/node.cpp Changeset: 46eeb3056482 Author: dsamersoff Date: 2014-02-12 22:08 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/46eeb3056482 8023667: SA: ExceptionBlob and other C2 classes not available in client VM Summary: Ignore error of intialization of C2 only variables Reviewed-by: sla, dholmes ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js Changeset: b6ab2c9abfc5 Author: mduigou Date: 2014-02-12 09:37 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/b6ab2c9abfc5 8030350: Enable additional compiler warnings for GCC Reviewed-by: dholmes, coleenp, erikj, tbell, ihse ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/gcc.make ! src/os/bsd/vm/os_bsd.cpp Changeset: e8af40d8de60 Author: mduigou Date: 2014-02-12 10:55 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e8af40d8de60 Merge Changeset: 4f6bf7dd3f52 Author: ccheung Date: 2014-02-12 12:01 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/4f6bf7dd3f52 8028785: [parfait] warnings from b116 for hotspot.src.share.vm.prims: JNI exception pending Summary: added JNI exception pending check in several files under src/share/vm/prims directory Reviewed-by: coleenp, minqi ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/prims/whitebox.hpp Changeset: e4e51dc2dca5 Author: ccheung Date: 2014-02-12 12:09 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e4e51dc2dca5 Merge Changeset: 0d10bb7339a9 Author: ctornqvi Date: 2014-02-12 20:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0d10bb7339a9 8034781: [TESTBUG] runtime/ClassFileUnsupportedClassFileVersion.java unable to find or load main class Summary: Passed empty string to ProcessBuilder which caused problems on Linux, fixed by checking string length Reviewed-by: lfoltan, sla, mseledtsov ! test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java Changeset: d7cb88bd7046 Author: dsamersoff Date: 2014-02-12 23:39 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/d7cb88bd7046 7127191: SA JSDB does not display native symbols correctly for transported Linux cores Summary: Better handle SA_ALTROOT Reviewed-by: sla, sspitsyn ! agent/src/os/linux/libproc_impl.c ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js Changeset: a33338c961e2 Author: dsamersoff Date: 2014-02-12 21:55 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/a33338c961e2 Merge Changeset: 93206a165a90 Author: dsamersoff Date: 2014-02-12 22:16 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/93206a165a90 Merge Changeset: 9e2a544d59cc Author: ccheung Date: 2014-02-14 09:50 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/9e2a544d59cc 8034860: Fatal error due to incorrect thread state during nightly testing Summary: use the HAS_PENDING_EXCEPTION and CLEAR_PENDING_EXCEPTION macros Reviewed-by: dholmes, coleenp, dcubed ! src/share/vm/prims/whitebox.hpp Changeset: cbdbdd6577f6 Author: sjiang Date: 2014-02-14 16:17 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/cbdbdd6577f6 8007710: runtime/7158988/FieldMonitor.java fails with com.sun.jdi.VMDisconnectedException: Connection closed Reviewed-by: sla, jbachorik, sspitsyn ! test/runtime/7158988/FieldMonitor.java Changeset: 48314d596a04 Author: coleenp Date: 2014-02-15 13:03 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/48314d596a04 8027146: Class loading verification failure if GC occurs in Universe::flush_dependents_on Summary: Remove search in system dictionary and hacks, replace with verifying in CLD::_klasses list. Reviewed-by: dcubed, acorn ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.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/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp Changeset: c66479743828 Author: hseigel Date: 2014-02-15 14:41 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/c66479743828 Merge ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/whitebox.cpp Changeset: e6195383bcaf Author: sla Date: 2014-02-18 09:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e6195383bcaf 8034080: Remove the USDT1 dtrace code from Hotspot Reviewed-by: dholmes, coleenp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/runtimeService.cpp ! src/share/vm/utilities/dtrace.hpp + src/share/vm/utilities/dtrace_disabled.hpp - src/share/vm/utilities/dtrace_usdt2_disabled.hpp Changeset: 402677ca28ed Author: sspitsyn Date: 2014-02-18 06:19 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/402677ca28ed 8034249: need more workarounds for suspend equivalent condition issue Summary: Collect data at safepoint, do not rely on thread suspension Reviewed-by: dcubed, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp Changeset: 805784307dca Author: coleenp Date: 2014-02-18 09:54 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/805784307dca 8035132: [TESTBUG] test/runtime/lambda-features/InvokespecialInterface.java test has unrecognized option Summary: add IgnoreUnrecognizedVMOptions for product mode run Reviewed-by: ctornqvi, dholmes ! test/runtime/lambda-features/InvokespecialInterface.java Changeset: 5ec7dace41a6 Author: roland Date: 2014-01-24 09:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5ec7dace41a6 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed Summary: type methods shouldn't always operate on speculative part Reviewed-by: kvn, twisti ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp + test/compiler/types/TestSpeculationFailedHigherEqual.java Changeset: 17ec2d5c43e8 Author: shade Date: 2014-01-24 15:26 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/17ec2d5c43e8 8032490: Remove -XX:+-UseOldInlining Summary: Move the option to obsolete options list, purge the redundant compiler code. Reviewed-by: kvn, jrose ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 0a66ed4b0b27 Author: kvn Date: 2014-01-24 13:30 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/0a66ed4b0b27 Merge Changeset: 11985e4d4255 Author: anoll Date: 2014-01-27 07:54 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/11985e4d4255 8009738: compiler/6826736/Test.java times out on big machines Summary: Added -Xmx256m -XX:ParallelGCThreads=4 to the test @run command. Verified that 256m is enough to trigger old 6826736 bug. Reviewed-by: kvn ! test/compiler/6826736/Test.java Changeset: 303f79ab8e3d Author: anoll Date: 2014-01-26 23:01 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/303f79ab8e3d Merge Changeset: c84312468f5c Author: adlertz Date: 2014-01-24 13:06 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c84312468f5c 8031498: Cleanup and re-factorize PhaseChaitin::build_ifg_physical Summary: Created sub-functions, added data structures, improved naming and removed unnecessary code Reviewed-by: kvn, roland, rbackman ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/ifg.cpp Changeset: 164db61dbced Author: goetz Date: 2013-06-19 12:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/164db61dbced 8016476: PPC64 (part 1): reenable CORE build Summary: reenable CORE build on PPC64 Reviewed-by: dholmes, kvn, coleenp ! make/Makefile Changeset: 0f03ff49c720 Author: goetz Date: 2013-06-19 12:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0f03ff49c720 8016491: PPC64 (part 2): Clean up PPC defines. Summary: Distinguish PPC, PPC64 and PPC32. PPC should guard code needed on any PPC system. PPC32 and PPC64 should guard code needed in a port for the ppc64 or ppc32 instruction set. Reviewed-by: kvn ! make/linux/platform_ppc ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.hpp ! src/os_cpu/linux_zero/vm/os_linux_zero.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/macros.hpp Changeset: d2907f74462e Author: goetz Date: 2013-06-20 16:30 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d2907f74462e 8016586: PPC64 (part 3): basic changes for PPC64 Summary: added #includes needed for ppc64 port. Renamed _MODEL_ppc to _MODEL_ppc_32 and renamed corresponding old _ppc files to _ppc_32. Reviewed-by: dholmes, kvn ! agent/src/os/linux/libproc.h ! make/linux/platform_ppc ! src/os/linux/vm/os_linux.cpp ! src/share/vm/adlc/main.cpp ! src/share/vm/code/vmreg.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_version.cpp Changeset: b5c8a61d7fa0 Author: kvn Date: 2013-06-21 15:56 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b5c8a61d7fa0 Merge ! make/Makefile ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/vmStructs.cpp - src/share/vm/trace/traceEventTypes.hpp ! src/share/vm/utilities/macros.hpp Changeset: f4f6ae481e1a Author: kvn Date: 2013-06-27 13:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f4f6ae481e1a Merge ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 58be756e7595 Author: goetz Date: 2013-06-24 17:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/58be756e7595 8017313: PPC64 (part 6): stack handling improvements Summary: Precompute limit for stack overflow check. Reviewed-by: kvn, coleenp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 48d3d0eb193b Author: goetz Date: 2013-06-26 16:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/48d3d0eb193b 8017317: PPC64 (part 7): cppInterpreter: implement support for biased locking Reviewed-by: kvn, dholmes ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: 583211d4b16b Author: kvn Date: 2013-07-03 11:50 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/583211d4b16b Merge ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 53fa76359eb1 Author: goetz Date: 2013-07-04 10:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/53fa76359eb1 8016696: PPC64 (part 4): add relocation for trampoline stubs Summary: A trampoline allows to encode a small branch in the code, even if there is the chance that this branch can not reach all possible code locations. If the relocation finds that a branch is too far for the instruction in the code, it can patch it to jump to the trampoline where is sufficient space for a far branch. Needed on PPC. Reviewed-by: kvn, bdelsart, jrose ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp Changeset: 641d55c11d6b Author: goetz Date: 2013-07-03 01:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/641d55c11d6b 8019517: PPC64 (part 102): cppInterpreter: implement G1 support Reviewed-by: kvn ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: 48b178ff07b6 Author: goetz Date: 2013-07-03 01:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/48b178ff07b6 8019518: PPC64 (part 103): cppInterpreter: implement support for compressed Oops Reviewed-by: kvn, coleenp ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: bfd9d884693d Author: goetz Date: 2013-07-03 11:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bfd9d884693d 8019519: PPC64 (part 105): C interpreter: implement support for jvmti early return. Reviewed-by: sspitsyn, kvn ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp Changeset: 0014add32e54 Author: goetz Date: 2013-07-09 14:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0014add32e54 8020121: PPC64: fix build in cppInterpreter after 8019519 Reviewed-by: kvn ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: faf0c78e906b Author: simonis Date: 2013-07-10 09:14 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/faf0c78e906b 8019922: PPC64 (part 8): Implement Linux/PPC64 support in HotSpot makefiles Summary: HotSpot make changes to build the HotSpot on Linux/PPC64 Reviewed-by: dholmes, kvn ! make/Makefile ! make/defs.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make + make/linux/makefiles/ppc64.make + make/linux/platform_ppc64 Changeset: 75ef1a499665 Author: goetz Date: 2013-07-05 22:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/75ef1a499665 8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX. Summary: On AIX 7.1 systemcfg.h defines IA64 unconditionally, so test for !AIX where IA64 is used. Reviewed-by: dholmes, kvn ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/utilities/macros.hpp Changeset: 6cc7093e1341 Author: kvn Date: 2013-07-11 12:56 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6cc7093e1341 Merge ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 438e13354adf Author: kvn Date: 2013-07-19 13:32 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/438e13354adf Merge ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp - src/share/vm/memory/klassInfoClosure.hpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: c9f0adfb4a8b Author: simonis Date: 2013-07-26 10:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c9f0adfb4a8b 8019926: PPC64 (part 106): Make hsdis build and work on Linux/PPC64 Summary: Make hsdis work on Linux/PPC64 and AIX/PPC64 Reviewed-by: kvn ! src/share/tools/hsdis/Makefile ! src/share/tools/hsdis/README ! src/share/tools/hsdis/hsdis.c Changeset: 94c202aa2646 Author: kvn Date: 2013-08-01 17:25 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/94c202aa2646 Merge ! src/share/vm/opto/matcher.cpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: ec28f9c041ff Author: goetz Date: 2013-08-02 16:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ec28f9c041ff 8019972: PPC64 (part 9): platform files for interpreter only VM. Summary: With this change the HotSpot core build works on Linux/PPC64. The VM succesfully executes simple test programs. Reviewed-by: kvn + src/cpu/ppc/vm/assembler_ppc.cpp + src/cpu/ppc/vm/assembler_ppc.hpp + src/cpu/ppc/vm/assembler_ppc.inline.hpp + src/cpu/ppc/vm/bytecodeInterpreter_ppc.hpp + src/cpu/ppc/vm/bytecodeInterpreter_ppc.inline.hpp + src/cpu/ppc/vm/bytecodes_ppc.cpp + src/cpu/ppc/vm/bytecodes_ppc.hpp + src/cpu/ppc/vm/bytes_ppc.hpp + src/cpu/ppc/vm/codeBuffer_ppc.hpp + src/cpu/ppc/vm/compiledIC_ppc.cpp + src/cpu/ppc/vm/copy_ppc.hpp + src/cpu/ppc/vm/cppInterpreterGenerator_ppc.hpp + src/cpu/ppc/vm/cppInterpreter_ppc.cpp + src/cpu/ppc/vm/cppInterpreter_ppc.hpp + src/cpu/ppc/vm/debug_ppc.cpp + src/cpu/ppc/vm/depChecker_ppc.hpp + src/cpu/ppc/vm/disassembler_ppc.hpp + src/cpu/ppc/vm/frame_ppc.cpp + src/cpu/ppc/vm/frame_ppc.hpp + src/cpu/ppc/vm/frame_ppc.inline.hpp + src/cpu/ppc/vm/globalDefinitions_ppc.hpp + src/cpu/ppc/vm/globals_ppc.hpp + src/cpu/ppc/vm/icBuffer_ppc.cpp + src/cpu/ppc/vm/icache_ppc.cpp + src/cpu/ppc/vm/icache_ppc.hpp + src/cpu/ppc/vm/interp_masm_ppc_64.cpp + src/cpu/ppc/vm/interp_masm_ppc_64.hpp + src/cpu/ppc/vm/interpreterGenerator_ppc.hpp + src/cpu/ppc/vm/interpreterRT_ppc.cpp + src/cpu/ppc/vm/interpreterRT_ppc.hpp + src/cpu/ppc/vm/interpreter_ppc.cpp + src/cpu/ppc/vm/interpreter_ppc.hpp + src/cpu/ppc/vm/javaFrameAnchor_ppc.hpp + src/cpu/ppc/vm/jniFastGetField_ppc.cpp + src/cpu/ppc/vm/jniTypes_ppc.hpp + src/cpu/ppc/vm/jni_ppc.h + src/cpu/ppc/vm/macroAssembler_ppc.cpp + src/cpu/ppc/vm/macroAssembler_ppc.hpp + src/cpu/ppc/vm/macroAssembler_ppc.inline.hpp + src/cpu/ppc/vm/metaspaceShared_ppc.cpp + src/cpu/ppc/vm/methodHandles_ppc.cpp + src/cpu/ppc/vm/methodHandles_ppc.hpp + src/cpu/ppc/vm/nativeInst_ppc.cpp + src/cpu/ppc/vm/nativeInst_ppc.hpp + src/cpu/ppc/vm/registerMap_ppc.hpp + src/cpu/ppc/vm/register_definitions_ppc.cpp + src/cpu/ppc/vm/register_ppc.cpp + src/cpu/ppc/vm/register_ppc.hpp + src/cpu/ppc/vm/relocInfo_ppc.cpp + src/cpu/ppc/vm/relocInfo_ppc.hpp + src/cpu/ppc/vm/sharedRuntime_ppc.cpp + src/cpu/ppc/vm/stubGenerator_ppc.cpp + src/cpu/ppc/vm/stubRoutines_ppc_64.cpp + src/cpu/ppc/vm/stubRoutines_ppc_64.hpp + src/cpu/ppc/vm/vmStructs_ppc.hpp + src/cpu/ppc/vm/vm_version_ppc.cpp + src/cpu/ppc/vm/vm_version_ppc.hpp + src/cpu/ppc/vm/vmreg_ppc.cpp + src/cpu/ppc/vm/vmreg_ppc.hpp + src/cpu/ppc/vm/vmreg_ppc.inline.hpp + src/cpu/ppc/vm/vtableStubs_ppc_64.cpp + src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp + src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp + src/os_cpu/linux_ppc/vm/orderAccess_linux_ppc.inline.hpp + src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp + src/os_cpu/linux_ppc/vm/os_linux_ppc.hpp + src/os_cpu/linux_ppc/vm/prefetch_linux_ppc.inline.hpp + src/os_cpu/linux_ppc/vm/threadLS_linux_ppc.cpp + src/os_cpu/linux_ppc/vm/threadLS_linux_ppc.hpp + src/os_cpu/linux_ppc/vm/thread_linux_ppc.cpp + src/os_cpu/linux_ppc/vm/thread_linux_ppc.hpp + src/os_cpu/linux_ppc/vm/vmStructs_linux_ppc.hpp ! src/share/vm/runtime/globals.hpp Changeset: b55e4bd0389e Author: kvn Date: 2013-08-16 16:23 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b55e4bd0389e Merge ! src/share/vm/runtime/globals.hpp - test/runtime/7196045/Test7196045.java - test/runtime/8000968/Test8000968.sh Changeset: f42f2e2a1518 Author: goetz Date: 2013-07-26 00:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f42f2e2a1518 8020775: PPC64 (part 12): posix signal printing Summary: Implement methods printing posix signal information and call them in unix os files. Reviewed-by: kvn, dholmes, twisti Contributed-by: thomas.stuefe at sap.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/posix/vm/os_posix.hpp ! src/os/solaris/vm/os_solaris.cpp Changeset: bdd155477289 Author: goetz Date: 2013-08-22 09:39 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/bdd155477289 8023033: PPC64 (part 13): basic changes for AIX Summary: Added AIX includes alpha-sorted before BSD. Fix compilation issues with xlC in shared code. Basic shared platform dependend adaption (vm_version etc.). Reviewed-by: kvn, dholmes, stefank ! src/os/posix/vm/os_posix.cpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/code/stubs.hpp ! src/share/vm/code/vmreg.hpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/libadt/port.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.inline.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/javaFrameAnchor.hpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/osThread.hpp ! src/share/vm/runtime/sharedRuntimeTrans.cpp ! src/share/vm/runtime/sharedRuntimeTrig.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/thread.inline.hpp ! src/share/vm/runtime/threadLocalStorage.hpp ! src/share/vm/runtime/timer.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/accessFlags.cpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/histogram.hpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/resourceHash.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: e2722a66aba7 Author: kvn Date: 2013-09-05 11:04 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e2722a66aba7 Merge ! make/linux/makefiles/gcc.make ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/vm/os_solaris.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/vm/code/nmethod.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/output.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/taskqueue.hpp - test/runtime/7051189/Xchecksig.sh Changeset: 7687c56b6693 Author: goetz Date: 2013-09-06 10:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7687c56b6693 8024379: Adapt PPC64 port to 8003424 Reviewed-by: coleenp ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/relocInfo_ppc.cpp Changeset: b83f7d608548 Author: simonis Date: 2013-09-06 20:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b83f7d608548 8023034: PPC64 (part 14): Implement AIX/PPC64 support in HotSpot makefiles Reviewed-by: kvn + make/aix/Makefile + make/aix/adlc_updater + make/aix/makefiles/adjust-mflags.sh + make/aix/makefiles/adlc.make + make/aix/makefiles/build_vm_def.sh + make/aix/makefiles/buildtree.make + make/aix/makefiles/compiler2.make + make/aix/makefiles/core.make + make/aix/makefiles/debug.make + make/aix/makefiles/defs.make + make/aix/makefiles/dtrace.make + make/aix/makefiles/fastdebug.make + make/aix/makefiles/jsig.make + make/aix/makefiles/jvmti.make + make/aix/makefiles/mapfile-vers-debug + make/aix/makefiles/mapfile-vers-jsig + make/aix/makefiles/mapfile-vers-product + make/aix/makefiles/ppc64.make + make/aix/makefiles/product.make + make/aix/makefiles/rules.make + make/aix/makefiles/sa.make + make/aix/makefiles/saproc.make + make/aix/makefiles/top.make + make/aix/makefiles/trace.make + make/aix/makefiles/vm.make + make/aix/makefiles/xlc.make + make/aix/platform_ppc64 ! make/defs.make Changeset: 666e6ce3976c Author: simonis Date: 2013-09-06 20:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/666e6ce3976c 8023038: PPC64 (part 15): Platform files for AIX/PPC64 support Reviewed-by: kvn + src/os/aix/vm/attachListener_aix.cpp + src/os/aix/vm/c2_globals_aix.hpp + src/os/aix/vm/decoder_aix.hpp + src/os/aix/vm/globals_aix.hpp + src/os/aix/vm/interfaceSupport_aix.hpp + src/os/aix/vm/jsig.c + src/os/aix/vm/jvm_aix.cpp + src/os/aix/vm/jvm_aix.h + src/os/aix/vm/libperfstat_aix.cpp + src/os/aix/vm/libperfstat_aix.hpp + src/os/aix/vm/loadlib_aix.cpp + src/os/aix/vm/loadlib_aix.hpp + src/os/aix/vm/mutex_aix.inline.hpp + src/os/aix/vm/osThread_aix.cpp + src/os/aix/vm/osThread_aix.hpp + src/os/aix/vm/os_aix.cpp + src/os/aix/vm/os_aix.hpp + src/os/aix/vm/os_aix.inline.hpp + src/os/aix/vm/os_share_aix.hpp + src/os/aix/vm/perfMemory_aix.cpp + src/os/aix/vm/porting_aix.cpp + src/os/aix/vm/porting_aix.hpp + src/os/aix/vm/threadCritical_aix.cpp + src/os/aix/vm/thread_aix.inline.hpp + src/os/aix/vm/vmError_aix.cpp + src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp + src/os_cpu/aix_ppc/vm/globals_aix_ppc.hpp + src/os_cpu/aix_ppc/vm/orderAccess_aix_ppc.inline.hpp + src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp + src/os_cpu/aix_ppc/vm/os_aix_ppc.hpp + src/os_cpu/aix_ppc/vm/prefetch_aix_ppc.inline.hpp + src/os_cpu/aix_ppc/vm/threadLS_aix_ppc.cpp + src/os_cpu/aix_ppc/vm/threadLS_aix_ppc.hpp + src/os_cpu/aix_ppc/vm/thread_aix_ppc.cpp + src/os_cpu/aix_ppc/vm/thread_aix_ppc.hpp + src/os_cpu/aix_ppc/vm/vmStructs_aix_ppc.hpp + src/share/vm/utilities/globalDefinitions_xlc.hpp Changeset: 6a936747b569 Author: goetz Date: 2013-09-12 13:51 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6a936747b569 8024344: PPC64 (part 112): C argument in register AND stack slot. Summary: On PPC, the first 13 floating point arguments to C calls are passed in floating point registers. Also, all but the first 8 arguments are passed on the stack. So there can be floating point arguments that are passed on the stack and in a register. We duplicate the regs datastructure in c_calling_convention() to represent this. Reviewed-by: kvn, cjplummer ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/cpu/zero/vm/globals_zero.hpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/cpu/zero/vm/shark_globals_zero.hpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: f3806614494a Author: goetz Date: 2013-09-13 22:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f3806614494a 8024469: PPC64 (part 202): cppInterpreter: support for OSR. Summary: Call OSR migration with last java frame. Reviewed-by: kvn ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: cfd05ec74089 Author: goetz Date: 2013-09-18 14:34 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/cfd05ec74089 8024342: PPC64 (part 111): Support for C calling conventions that require 64-bit ints. Summary: Some platforms, as ppc and s390x/zArch require that 32-bit ints are passed as 64-bit values to C functions. This change adds support to adapt the signature and to issue proper casts to c2-compiled stubs. The functions are used in generate_native_wrapper(). Adapt signature used by the compiler as in PhaseIdealLoop::intrinsify_fill(). Reviewed-by: kvn ! src/cpu/ppc/vm/globalDefinitions_ppc.hpp ! src/cpu/ppc/vm/sharedRuntime_ppc.cpp ! src/cpu/sparc/vm/globalDefinitions_sparc.hpp ! src/cpu/x86/vm/globalDefinitions_x86.hpp ! src/cpu/zero/vm/globalDefinitions_zero.hpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 7373e44fa207 Author: goetz Date: 2013-09-19 17:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7373e44fa207 8024922: PPC64 (part 116): Extend adlc to generate fields into nodes. Summary: Similar to specifying functions returning constants (as ins_avoid_back_to_back()) adlc now accepts specifications with prefix ins_field_xxx(tp) and adds field xxx of type tp to the node. Reviewed-by: kvn ! src/share/vm/adlc/output_h.cpp Changeset: abe03600372a Author: goetz Date: 2013-09-15 15:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/abe03600372a 8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling Summary: Implement profiling for c2 jit compilation. Also enable new cppInterpreter features. Reviewed-by: kvn ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp + src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/invocationCounter.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/prims/jvmtiManageCapabilities.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 3068270ba476 Author: simonis Date: 2013-10-16 10:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3068270ba476 8026487: PPC64: Implement 'os::fork_and_exec' on AIX Reviewed-by: kvn, twisti ! src/os/aix/vm/os_aix.cpp Changeset: 2b8e28fdf503 Author: kvn Date: 2013-11-05 17:38 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/2b8e28fdf503 Merge ! make/Makefile ! make/defs.make ! make/linux/makefiles/gcc.make ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/globals_zero.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/adlc/main.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/classfile/classLoader.cpp - src/share/vm/classfile/genericSignatures.cpp - src/share/vm/classfile/genericSignatures.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/libadt/port.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! 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/virtualspace.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/taskqueue.hpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java - 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/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java Changeset: bd29f2c96a5f Author: goetz Date: 2013-11-07 11:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bd29f2c96a5f 8027964: Adapt PPC to 6843347: Boundary values in some public GC options cause crashes Reviewed-by: dholmes ! src/cpu/ppc/vm/globals_ppc.hpp Changeset: a0d02bb625e2 Author: goetz Date: 2013-11-07 11:42 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a0d02bb625e2 8027965: Adapt PPC to 8015107: NPG: Use consistent naming for metaspace concepts Reviewed-by: dholmes ! src/cpu/ppc/vm/macroAssembler_ppc.cpp Changeset: 2e3c546f46d9 Author: goetz Date: 2013-11-07 11:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2e3c546f46d9 8027966: Adapt PPC to 8023657: New type profiling points: arguments to call Reviewed-by: dholmes ! src/cpu/ppc/vm/globals_ppc.hpp Changeset: 600acc4b8b1e Author: goetz Date: 2013-11-07 11:51 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/600acc4b8b1e 8027969: Adapt PPC to 8026328: Setting a breakpoint on invokedynamic crashes the JVM Reviewed-by: dholmes, coleenp, sspitsyn ! src/cpu/ppc/vm/cppInterpreter_ppc.cpp Changeset: eb178e97560c Author: goetz Date: 2013-11-07 11:47 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/eb178e97560c 8027968: Adapt PPC to 8024927: Nashorn performance regression with CompressedOops Reviewed-by: coleenp, kvn ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.hpp ! src/cpu/ppc/vm/vtableStubs_ppc_64.cpp Changeset: 044b28168e20 Author: goetz Date: 2013-11-14 19:24 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/044b28168e20 8003854: PPC64 (part 115): Introduce PostallocExpand that expands nodes after register allocation Summary: added ability in C2 to expand mach nodes to several mach nodes after register allocation Reviewed-by: kvn ! 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/adlparse.hpp ! src/share/vm/adlc/archDesc.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp Changeset: 2113136690bc Author: goetz Date: 2013-11-15 11:05 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/2113136690bc 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering Summary: Add a field to C2 LoadNode and StoreNode classes which indicates whether the load/store should do an acquire/release on platforms which support it. Reviewed-by: kvn ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/opto/vectornode.hpp Changeset: ea78de16a4a4 Author: kvn Date: 2013-11-15 14:09 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/ea78de16a4a4 Merge Changeset: 1410ad6b05f1 Author: goetz Date: 2013-11-15 12:01 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/1410ad6b05f1 8028401: PPC (part 117): Improve usability of adlc and format() functionality. Summary: Add additional, more verbose syntax checks in adlc. Fix printing constant's problem in format(). Reviewed-by: kvn ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp Changeset: 935bf3340572 Author: goetz Date: 2013-11-16 01:42 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/935bf3340572 8028470: PPC64 (part 214): linux: extend signal handler to catch SIGTRAP on ppc64. Reviewed-by: kvn ! src/os/linux/vm/os_linux.cpp Changeset: 018b357638aa Author: simonis Date: 2013-11-19 11:53 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/018b357638aa 8028514: PPC64: Fix C++ Interpreter after '7195622: CheckUnhandledOops has limited usefulness now' Summary: fix CPP-interpreter after CheckUnhandledOops was re-enabled in the fastdebug build Reviewed-by: kvn, dholmes, lfoltan ! src/cpu/ppc/vm/bytecodeInterpreter_ppc.hpp ! src/cpu/ppc/vm/frame_ppc.cpp ! src/cpu/ppc/vm/nativeInst_ppc.cpp ! src/cpu/sparc/vm/bytecodeInterpreter_sparc.hpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.hpp ! src/cpu/zero/vm/bytecodeInterpreter_zero.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/oops/methodData.hpp Changeset: 318d0622a6d7 Author: goetz Date: 2013-11-20 11:08 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/318d0622a6d7 8028580: PPC64 (part 114/120): Support for Call nodes with constants. Summary: extends MachCall nodes so that they can issue constants to the constant table Reviewed-by: kvn ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/output.cpp Changeset: da862781b584 Author: kvn Date: 2013-11-21 12:30 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/da862781b584 Merge ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: b0133e4187d3 Author: goetz Date: 2013-11-21 18:29 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/b0133e4187d3 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. Summary: Fixed Implicit NULL check optimization for AIX, where the page at address '0' is only write-protected. Reviewed-by: kvn ! src/cpu/ppc/vm/globals_ppc.hpp ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.inline.hpp ! src/cpu/ppc/vm/sharedRuntime_ppc.cpp ! src/cpu/ppc/vm/vtableStubs_ppc_64.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os/linux/vm/os_linux.hpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/windows/vm/os_windows.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/lcm.cpp Changeset: 15120a36272d Author: goetz Date: 2013-11-21 19:00 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/15120a36272d 8028767: PPC64: (part 121): smaller shared changes needed to build C2 Summary: smaller shared changes required to build the C2 compiler on PPC64. Reviewed-by: kvn ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/regalloc.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: 4cdf4f71177d Author: goetz Date: 2013-11-22 12:14 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/4cdf4f71177d 8029025: PPC64 (part 203): opto: Move static _in_dump_cnt to Compile object. Summary: Also introduces the compiler oracle 'option' feature for PrintAssembly. Reviewed-by: kvn ! src/share/vm/code/nmethod.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp Changeset: 50fdb38839eb Author: goetz Date: 2013-11-26 18:38 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/50fdb38839eb 8028515: PPPC64 (part 113.2): opto: Introduce LoadFence/StoreFence. Summary: Use new nodes for loadFence/storeFence intrinsics in C2. Reviewed-by: kvn, dholmes ! make/jprt.properties ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 41b780b43b74 Author: goetz Date: 2013-11-27 16:16 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/41b780b43b74 8029015: PPC64 (part 216): opto: trap based null and range checks Summary: On PPC64 use tdi instruction that does a compare and raises SIGTRAP for NULL and range checks. Reviewed-by: kvn ! src/cpu/ppc/vm/globals_ppc.hpp ! src/cpu/ppc/vm/nativeInst_ppc.hpp ! src/cpu/ppc/vm/vm_version_ppc.cpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/adlc/main.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/runtime/globals.hpp Changeset: e7cbc95179c4 Author: simonis Date: 2013-12-05 19:19 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e7cbc95179c4 8019929: PPC64 (part 107): Extend ELF-decoder to support PPC64 function descriptor tables Summary: Extend ELF-decoder to support PPC64 function descriptor tables Reviewed-by: kvn, zgu ! make/aix/makefiles/vm.make ! src/os/linux/vm/decoder_linux.cpp ! src/share/vm/utilities/decoder_elf.cpp ! src/share/vm/utilities/decoder_elf.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp + src/share/vm/utilities/elfFuncDescTable.cpp + src/share/vm/utilities/elfFuncDescTable.hpp ! src/share/vm/utilities/elfStringTable.cpp ! src/share/vm/utilities/elfStringTable.hpp ! src/share/vm/utilities/elfSymbolTable.cpp ! src/share/vm/utilities/elfSymbolTable.hpp Changeset: 1174c8abbdb6 Author: kvn Date: 2013-12-05 15:13 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/1174c8abbdb6 Merge ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp - test/compiler/jsr292/methodHandleExceptions/C.java - test/compiler/jsr292/methodHandleExceptions/I.java Changeset: 3205e78d8193 Author: goetz Date: 2013-12-02 10:26 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3205e78d8193 8029396: PPC64 (part 212): Several memory ordering fixes in C-code. Summary: memory ordering fixes in GC and other runtime code showing on PPC64. Reviewed-by: kvn, coleenp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/barrierSet.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/modRefBarrierSet.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/thread.hpp Changeset: 492e67693373 Author: goetz Date: 2013-12-10 14:29 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/492e67693373 8029888: PPC64: (part 219): adl replacement variable CondRegister Summary: Add support for replacement variable CondRegister in adlc. Reviewed-by: kvn ! src/share/vm/adlc/output_c.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/opto/machnode.hpp Changeset: 67fa91961822 Author: goetz Date: 2013-12-11 00:06 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/67fa91961822 8029940: PPC64 (part 122): C2 compiler port Reviewed-by: kvn ! make/aix/makefiles/adlc.make ! src/cpu/ppc/vm/assembler_ppc.hpp ! src/cpu/ppc/vm/assembler_ppc.inline.hpp ! src/cpu/ppc/vm/bytecodeInterpreter_ppc.hpp ! src/cpu/ppc/vm/bytes_ppc.hpp + src/cpu/ppc/vm/c2_globals_ppc.hpp + src/cpu/ppc/vm/c2_init_ppc.cpp ! src/cpu/ppc/vm/copy_ppc.hpp ! src/cpu/ppc/vm/cppInterpreter_ppc.cpp ! src/cpu/ppc/vm/frame_ppc.cpp ! src/cpu/ppc/vm/frame_ppc.hpp ! src/cpu/ppc/vm/frame_ppc.inline.hpp ! src/cpu/ppc/vm/globals_ppc.hpp ! src/cpu/ppc/vm/icache_ppc.cpp ! src/cpu/ppc/vm/icache_ppc.hpp ! src/cpu/ppc/vm/interp_masm_ppc_64.cpp ! src/cpu/ppc/vm/interp_masm_ppc_64.hpp ! src/cpu/ppc/vm/interpreter_ppc.cpp ! src/cpu/ppc/vm/jni_ppc.h ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.hpp ! src/cpu/ppc/vm/macroAssembler_ppc.inline.hpp ! src/cpu/ppc/vm/methodHandles_ppc.cpp ! src/cpu/ppc/vm/nativeInst_ppc.cpp ! src/cpu/ppc/vm/nativeInst_ppc.hpp + src/cpu/ppc/vm/ppc.ad + src/cpu/ppc/vm/ppc_64.ad ! src/cpu/ppc/vm/register_definitions_ppc.cpp ! src/cpu/ppc/vm/register_ppc.cpp ! src/cpu/ppc/vm/register_ppc.hpp + src/cpu/ppc/vm/runtime_ppc.cpp ! src/cpu/ppc/vm/sharedRuntime_ppc.cpp ! src/cpu/ppc/vm/stubGenerator_ppc.cpp ! src/cpu/ppc/vm/vm_version_ppc.cpp ! src/cpu/ppc/vm/vtableStubs_ppc_64.cpp ! src/os_cpu/aix_ppc/vm/orderAccess_aix_ppc.inline.hpp ! src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp ! src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp ! src/os_cpu/linux_ppc/vm/orderAccess_linux_ppc.inline.hpp ! src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp Changeset: b4e19a1e459f Author: goetz Date: 2013-12-11 12:28 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b4e19a1e459f 8029957: PPC64 (part 213): cppInterpreter: memory ordering for object initialization Summary: Add StoreStore barriers after object initialization and after constructor calls in the C++ interpreter. Reviewed-by: kvn ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: 2da20f966936 Author: kvn Date: 2013-12-12 11:05 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/2da20f966936 Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 134e52455808 Author: kvn Date: 2014-01-08 11:24 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/134e52455808 Merge Changeset: ad6695638a35 Author: goetz Date: 2013-12-20 13:51 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ad6695638a35 8030863: PPC64: (part 220): ConstantTableBase for calls between args and jvms Summary: Add ConstantTableBase node edge after parameters and before jvms. Adapt jvms offsets. Reviewed-by: kvn ! src/cpu/ppc/vm/ppc.ad ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/archDesc.hpp ! src/share/vm/adlc/main.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/matcher.cpp Changeset: c3efa8868779 Author: goetz Date: 2014-01-06 11:02 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c3efa8868779 8031188: Fix for 8029015: PPC64 (part 216): opto: trap based null and range checks Summary: Swap the Projs in the block list so that the new block is added behind the proper node. Reviewed-by: kvn ! src/share/vm/opto/block.cpp Changeset: b858620b0081 Author: goetz Date: 2014-01-07 17:24 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b858620b0081 8031319: PPC64: Some fixes in ppc and aix coding. Reviewed-by: kvn ! src/cpu/ppc/vm/cppInterpreter_ppc.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/nativeInst_ppc.cpp ! src/cpu/ppc/vm/nativeInst_ppc.hpp ! src/cpu/ppc/vm/ppc.ad ! src/cpu/ppc/vm/stubGenerator_ppc.cpp ! src/os/aix/vm/os_aix.cpp ! src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp Changeset: c6d7e7406136 Author: goetz Date: 2014-01-16 14:25 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c6d7e7406136 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes Reviewed-by: dholmes, kvn Contributed-by: martin.doerr at sap.com ! src/cpu/ppc/vm/globalDefinitions_ppc.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 12fb826833f0 Author: kvn Date: 2014-01-22 14:27 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/12fb826833f0 Merge Changeset: 6a6c94b49dab Author: goetz Date: 2014-01-24 10:23 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6a6c94b49dab 8032634: Add #ifdef PPC64 around OrderAccess operations on _thread_state. Reviewed-by: dholmes, kvn ! src/share/vm/runtime/thread.hpp Changeset: f0221ff14605 Author: kvn Date: 2014-01-28 10:19 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/f0221ff14605 8029941: rollback changes in make/jprt.properties for embedded testing Summary: cleanup changes merged by accident Reviewed-by: roland, dholmes ! make/jprt.properties Changeset: abec000618bf Author: kvn Date: 2014-01-28 12:25 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/abec000618bf Merge ! agent/src/os/linux/libproc.h ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/globalDefinitions_sparc.hpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/globalDefinitions_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/globals_zero.hpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/os/posix/vm/os_posix.hpp ! src/share/tools/hsdis/hsdis.c ! 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/main.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/space.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp ! src/share/vm/opto/regalloc.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/prims/forte.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/macros.hpp Changeset: 45467c53f178 Author: kvn Date: 2014-01-28 12:28 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/45467c53f178 Merge ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 0c521b3f32dd Author: goetz Date: 2014-01-29 12:22 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0c521b3f32dd 8033117: PPC64: Adapt to 8002074: Support for AES on SPARC Summary: Implement missing function Matcher::pass_original_key_for_aes() in ppc64 ad file. Reviewed-by: kvn ! src/cpu/ppc/vm/ppc.ad ! src/cpu/ppc/vm/stubGenerator_ppc.cpp Changeset: 194e8b7fe9ca Author: goetz Date: 2014-01-30 14:30 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/194e8b7fe9ca 8033168: PPC64: gcc 4.8 warning in output_c.cpp Summary: fix warnings Reviewed-by: kvn ! src/share/vm/adlc/output_c.cpp Changeset: 8a9bb7821e28 Author: kvn Date: 2014-02-19 12:08 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/8a9bb7821e28 Merge ! make/Makefile ! make/linux/makefiles/buildtree.make ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/modRefBarrierSet.hpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/sharedRuntimeTrans.cpp ! src/share/vm/runtime/sharedRuntimeTrig.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: a13badbb8b8e Author: goetz Date: 2014-02-19 14:03 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/a13badbb8b8e 8034797: AIX: Fix os::naked_short_sleep() in os_aix.cpp after 8028280 Summary: imlements os::naked_short_sleep(jlong ms) on AIX Reviewed-by: dholmes, kvn ! src/os/aix/vm/os_aix.cpp Changeset: 1e820011ee5f Author: goetz Date: 2014-02-20 10:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1e820011ee5f 8035392: cppInterpreter: fix message of NPE Reviewed-by: kvn Contributed-by: axel.siebenborn at sap.com ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: 0f19095fd8c1 Author: goetz Date: 2014-02-20 11:05 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0f19095fd8c1 8035394: PPC64: Make usage of intrinsic dsqrt depend on processor recognition. Reviewed-by: kvn ! src/cpu/ppc/vm/ppc.ad ! src/share/vm/opto/library_call.cpp Changeset: 3ef193f311ed Author: simonis Date: 2014-02-20 14:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3ef193f311ed 8035423: AIX: Fix os::get_default_process_handle() in os_aix.cpp after 8031968 Reviewed-by: kvn ! src/os/aix/vm/os_aix.cpp Changeset: 28f281e8de1d Author: kvn Date: 2014-02-20 12:20 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/28f281e8de1d Merge ! make/linux/makefiles/gcc.make ! src/os/bsd/vm/os_bsd.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp Changeset: d166675568f6 Author: stefank Date: 2014-02-13 17:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d166675568f6 8034761: Remove the do_code_roots parameter from process_strong_roots Reviewed-by: tschatzl, mgerdin, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.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/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp Changeset: 10c424c5a362 Author: stefank Date: 2014-02-14 09:29 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/10c424c5a362 8034764: Use process_strong_roots to adjust the StringTable Reviewed-by: tschatzl, brutisso ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp Changeset: aa8fab3bed11 Author: goetz Date: 2014-02-11 09:34 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/aa8fab3bed11 8034171: Remove use of template template parameters from binaryTreeDictionary. Reviewed-by: mgerdin, jmasa Contributed-by: matthias.baesken at sap.com ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 7ab49a697539 Author: ehelin Date: 2014-02-17 10:13 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7ab49a697539 Merge Changeset: f6490a5f084a Author: sjohanss Date: 2014-02-17 09:51 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f6490a5f084a 8033440: jmap reports unexpected used/free size of concurrent mark-sweep generation Summary: SA used the wrong type for the indexedFreeList in CompactibleFreeListSpace. Reviewed-by: coleenp, dsamersoff + agent/src/share/classes/sun/jvm/hotspot/memory/AdaptiveFreeList.java ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java - agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 1cc1d4ffcb84 Author: ehelin Date: 2014-02-21 10:00 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1cc1d4ffcb84 Merge - agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 80b39937b791 Author: amurillo Date: 2014-02-21 08:09 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/80b39937b791 Merge - agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java - src/share/vm/utilities/dtrace_usdt2_disabled.hpp Changeset: 2dd7abe7b841 Author: henryjen Date: 2014-02-25 23:59 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/2dd7abe7b841 8033898: undefined symbol when build hotspot with Xcode5 Reviewed-by: sla, dholmes ! make/bsd/makefiles/gcc.make Changeset: de7f1b016d55 Author: coleenp Date: 2014-02-19 02:58 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/de7f1b016d55 7014526: "java -version" crash on sparc with some values of HeapBaseMinAddress Summary: Make default HeapBaseMinAddress the minimum that can be specified. Reviewed-by: minqi, kvn, tschatzl, dholmes ! src/share/vm/runtime/arguments.cpp ! test/runtime/CompressedOops/CompressedClassPointers.java Changeset: 6c9332549827 Author: fparain Date: 2014-02-19 16:22 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/6c9332549827 6546236: Thread interrupt() of Thread.sleep() can be lost on Solaris due to race with signal handler Reviewed-by: dholmes, dcubed ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/os/windows/vm/os_windows.inline.hpp ! src/share/vm/runtime/os.hpp Changeset: 4510a3502166 Author: gtriantafill Date: 2014-02-20 16:38 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/4510a3502166 8034898: [TESTBUG]: Zero failure project - tag all Runtime JTReg bugs that fail nightly Summary: Use @ignore to exclude failing tests Reviewed-by: coleenp, ctornqvi, mseledtsov Contributed-by: george.triantafillou at oracle.com ! test/runtime/6925573/SortMethodsTest.java ! test/runtime/7107135/Test7107135.sh ! test/runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java ! test/runtime/SharedArchiveFile/CdsWriteError.java ! test/runtime/SharedArchiveFile/DefaultUseWithClient.java Changeset: 96d2c94bbdd0 Author: mgronlun Date: 2014-02-22 10:22 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/96d2c94bbdd0 8035493: JVMTI PopFrame capability must instruct compilers not to prune locals Reviewed-by: kvn, sla, coleenp, sspitsyn ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_ValueStack.cpp ! src/share/vm/c1/c1_ValueStack.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/graphKit.cpp Changeset: bb9356ec5967 Author: hseigel Date: 2014-02-23 13:16 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/bb9356ec5967 Merge - agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/os.hpp Changeset: dcca80b5e7e7 Author: sspitsyn Date: 2014-02-23 22:36 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/dcca80b5e7e7 8034867: Object references from expression stack are not visible as roots via jvmti FollowReferences and HeapDump Summary: The heap walking is inconsistent without following references from expression stack, so need to fix it Reviewed-by: coleenp, sspitsyn Contributed-by: axel.siebenborn at sap.com ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/services/heapDumper.cpp Changeset: 61ab121722b8 Author: mgronlun Date: 2014-02-24 13:29 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/61ab121722b8 8035650: Exclude AIX from VS.NET make/windows/projectcreator.make Reviewed-by: dholmes, sla ! make/windows/makefiles/projectcreator.make Changeset: 016b6a289fc4 Author: jbachorik Date: 2014-02-24 10:28 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/016b6a289fc4 4505697: nsk/jdi/ExceptionEvent/_itself_/exevent006 and exevent008 tests fail with InvocationTargetException Reviewed-by: dcubed, dholmes, sspitsyn ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/runtime/reflection.cpp Changeset: 5e7eb4244604 Author: ccheung Date: 2014-02-24 21:54 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/5e7eb4244604 8025519: [TESTBUG] runtime/7107135/Test7107135.sh need to use COMPILEJAVA for javac task Summary: modified some tests to use COMPILEJAVA instead of TESTJAVA for javac and include path Reviewed-by: dholmes, mseledtsov ! test/TEST.groups ! test/runtime/6929067/Test6929067.sh ! test/runtime/7107135/Test7107135.sh ! test/runtime/jsig/Test8017498.sh Changeset: be0ac0e8f6e7 Author: stefank Date: 2014-02-21 10:01 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/be0ac0e8f6e7 8035393: Use CLDClosure instead of CLDToOopClosure in frame::oops_interpreted_do Reviewed-by: tschatzl, coleenp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp Changeset: 3cdda110bbb5 Author: stefank Date: 2014-02-21 10:19 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3cdda110bbb5 8035412: Cleanup ClassLoaderData::is_alive Reviewed-by: coleenp, mgerdin ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp Changeset: e9d5c28e5059 Author: tschatzl Date: 2014-02-24 09:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e9d5c28e5059 8027559: Decrease code size and templatizing in G1ParCopyClosure::do_oop_work Summary: Move methods that are not dependent on any of G1ParCopyClosure's template parameters into G1ParCopyHelper. Further remove unused methods and members of the class hierarchy. Reviewed-by: mgerdin, stefank ! make/excludeSrc.make ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp + src/share/vm/gc_implementation/g1/g1OopClosures.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp Changeset: 4f227ecd7beb Author: tschatzl Date: 2014-02-24 09:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4f227ecd7beb 8035326: Assume non-NULL references in G1CollectedHeap::in_cset_fast_test Summary: Remove the assumption that G1CollectedHeap::in_cset_fast_test needs to check for NULL references. Most of the time this is not required, making the code doing this check multiple times. Reviewed-by: stefank, mgerdin, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 97300b6165f8 Author: tschatzl Date: 2014-02-24 09:41 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/97300b6165f8 8035329: Move G1ParCopyClosure::copy_to_survivor_space into G1ParScanThreadState Summary: Move G1ParCopyClosure::copy_to_survivor_space to decrease code size. Reviewed-by: stefank, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp Changeset: 60fd6d24f49f Author: tschatzl Date: 2014-02-24 10:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/60fd6d24f49f 8034948: Back out JDK-6976350 since it does not fix any issue Summary: Revert JDK-6976350 because it does not improve PLAB fragmentation. To the contrary, it tends to increase the amount of wasted space with many threads. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp Changeset: f460c6926af7 Author: ehelin Date: 2014-02-25 11:02 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f460c6926af7 Merge ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmThread.cpp - src/share/vm/utilities/dtrace_usdt2_disabled.hpp Changeset: 3f406218c511 Author: jwilhelm Date: 2014-02-26 14:52 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3f406218c511 8035822: Unable to test minimalVM Summary: Moved the test code inside INCLUDE_ALL_GCS Reviewed-by: dholmes, stefank ! src/share/vm/prims/jni.cpp Changeset: 301df27023d4 Author: stefank Date: 2014-02-27 10:34 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/301df27023d4 8035648: Don't use Handle in java_lang_String::print Reviewed-by: coleenp, pliden ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/oops/instanceKlass.cpp Changeset: 7f0e0366ec81 Author: stefank Date: 2014-02-27 10:36 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7f0e0366ec81 8035746: Add missing Klass::oop_is_instanceClassLoader() function Reviewed-by: mgerdin, coleenp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/prims/jni.cpp Changeset: 7d30d4f37d31 Author: ehelin Date: 2014-02-28 14:56 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7d30d4f37d31 Merge ! src/share/vm/oops/instanceKlass.cpp Changeset: 5292439ef895 Author: kvn Date: 2014-02-24 15:12 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/5292439ef895 8033805: Move Fast_Lock/Fast_Unlock code from .ad files to macroassembler Summary: Consolidated C2 x86 locking code in one place in macroAssembler_x86.cpp. Reviewed-by: roland ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad Changeset: cd5d10655495 Author: rbackman Date: 2014-01-23 12:08 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/cd5d10655495 8027754: Enable loop optimizations for loops with MathExact inside Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! 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/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/vmStructs.cpp ! test/compiler/intrinsics/mathexact/AddExactICondTest.java ! test/compiler/intrinsics/mathexact/AddExactIConstantTest.java ! test/compiler/intrinsics/mathexact/AddExactILoadTest.java ! test/compiler/intrinsics/mathexact/AddExactILoopDependentTest.java ! test/compiler/intrinsics/mathexact/AddExactINonConstantTest.java ! test/compiler/intrinsics/mathexact/AddExactIRepeatTest.java ! test/compiler/intrinsics/mathexact/AddExactLConstantTest.java ! test/compiler/intrinsics/mathexact/AddExactLNonConstantTest.java ! test/compiler/intrinsics/mathexact/CompareTest.java ! test/compiler/intrinsics/mathexact/DecExactITest.java ! test/compiler/intrinsics/mathexact/DecExactLTest.java ! test/compiler/intrinsics/mathexact/GVNTest.java ! test/compiler/intrinsics/mathexact/IncExactITest.java ! test/compiler/intrinsics/mathexact/IncExactLTest.java ! test/compiler/intrinsics/mathexact/MulExactICondTest.java ! test/compiler/intrinsics/mathexact/MulExactIConstantTest.java ! test/compiler/intrinsics/mathexact/MulExactILoadTest.java ! test/compiler/intrinsics/mathexact/MulExactILoopDependentTest.java ! test/compiler/intrinsics/mathexact/MulExactINonConstantTest.java ! test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java ! test/compiler/intrinsics/mathexact/MulExactLConstantTest.java ! test/compiler/intrinsics/mathexact/MulExactLNonConstantTest.java ! test/compiler/intrinsics/mathexact/NegExactIConstantTest.java ! test/compiler/intrinsics/mathexact/NegExactILoadTest.java ! test/compiler/intrinsics/mathexact/NegExactILoopDependentTest.java ! test/compiler/intrinsics/mathexact/NegExactINonConstantTest.java ! test/compiler/intrinsics/mathexact/NegExactLConstantTest.java ! test/compiler/intrinsics/mathexact/NegExactLNonConstantTest.java ! test/compiler/intrinsics/mathexact/NestedMathExactTest.java ! test/compiler/intrinsics/mathexact/SplitThruPhiTest.java ! test/compiler/intrinsics/mathexact/SubExactICondTest.java ! test/compiler/intrinsics/mathexact/SubExactIConstantTest.java ! test/compiler/intrinsics/mathexact/SubExactILoadTest.java ! test/compiler/intrinsics/mathexact/SubExactILoopDependentTest.java ! test/compiler/intrinsics/mathexact/SubExactINonConstantTest.java ! test/compiler/intrinsics/mathexact/SubExactIRepeatTest.java ! test/compiler/intrinsics/mathexact/SubExactLConstantTest.java ! test/compiler/intrinsics/mathexact/SubExactLNonConstantTest.java ! test/compiler/intrinsics/mathexact/Verify.java ! test/compiler/intrinsics/mathexact/sanity/AddExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/AddExactLongTest.java ! test/compiler/intrinsics/mathexact/sanity/DecrementExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java ! test/compiler/intrinsics/mathexact/sanity/IncrementExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/IncrementExactLongTest.java ! test/compiler/intrinsics/mathexact/sanity/MultiplyExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/MultiplyExactLongTest.java ! test/compiler/intrinsics/mathexact/sanity/NegateExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/NegateExactLongTest.java ! test/compiler/intrinsics/mathexact/sanity/SubtractExactIntTest.java ! test/compiler/intrinsics/mathexact/sanity/SubtractExactLongTest.java Changeset: 99fc8c086679 Author: adlertz Date: 2014-02-25 10:26 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/99fc8c086679 8032894: Remove dead code in Pressure::lower Summary: Remove dead code in Pressure::lower Reviewed-by: kvn, roland ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/ifg.cpp Changeset: 9a83b7b3e37c Author: anoll Date: 2014-02-25 13:52 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9a83b7b3e37c 8034775: Failing to initialize VM when running with negative value for -XX:CICompilerCount Summary: Ensure appropriate min. number of compiler threads (1 for non-tiered, and 2 for tiered) Reviewed-by: kvn ! src/share/vm/runtime/arguments.cpp + test/compiler/startup/NumCompilerThreadsCheck.java Changeset: 04e7587c97dc Author: adlertz Date: 2014-02-25 14:09 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/04e7587c97dc 8032656: Tag the MachSpillCopies with purpose information Summary: Subclassed the MachSpillCopyNode with different subnodes for different spill purposes to enhance debugging / visualization Reviewed-by: kvn, roland ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/reg_split.cpp Changeset: 1077c8270209 Author: adlertz Date: 2014-02-25 17:51 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1077c8270209 8033260: assert(lrg._area >= 0.0) failed: negative spill area Summary: Change type from float to double on block frequency, and add check for +Inf - +Inf operation Reviewed-by: kvn, roland ! agent/src/share/classes/sun/jvm/hotspot/opto/Block.java ! src/share/vm/opto/block.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: fdad2932c73f Author: roland Date: 2014-02-25 18:16 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/fdad2932c73f 8031752: Failed speculative optimizations should be reattempted when root of compilation is different Summary: support for speculative traps that keep track of the root of the compilation in which a trap occurs. Reviewed-by: kvn, twisti ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/globals.hpp + test/compiler/uncommontrap/TestSpecTrapClassUnloading.java Changeset: f217a92ae194 Author: roland Date: 2014-02-25 10:42 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/f217a92ae194 Merge Changeset: 2757a106eaa8 Author: anoll Date: 2014-02-26 07:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2757a106eaa8 8032642: [TESTBUG] Fix testbugs in compiler/startup/.* Summary: Fixed issues with these tests Reviewed-by: kvn, twisti ! test/compiler/startup/SmallCodeCacheStartup.java ! test/compiler/startup/StartupOutput.java Changeset: 4e7ee57b57bf Author: adlertz Date: 2014-02-26 07:46 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4e7ee57b57bf 8010500: [parfait] Possible null pointer dereference at hotspot/src/share/vm/opto/loopnode.hpp Summary: Added NULL check for loopnode() in get_pre_loop_end() Reviewed-by: kvn, roland ! src/share/vm/opto/superword.cpp Changeset: 47f00f3b3900 Author: neliasso Date: 2014-02-11 13:29 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/47f00f3b3900 8034188: OSR methods may not be recompiled at proper compilation level Summary: remove_osr_nmethod doesn't check that it is the correct method Reviewed-by: kvn, iveresov ! src/share/vm/oops/instanceKlass.cpp Changeset: 524b54a7f1b5 Author: anoll Date: 2014-02-26 11:29 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/524b54a7f1b5 8034839: jvm hangs with gc/gctests/LoadUnloadGC test Summary: Provide fast lookup of checked dependencies via hashmap Reviewed-by: kvn, roland ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/dependencies.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: b3fe59626fdc Author: anoll Date: 2014-02-26 02:38 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/b3fe59626fdc Merge - agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java ! src/share/vm/code/nmethod.cpp - src/share/vm/utilities/dtrace_usdt2_disabled.hpp Changeset: fae50ee0308d Author: anoll Date: 2014-02-26 02:54 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/fae50ee0308d Merge Changeset: 78112be27ba0 Author: goetz Date: 2014-02-26 11:33 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/78112be27ba0 8035396: Introduce accessor for tmp_oop in frame. Summary: Avoid #ifs by introducing the accessor function interpreter_frame_temp_oop_addr(). Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/frame.inline.hpp Changeset: b3e1a903b6e8 Author: iveresov Date: 2014-02-26 16:45 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/b3e1a903b6e8 8035283: Second phase of branch shortening doesn't account for loop alignment Summary: added missing check for loop padding case. Reviewed-by: kvn, jrose ! src/share/vm/opto/output.cpp Changeset: 3df21373e577 Author: roland Date: 2014-02-27 09:37 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3df21373e577 8032011: nsk/stress/jck60/jck60022 crashes in src\share\vm\runtime\synchronizer.cpp:239 Summary: biased locking's revoke_bias locks monitor in compiled frame with eliminated lock Reviewed-by: kvn, iveresov ! src/share/vm/runtime/biasedLocking.cpp + test/compiler/uncommontrap/TestLockEliminatedAtDeopt.java Changeset: 7e8e4d1a41d6 Author: goetz Date: 2014-02-27 20:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7e8e4d1a41d6 8035970: PPC64: fix ad file after 8027754: Enable loop optimizations for loops with MathExact Reviewed-by: kvn ! src/cpu/ppc/vm/ppc.ad Changeset: 484a359ff649 Author: roland Date: 2014-02-28 13:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/484a359ff649 8031754: Type speculation should favor profile data from outermost inlined method Summary: favor profile data coming from outer most method Reviewed-by: kvn, twisti ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: 16c705d792be Author: morris Date: 2014-02-28 08:02 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/16c705d792be Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp Changeset: 2328dac1da27 Author: amurillo Date: 2014-02-28 09:30 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/2328dac1da27 Merge Changeset: 8a3c36abaf4b Author: katleman Date: 2014-02-21 11:39 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/8a3c36abaf4b Added tag jdk9-b03 for changeset b2fee789d23f ! .hgtags Changeset: 6e33e32e82e0 Author: lana Date: 2014-02-24 12:56 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/6e33e32e82e0 Merge - src/os/bsd/dtrace/hotspot.d - src/os/bsd/dtrace/hotspot_jni.d - src/os/bsd/dtrace/hs_private.d - src/os/solaris/dtrace/hotspot.d - src/os/solaris/dtrace/hotspot_jni.d - src/os/solaris/dtrace/hs_private.d Changeset: 3812c088b945 Author: lana Date: 2014-03-06 10:37 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/3812c088b945 Merge Changeset: d8041d695d19 Author: twisti Date: 2014-03-11 18:45 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d8041d695d19 Merged with jdk9/dev/hotspot changeset 3812c088b945 ! .hgtags + agent/src/share/classes/sun/jvm/hotspot/memory/AdaptiveFreeList.java - agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! make/Makefile ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/fastdebug.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/jsig.make + make/bsd/makefiles/mapfile-vers-darwin-debug + make/bsd/makefiles/mapfile-vers-darwin-product ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/top.make ! make/bsd/makefiles/vm.make ! make/defs.make ! make/linux/makefiles/adlc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/top.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/vm.make ! make/windows/build_vm_def.sh ! make/windows/makefiles/projectcreator.make ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/c1_globals_x86.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86.hpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vmStructs_x86.hpp - src/os/bsd/dtrace/hotspot.d - src/os/bsd/dtrace/hotspot_jni.d - src/os/bsd/dtrace/hs_private.d ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp + src/os/posix/dtrace/hotspot.d + src/os/posix/dtrace/hotspot_jni.d + src/os/posix/dtrace/hs_private.d - src/os/solaris/dtrace/hotspot.d - src/os/solaris/dtrace/hotspot_jni.d - src/os/solaris/dtrace/hs_private.d ! 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/tools/ProjectCreator/WinGammaPlatformVC10.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java ! src/share/tools/hsdis/README ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRGenerator.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.hpp ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciUtilities.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/dependencies.hpp ! src/share/vm/code/icBuffer.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/code/scopeDesc.hpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp ! 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_implementation/g1/vmStructs_g1.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/invocationCounter.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/constantPool.cpp ! 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.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2compiler.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.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/deoptimization.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/javaCalls.hpp ! 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/sharedRuntime.hpp ! src/share/vm/runtime/stubRoutines.hpp ! 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/timer.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/utilities/debug.hpp + src/share/vm/utilities/dtrace_disabled.hpp - src/share/vm/utilities/dtrace_usdt2_disabled.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/top.hpp ! src/share/vm/utilities/vmError.cpp Changeset: a0d1e2972a29 Author: Gilles Duboscq Date: 2014-03-11 11:00 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a0d1e2972a29 Windows make: use CXX_FLAGS instead of CPP_FLAGS for graal build ! make/windows/makefiles/vm.make Changeset: f84115370178 Author: Gilles Duboscq Date: 2014-03-11 15:34 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f84115370178 Javadoc fixes ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java Changeset: 29ccc4cbabca Author: Gilles Duboscq Date: 2014-03-12 13:30 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/29ccc4cbabca Merge - agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! make/bsd/makefiles/gcc.make - src/os/bsd/dtrace/hotspot.d - src/os/bsd/dtrace/hotspot_jni.d - src/os/bsd/dtrace/hs_private.d - src/os/solaris/dtrace/hotspot.d - src/os/solaris/dtrace/hotspot_jni.d - src/os/solaris/dtrace/hs_private.d ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/runtime/deoptimization.cpp - src/share/vm/utilities/dtrace_usdt2_disabled.hpp Changeset: 7c36ec150036 Author: Gilles Duboscq Date: 2014-03-13 15:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7c36ec150036 Make the DuplicateSuppressingStream periodically print while it is filtering output ! mxtool/mx.py Changeset: 5e55de0379d9 Author: Doug Simon Date: 2014-03-13 17:47 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5e55de0379d9 fixed bug in HotSpotResolvedJavaField.equals ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java Changeset: 10c4df6767c4 Author: Doug Simon Date: 2014-03-13 17:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/10c4df6767c4 removed GPU offload interaction with compilation policy ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotHostBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReplacementsImpl.java ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp Changeset: 469e04960daa Author: Doug Simon Date: 2014-03-13 17:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/469e04960daa added COMPILERGRAAL to predefined symbols in hotspot CDT project ! hotspot/.cproject Changeset: 4823ccaf5023 Author: Doug Simon Date: 2014-03-13 21:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4823ccaf5023 removed unnecessary LFLAGS adjustment for clang ! make/bsd/makefiles/gcc.make Changeset: 756029dab703 Author: Doug Simon Date: 2014-03-13 21:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/756029dab703 fixed regression due to jdk9 merge ! make/bsd/makefiles/top.make Changeset: 41ecd18552b2 Author: Doug Simon Date: 2014-03-13 21:16 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/41ecd18552b2 Merge. Changeset: 82c3b54d1f08 Author: twisti Date: 2014-03-12 15:12 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/82c3b54d1f08 added HotSpotConstantPool.JVM_CONSTANT enum ! 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 ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: d87b84dade7d Author: twisti Date: 2014-03-12 17:33 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d87b84dade7d moved CompilerToVM.loadReferencedTypeInPool logic into Java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotConstantPool.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 4c9f24b8f002 Author: twisti Date: 2014-03-13 13:38 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4c9f24b8f002 undo accidentially pushed make/Makefile changes ! make/Makefile From doug.simon at oracle.com Fri Mar 14 11:03:12 2014 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 14 Mar 2014 12:03:12 +0100 Subject: Possible bug in latest version of clang on Mac OS X In-Reply-To: <48654091-D15A-4790-8175-0255BCC669D3@oracle.com> References: <9D6A58F5-C407-4609-A26E-43DD86F0AD23@oracle.com> <264C27AB-0465-4B1E-90AA-1C697180C0CF@oracle.com> <2A5E686F-F0D9-43D2-9CCB-BE32FA59268A@oracle.com> <48654091-D15A-4790-8175-0255BCC669D3@oracle.com> Message-ID: <53741F47-B685-478D-BC89-2C5C21D13F53@oracle.com> Thanks to more investigation by Tom, it appears as though clang is legally omitting the null pointer check according to one way of interpreting (recent?) C++ specification around the value and type of NULL. For anyone interested, I took some of Tom?s example code and made it into a standalone program (attached) showing the issue: $ clang++ -O3 -o clang_omits_null_check clang_omits_null_check.cpp $ ./clang_omits_null_check 1. argc = 1 2. argc = 1 Illegal instruction: 4 Switching to -O0 to prevents the crash: $ clang++ -O0 -o clang_omits_null_check clang_omits_null_check.cpp $ ./clang_omits_null_check 1. argc = 1 2. argc = 1 3. argc = 1 The only hints found on the web about this behavior so far are: http://stackoverflow.com/questions/10153246/crashing-threads-with-intnull-1-problematic http://blog.qt.digia.com/blog/2011/06/10/type-punning-and-strict-aliasing/ -Doug -------------- next part -------------- On Mar 12, 2014, at 2:30 AM, Christian Thalinger wrote: > > On Mar 11, 2014, at 4:01 PM, Tom Rodriguez wrote: > >> So this is a known clang/llvm issue? Has it been reported? > > I don?t think so. At least I didn?t do it. > >> >> tom >> >> On Mar 11, 2014, at 3:14 PM, Christian Thalinger wrote: >> >>> Sigh. Meta-circular FTW! ;-) >>> >>> Did you add a new section like this: >>> >>> # 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 >>> OPT_CFLAGS/graalCompilerToVM.o += -O1 >>> endif >>> >>> for 5.1 in make/bsd/makefiles/gcc.make? >>> >>> On Mar 11, 2014, at 3:03 PM, Doug Simon wrote: >>> >>>> Since I have automatic updating enabled on my Mac, I was recently updated to the latest version of Xcode (5.1). I have just done my first recompile of HotSpot since this update and am seeing that clang appears to have a rather serious bug. In both disassembled functions below, the third parameter (%rdx) is a jobject that should be resolved via JNIHandles::resolve and then dereferenced *after* adding the fourth parameter (%rcx) to it. clang is inlining the call to JNIHandles::resolve but omitting the null check on the jobject value. >>>> >>>> If this is really a bug, I?m sure reports about it will start showing up soon. In the meantime, don?t update Xcode. >>>> >>>> -Doug >>>> >>>> >>>> _Unsafe_GetLong: >>>> 0000000000357e59 pushq %rbp >>>> 0000000000357e5a movq %rsp, %rbp >>>> 0000000000357e5d pushq %r15 >>>> 0000000000357e5f pushq %r14 >>>> 0000000000357e61 pushq %r12 >>>> 0000000000357e63 pushq %rbx >>>> 0000000000357e64 subq $0x10, %rsp >>>> 0000000000357e68 movq %rcx, %r14 >>>> 0000000000357e6b movq %rdx, %r15 >>>> 0000000000357e6e movq %rdi, %rbx >>>> 0000000000357e71 movl 0x90(%rbx), %eax >>>> 0000000000357e77 addq $-0x1f0, %rbx >>>> 0000000000357e7e cmpl $0xdeab, %eax >>>> 0000000000357e83 je 0x357e9c >>>> 0000000000357e85 movl 0x280(%rbx), %eax >>>> 0000000000357e8b cmpl $0xdeac, %eax >>>> 0000000000357e90 je 0x357e9c >>>> 0000000000357e92 movq %rbx, %rdi >>>> 0000000000357e95 callq __ZN10JavaThread18block_if_vm_exitedEv >>>> 0000000000357e9a xorl %ebx, %ebx >>>> 0000000000357e9c leaq -0x28(%rbp), %r12 >>>> 0000000000357ea0 movq %r12, %rdi >>>> 0000000000357ea3 movq %rbx, %rsi >>>> 0000000000357ea6 callq __ZN20ThreadInVMfromNativeC1EP10JavaThread >>>> 0000000000357eab movq %rbx, -0x30(%rbp) >>>> 0000000000357eaf movq (%r15), %rax >>>> 0000000000357eb2 movq (%rax,%r14), %rbx >>>> 0000000000357eb6 leaq -0x30(%rbp), %rdi >>>> 0000000000357eba callq __ZN17HandleMarkCleanerD1Ev >>>> 0000000000357ebf movq %r12, %rdi >>>> 0000000000357ec2 callq __ZN20ThreadInVMfromNativeD1Ev >>>> 0000000000357ec7 movq %rbx, %rax >>>> 0000000000357eca addq $0x10, %rsp >>>> 0000000000357ece popq %rbx >>>> 0000000000357ecf popq %r12 >>>> 0000000000357ed1 popq %r14 >>>> 0000000000357ed3 popq %r15 >>>> 0000000000357ed5 popq %rbp >>>> 0000000000357ed6 ret >>>> >>>> __Z33c2v_readUnsafeUncompressedPointerP7JNIEnv_P8_jobjectS2_l: >>>> 000000000016e261 pushq %rbp >>>> 000000000016e262 movq %rsp, %rbp >>>> 000000000016e265 pushq %r15 >>>> 000000000016e267 pushq %r14 >>>> 000000000016e269 pushq %r12 >>>> 000000000016e26b pushq %rbx >>>> 000000000016e26c subq $0x10, %rsp >>>> 000000000016e270 movq %rcx, %r14 >>>> 000000000016e273 movq %rdx, %r15 >>>> 000000000016e276 leaq _TraceGraal(%rip), %rax >>>> 000000000016e27d cmpq $0x3, (%rax) >>>> 000000000016e281 jl 0x16e2ac >>>> 000000000016e283 leaq _tty(%rip), %rbx >>>> 000000000016e28a movq (%rbx), %rdi >>>> 000000000016e28d leaq 0x23de25(%rip), %rsi ## literal pool for: " TraceGraal-3: " >>>> 000000000016e294 xorl %eax, %eax >>>> 000000000016e296 callq __ZN12outputStream5printEPKcz >>>> 000000000016e29b movq (%rbx), %rdi >>>> 000000000016e29e leaq 0x23ef0f(%rip), %rsi ## literal pool for: "CompilerToVM::readUnsafeUncompressedPointer" >>>> 000000000016e2a5 xorl %eax, %eax >>>> 000000000016e2a7 callq __ZN12outputStream8print_crEPKcz >>>> 000000000016e2ac leaq __ZN18ThreadLocalStorage13_thread_indexE(%rip), %rax >>>> 000000000016e2b3 movslq (%rax), %rdi >>>> 000000000016e2b6 callq 0x38a758 ## symbol stub for: _pthread_getspecific >>>> 000000000016e2bb movq %rax, %rbx >>>> 000000000016e2be leaq -0x28(%rbp), %r12 >>>> 000000000016e2c2 movq %r12, %rdi >>>> 000000000016e2c5 movq %rbx, %rsi >>>> 000000000016e2c8 callq __ZN20ThreadInVMfromNativeC1EP10JavaThread >>>> 000000000016e2cd movq %rbx, -0x30(%rbp) >>>> 000000000016e2d1 movq (%r15), %rax >>>> 000000000016e2d4 movq (%rax,%r14), %rdi >>>> 000000000016e2d8 callq __ZN10JNIHandles10make_localEP7oopDesc >>>> 000000000016e2dd movq %rax, %rbx >>>> 000000000016e2e0 leaq -0x30(%rbp), %rdi >>>> 000000000016e2e4 callq __ZN17HandleMarkCleanerD1Ev >>>> 000000000016e2e9 movq %r12, %rdi >>>> 000000000016e2ec callq __ZN20ThreadInVMfromNativeD1Ev >>>> 000000000016e2f1 movq %rbx, %rax >>>> 000000000016e2f4 addq $0x10, %rsp >>>> 000000000016e2f8 popq %rbx >>>> 000000000016e2f9 popq %r12 >>>> 000000000016e2fb popq %r14 >>>> 000000000016e2fd popq %r15 >>>> 000000000016e2ff popq %rbp >>>> 000000000016e300 ret >>>> >>>> >>> >> > From doug.simon at oracle.com Fri Mar 14 11:11:38 2014 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 14 Mar 2014 12:11:38 +0100 Subject: Possible bug in latest version of clang on Mac OS X In-Reply-To: <48654091-D15A-4790-8175-0255BCC669D3@oracle.com> References: <9D6A58F5-C407-4609-A26E-43DD86F0AD23@oracle.com> <264C27AB-0465-4B1E-90AA-1C697180C0CF@oracle.com> <2A5E686F-F0D9-43D2-9CCB-BE32FA59268A@oracle.com> <48654091-D15A-4790-8175-0255BCC669D3@oracle.com> Message-ID: <52FFDC19-370D-449A-8C09-19D6635094F9@oracle.com> (sending again with attachment inline) Thanks to more investigation by Tom, it appears as though clang is legally omitting the null pointer check according to one way of interpreting (recent?) C++ specification around the value and type of NULL. For anyone interested, I took some of Tom?s example code and made it into a standalone program (below) showing the issue: $ clang++ -O3 -o clang_omits_null_check clang_omits_null_check.cpp $ ./clang_omits_null_check 1. argc = 1 2. argc = 1 Illegal instruction: 4 Switching to -O0 to prevents the crash: $ clang++ -O0 -o clang_omits_null_check clang_omits_null_check.cpp $ ./clang_omits_null_check 1. argc = 1 2. argc = 1 3. argc = 1 The only hints found on the web about this behavior so far are: http://stackoverflow.com/questions/10153246/crashing-threads-with-intnull-1-problematic http://blog.qt.digia.com/blog/2011/06/10/type-punning-and-strict-aliasing/ ===== clang_omits_null_check.cpp ==== #include #include static char read1(char* handle, long offset) { char* obj = handle == NULL ? NULL : *(char**) handle; return *(char*)((intptr_t)obj + offset); } static char read2(char* handle, long offset) { char* obj = handle == NULL ? NULL : *(char**) handle; // Without the cast to intptr_t, this crashes since // the compiler dereferences handle first and then // adds offset to it. return *(char*)( obj + offset); } int main(int argc, char** argv) { int* argcAddr = &argc; printf("1. argc = %d\n", argc); printf("2. argc = %d\n", read1(NULL, (long) argcAddr)); printf("3. argc = %d\n", read2(NULL, (long) argcAddr)); } ===================================== -Doug On Mar 12, 2014, at 2:30 AM, Christian Thalinger wrote: > > On Mar 11, 2014, at 4:01 PM, Tom Rodriguez wrote: > >> So this is a known clang/llvm issue? Has it been reported? > > I don?t think so. At least I didn?t do it. > >> >> tom >> >> On Mar 11, 2014, at 3:14 PM, Christian Thalinger wrote: >> >>> Sigh. Meta-circular FTW! ;-) >>> >>> Did you add a new section like this: >>> >>> # 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 >>> OPT_CFLAGS/graalCompilerToVM.o += -O1 >>> endif >>> >>> for 5.1 in make/bsd/makefiles/gcc.make? >>> >>> On Mar 11, 2014, at 3:03 PM, Doug Simon wrote: >>> >>>> Since I have automatic updating enabled on my Mac, I was recently updated to the latest version of Xcode (5.1). I have just done my first recompile of HotSpot since this update and am seeing that clang appears to have a rather serious bug. In both disassembled functions below, the third parameter (%rdx) is a jobject that should be resolved via JNIHandles::resolve and then dereferenced *after* adding the fourth parameter (%rcx) to it. clang is inlining the call to JNIHandles::resolve but omitting the null check on the jobject value. >>>> >>>> If this is really a bug, I?m sure reports about it will start showing up soon. In the meantime, don?t update Xcode. >>>> >>>> -Doug >>>> >>>> >>>> _Unsafe_GetLong: >>>> 0000000000357e59 pushq %rbp >>>> 0000000000357e5a movq %rsp, %rbp >>>> 0000000000357e5d pushq %r15 >>>> 0000000000357e5f pushq %r14 >>>> 0000000000357e61 pushq %r12 >>>> 0000000000357e63 pushq %rbx >>>> 0000000000357e64 subq $0x10, %rsp >>>> 0000000000357e68 movq %rcx, %r14 >>>> 0000000000357e6b movq %rdx, %r15 >>>> 0000000000357e6e movq %rdi, %rbx >>>> 0000000000357e71 movl 0x90(%rbx), %eax >>>> 0000000000357e77 addq $-0x1f0, %rbx >>>> 0000000000357e7e cmpl $0xdeab, %eax >>>> 0000000000357e83 je 0x357e9c >>>> 0000000000357e85 movl 0x280(%rbx), %eax >>>> 0000000000357e8b cmpl $0xdeac, %eax >>>> 0000000000357e90 je 0x357e9c >>>> 0000000000357e92 movq %rbx, %rdi >>>> 0000000000357e95 callq __ZN10JavaThread18block_if_vm_exitedEv >>>> 0000000000357e9a xorl %ebx, %ebx >>>> 0000000000357e9c leaq -0x28(%rbp), %r12 >>>> 0000000000357ea0 movq %r12, %rdi >>>> 0000000000357ea3 movq %rbx, %rsi >>>> 0000000000357ea6 callq __ZN20ThreadInVMfromNativeC1EP10JavaThread >>>> 0000000000357eab movq %rbx, -0x30(%rbp) >>>> 0000000000357eaf movq (%r15), %rax >>>> 0000000000357eb2 movq (%rax,%r14), %rbx >>>> 0000000000357eb6 leaq -0x30(%rbp), %rdi >>>> 0000000000357eba callq __ZN17HandleMarkCleanerD1Ev >>>> 0000000000357ebf movq %r12, %rdi >>>> 0000000000357ec2 callq __ZN20ThreadInVMfromNativeD1Ev >>>> 0000000000357ec7 movq %rbx, %rax >>>> 0000000000357eca addq $0x10, %rsp >>>> 0000000000357ece popq %rbx >>>> 0000000000357ecf popq %r12 >>>> 0000000000357ed1 popq %r14 >>>> 0000000000357ed3 popq %r15 >>>> 0000000000357ed5 popq %rbp >>>> 0000000000357ed6 ret >>>> >>>> __Z33c2v_readUnsafeUncompressedPointerP7JNIEnv_P8_jobjectS2_l: >>>> 000000000016e261 pushq %rbp >>>> 000000000016e262 movq %rsp, %rbp >>>> 000000000016e265 pushq %r15 >>>> 000000000016e267 pushq %r14 >>>> 000000000016e269 pushq %r12 >>>> 000000000016e26b pushq %rbx >>>> 000000000016e26c subq $0x10, %rsp >>>> 000000000016e270 movq %rcx, %r14 >>>> 000000000016e273 movq %rdx, %r15 >>>> 000000000016e276 leaq _TraceGraal(%rip), %rax >>>> 000000000016e27d cmpq $0x3, (%rax) >>>> 000000000016e281 jl 0x16e2ac >>>> 000000000016e283 leaq _tty(%rip), %rbx >>>> 000000000016e28a movq (%rbx), %rdi >>>> 000000000016e28d leaq 0x23de25(%rip), %rsi ## literal pool for: " TraceGraal-3: " >>>> 000000000016e294 xorl %eax, %eax >>>> 000000000016e296 callq __ZN12outputStream5printEPKcz >>>> 000000000016e29b movq (%rbx), %rdi >>>> 000000000016e29e leaq 0x23ef0f(%rip), %rsi ## literal pool for: "CompilerToVM::readUnsafeUncompressedPointer" >>>> 000000000016e2a5 xorl %eax, %eax >>>> 000000000016e2a7 callq __ZN12outputStream8print_crEPKcz >>>> 000000000016e2ac leaq __ZN18ThreadLocalStorage13_thread_indexE(%rip), %rax >>>> 000000000016e2b3 movslq (%rax), %rdi >>>> 000000000016e2b6 callq 0x38a758 ## symbol stub for: _pthread_getspecific >>>> 000000000016e2bb movq %rax, %rbx >>>> 000000000016e2be leaq -0x28(%rbp), %r12 >>>> 000000000016e2c2 movq %r12, %rdi >>>> 000000000016e2c5 movq %rbx, %rsi >>>> 000000000016e2c8 callq __ZN20ThreadInVMfromNativeC1EP10JavaThread >>>> 000000000016e2cd movq %rbx, -0x30(%rbp) >>>> 000000000016e2d1 movq (%r15), %rax >>>> 000000000016e2d4 movq (%rax,%r14), %rdi >>>> 000000000016e2d8 callq __ZN10JNIHandles10make_localEP7oopDesc >>>> 000000000016e2dd movq %rax, %rbx >>>> 000000000016e2e0 leaq -0x30(%rbp), %rdi >>>> 000000000016e2e4 callq __ZN17HandleMarkCleanerD1Ev >>>> 000000000016e2e9 movq %r12, %rdi >>>> 000000000016e2ec callq __ZN20ThreadInVMfromNativeD1Ev >>>> 000000000016e2f1 movq %rbx, %rax >>>> 000000000016e2f4 addq $0x10, %rsp >>>> 000000000016e2f8 popq %rbx >>>> 000000000016e2f9 popq %r12 >>>> 000000000016e2fb popq %r14 >>>> 000000000016e2fd popq %r15 >>>> 000000000016e2ff popq %rbp >>>> 000000000016e300 ret >>>> >>>> >>> >> > From doug.simon at oracle.com Sat Mar 15 02:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 15 Mar 2014 02:00:07 +0000 Subject: hg: graal/graal: 15 new changesets Message-ID: <201403150200.s2F20QYs021808@aojmv0008> Changeset: a300322b782b Author: Lukas Stadler Date: 2014-03-14 08:28 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a300322b782b fix for IfNode reordering ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java Changeset: e5235120893c Author: Lukas Stadler Date: 2014-03-14 10:21 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e5235120893c split BciBlockMapping liveness calculation into fast and slow path ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/FrameStateBuilder.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: ccf090d3be47 Author: Lukas Stadler Date: 2014-03-14 10:22 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ccf090d3be47 new graph ordering assertion mechanism ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/util/GraphOrder.java Changeset: 2298f22a7b28 Author: Lukas Stadler Date: 2014-03-14 11:17 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2298f22a7b28 tiny change to DebugInfoBuilder ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/DebugInfoBuilder.java Changeset: b3937b8b9ae1 Author: Lukas Stadler Date: 2014-03-14 10:22 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b3937b8b9ae1 tiny change in FrameStateAssignmentPhase ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FrameStateAssignmentPhase.java Changeset: 360beb9b3c50 Author: Lukas Stadler Date: 2014-03-14 10:22 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/360beb9b3c50 let NodeIterable.snapshotTo take collections instead of lists ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeList.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/iterators/AbstractNodeIterable.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/iterators/NodeIterable.java Changeset: 5454f6bf50bf Author: Christian Wirth Date: 2014-03-12 11:23 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5454f6bf50bf fix for mx, did not compile on Windows ! mxtool/mx.py Changeset: 47b775458982 Author: Christian Wirth Date: 2014-03-14 09:58 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/47b775458982 Merged - agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotGraphCache.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/GraphCache.java ! mxtool/mx.py - src/os/bsd/dtrace/hotspot.d - src/os/bsd/dtrace/hotspot_jni.d - src/os/bsd/dtrace/hs_private.d - src/os/solaris/dtrace/hotspot.d - src/os/solaris/dtrace/hotspot_jni.d - src/os/solaris/dtrace/hs_private.d - src/share/vm/utilities/dtrace_usdt2_disabled.hpp Changeset: f659d019d3ab Author: Christian Wirth Date: 2014-03-14 15:29 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f659d019d3ab Merged Changeset: 145b31ba9a57 Author: Bernhard Urban Date: 2014-03-14 15:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/145b31ba9a57 SnippetTemplate: don't use dummy node for replace ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 084603b0bfbb Author: Bernhard Urban Date: 2014-03-14 18:10 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/084603b0bfbb CheckGraalInvariants: catch BailoutException ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/CheckGraalInvariants.java Changeset: 12eaf1a47a90 Author: Doug Simon Date: 2014-03-14 22:05 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/12eaf1a47a90 removed ResolvedJavaMethod.getCompilerStorage(); moved last compiled graph node count into profiling info (i.e. MethodData metadata) ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/DefaultProfilingInfo.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ProfilingInfo.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaMethod.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodData.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotNmethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotProfilingInfo.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! src/share/vm/graal/vmStructs_graal.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp Changeset: 8c306609eb68 Author: Doug Simon Date: 2014-03-14 22:09 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8c306609eb68 modified HotSpotResolvedJavaMethod.getCompiledCodeSize() to only return Graal compiled code size ! 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: 4877b0cb446f Author: Doug Simon Date: 2014-03-14 22:56 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4877b0cb446f removed ResolvedJavaMethod.getCompiledCodeSize() ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaMethod.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationStatistics.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 942c4daa9db9 Author: Doug Simon Date: 2014-03-15 01:42 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/942c4daa9db9 added findbugs command to mx + graal/findbugsExcludeFilter.xml ! mx/mx_graal.py ! mx/projects From doug.simon at oracle.com Sun Mar 16 02:00:05 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 16 Mar 2014 02:00:05 +0000 Subject: hg: graal/graal: fixed some findbugs issues Message-ID: <201403160200.s2G207fV015202@aojmv0008> Changeset: 0d5923064a88 Author: Doug Simon Date: 2014-03-15 10:28 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0d5923064a88 fixed some findbugs issues ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierVerificationPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/util/GraphOrder.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/codewriter/AbstractCodeWriter.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java From D.Sturm42 at gmail.com Sun Mar 16 13:19:38 2014 From: D.Sturm42 at gmail.com (D.Sturm) Date: Sun, 16 Mar 2014 14:19:38 +0100 Subject: Tail Calls Message-ID: I was trying to write a testcase for the aarch64 backend for tail recursion, but I can't seem to get Graal to generate the code for it. I tried it with the following, but that just causes a normal static call: public static int tailCallTest(int n, int total) { if (n == 0) return total; return tailCallTest(n - 1, total + 1); } any ideas? -- Daniel From duboscq at ssw.jku.at Sun Mar 16 15:14:22 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Sun, 16 Mar 2014 16:14:22 +0100 Subject: Tail Calls In-Reply-To: References: Message-ID: Hello, I suppose you mean that you expect Graal to transform that code snippet into a loop? There is currently no tail recursion optimization in Graal. -Gilles On 16 Mar 2014 14:21, "D.Sturm" wrote: > I was trying to write a testcase for the aarch64 backend for tail > recursion, but I can't seem to get Graal to generate the code for it. I > tried it with the following, but that just causes a normal static call: > > public static int tailCallTest(int n, int total) { > if (n == 0) return total; > return tailCallTest(n - 1, total + 1); > } > > any ideas? > > -- Daniel > From D.Sturm42 at gmail.com Sun Mar 16 15:24:16 2014 From: D.Sturm42 at gmail.com (D.Sturm) Date: Sun, 16 Mar 2014 16:24:16 +0100 Subject: Tail Calls In-Reply-To: References: Message-ID: There is a TailCallNode in hotspot.nodes and the HotSpotLIRGenerator has an emitTailcall function, that's why I asked. So is the reason for this just to make int foo() { // code. return bar(); } a bit more efficient by avoiding the need for the second return op and letting bar jump back to foo's caller directly? -- Daniel On 16 March 2014 16:14, Gilles Duboscq wrote: > Hello, > > I suppose you mean that you expect Graal to transform that code snippet > into a loop? > There is currently no tail recursion optimization in Graal. > > -Gilles > On 16 Mar 2014 14:21, "D.Sturm" wrote: > >> I was trying to write a testcase for the aarch64 backend for tail >> recursion, but I can't seem to get Graal to generate the code for it. I >> tried it with the following, but that just causes a normal static call: >> >> public static int tailCallTest(int n, int total) { >> if (n == 0) return total; >> return tailCallTest(n - 1, total + 1); >> } >> >> any ideas? >> >> -- Daniel >> > From duboscq at ssw.jku.at Sun Mar 16 15:31:11 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Sun, 16 Mar 2014 16:31:11 +0100 Subject: Tail Calls In-Reply-To: References: Message-ID: Yes sorry, I should have read the email subject rather than concentrating on the example. There is also no tail calls optimization. This node was used for manually constructed graphs. I'm not even sure it is still used anywhere. -Gilles On 16 Mar 2014 16:24, "D.Sturm" wrote: > There is a TailCallNode in hotspot.nodes and the HotSpotLIRGenerator has > an emitTailcall function, that's why I asked. So is the reason for this > just to make > > int foo() { > // code. > return bar(); > } > > a bit more efficient by avoiding the need for the second return op and > letting bar jump back to foo's caller directly? > > -- Daniel > > On 16 March 2014 16:14, Gilles Duboscq wrote: > >> Hello, >> >> I suppose you mean that you expect Graal to transform that code snippet >> into a loop? >> There is currently no tail recursion optimization in Graal. >> >> -Gilles >> On 16 Mar 2014 14:21, "D.Sturm" wrote: >> >>> I was trying to write a testcase for the aarch64 backend for tail >>> recursion, but I can't seem to get Graal to generate the code for it. I >>> tried it with the following, but that just causes a normal static call: >>> >>> public static int tailCallTest(int n, int total) { >>> if (n == 0) return total; >>> return tailCallTest(n - 1, total + 1); >>> } >>> >>> any ideas? >>> >>> -- Daniel >>> >> > From D.Sturm42 at gmail.com Sun Mar 16 15:41:04 2014 From: D.Sturm42 at gmail.com (D.Sturm) Date: Sun, 16 Mar 2014 16:41:04 +0100 Subject: Tail Calls In-Reply-To: References: Message-ID: My fault for not being clearer. Thanks for the answer, I guess I'll just throw a not implemented exception for now and worry about testing the code when I run into an actual use case. --Daniel On 16 Mar 2014 16:31, "Gilles Duboscq" wrote: > Yes sorry, I should have read the email subject rather than concentrating > on the example. > > There is also no tail calls optimization. > > This node was used for manually constructed graphs. I'm not even sure it > is still used anywhere. > > -Gilles > On 16 Mar 2014 16:24, "D.Sturm" wrote: > >> There is a TailCallNode in hotspot.nodes and the HotSpotLIRGenerator has >> an emitTailcall function, that's why I asked. So is the reason for this >> just to make >> >> int foo() { >> // code. >> return bar(); >> } >> >> a bit more efficient by avoiding the need for the second return op and >> letting bar jump back to foo's caller directly? >> >> -- Daniel >> >> On 16 March 2014 16:14, Gilles Duboscq wrote: >> >>> Hello, >>> >>> I suppose you mean that you expect Graal to transform that code snippet >>> into a loop? >>> There is currently no tail recursion optimization in Graal. >>> >>> -Gilles >>> On 16 Mar 2014 14:21, "D.Sturm" wrote: >>> >>>> I was trying to write a testcase for the aarch64 backend for tail >>>> recursion, but I can't seem to get Graal to generate the code for it. I >>>> tried it with the following, but that just causes a normal static call: >>>> >>>> public static int tailCallTest(int n, int total) { >>>> if (n == 0) return total; >>>> return tailCallTest(n - 1, total + 1); >>>> } >>>> >>>> any ideas? >>>> >>>> -- Daniel >>>> >>> >> From duboscq at ssw.jku.at Sun Mar 16 18:51:12 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Sun, 16 Mar 2014 19:51:12 +0100 Subject: nextLastFixed == null in LoweringPhase.process In-Reply-To: References: Message-ID: Hello Tom, I think the problem is on our side, it should be possible to do what you describe. In this case, the first branch should detect that what comes after the just-lowered node is gone (nextNdoe should not be alive). I tried some modifications to the snippet instantiation which may help you, they've just gone through the gate and should be available on openjdk in the next push (which should happen this night). In particular the changes in e1a2302a42bc could help. Let me know if it worked. -Gilles On Thu, Mar 13, 2014 at 7:17 PM, Tom Deneau wrote: > Question from a newbie snippet writer... > > I have a snippet (for NewInstanceNode replacement) that is calling Deoptimize.deopt conditionally but in the particular simple test case I am running it will generate code that unconditionally takes the deopt path. > > When I get to this part of the code (LoweringPhase.process) after the replacement of the snippet into the graph, nextLastFixed is null, so we hit a nullPointerException. Does this mean there is something wrong with my snippet or should there be some logic in here to handle the case where nextLastFixed == null? > > -- Tom > > > if (!nextNode.isAlive()) { > // can happen when the rest of the block is killed by lowering > // (e.g. by an unconditional deopt) > break; > } else { > Node nextLastFixed = nextNode.predecessor(); > if (!(nextLastFixed instanceof FixedWithNextNode)) { > // insert begin node, to have a valid last fixed for next lowerable node. > // This is about lowering a FixedWithNextNode to a control split while this > // FixedWithNextNode is followed by some kind of BeginNode. > // For example the when a FixedGuard followed by a loop exit is lowered to a > // control-split + deopt. > BeginNode begin = node.graph().add(new BeginNode()); > nextLastFixed.replaceFirstSuccessor(nextNode, begin); > begin.setNext(nextNode); > nextLastFixed = begin; > } > loweringTool.setLastFixedNode((FixedWithNextNode) nextLastFixed); > } > From jules_gosnell at yahoo.com Sun Mar 16 23:35:41 2014 From: jules_gosnell at yahoo.com (Jules Gosnell) Date: Sun, 16 Mar 2014 23:35:41 +0000 Subject: Graal and Clojure In-Reply-To: References: <1394063789.8387.YahooMailNeo@web122406.mail.ne1.yahoo.com> Message-ID: <5326354D.8010204@yahoo.com> Doug, Sorry it has taken me a while to get back - I've been busy playing with code. I currently have a small clojure testsuite up and running. I plan to broaden this and then think about providing it in a junit-compatible way to your project. I still haven't made up my mind exactly what I should be testing. It seems unnecessary to duplicate all your tests in Clojure, since you are already guarding against regression in these areas - I think I will start out with a fairly general set of tests as I probe for particular problem areas for Clojure, into which I may dive for more detail - time will tell... if you have any ideas, please let me know. I've checked my stuff in at github, if anyone is interested - here is the project: https://github.com/JulesGosnell/clumatra here is some clojure that I reverse engineered from GraalKernelTester: https://github.com/JulesGosnell/clumatra/blob/master/src/clumatra/core.clj and here are the first successful tests: https://github.com/JulesGosnell/clumatra/blob/master/test/clumatra/core_test.clj not very pretty yet - I am still feeling my way. cheers Jules On 06/03/14 10:24, Doug Simon wrote: > Hi Julian, > > This looks very interesting and will be an good alternative testing vector for the Sumatra work as it matures. If Clojure tests can somehow be made to run from Junit, then I?m sure we can try integrating it into our testing. > > -Doug > > On Mar 6, 2014, at 12:56 AM, Julian Gosnell wrote: > >> Guys, >> >> I just built the Java8 / Graal / Okra stack and managed to run some very simple Clojure copying the contents of one int array into another one on Okra. >> >> https://groups.google.com/forum/#!topic/clojure/JpjK__NTR5Y >> >> >> I find the ramifications of this very exciting :-) >> >> I understand that fn-ality is limited at the moment - but I am keen to keep testing and to help ensure early visibility of Clojure related issues to both communities - perhaps even the submission of a Clojure testsuite if Graal developers thought that useful. >> >> I'd be very interested in your thoughts on Graal / Clojure. >> >> regards, >> >> >> Jules >> > > From doug.simon at oracle.com Mon Mar 17 02:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Mon, 17 Mar 2014 02:00:06 +0000 Subject: hg: graal/graal: 6 new changesets Message-ID: <201403170200.s2H20FpO005031@aojmv0008> Changeset: e1a2302a42bc Author: Gilles Duboscq Date: 2014-03-14 18:11 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e1a2302a42bc Improve cleanup during snippet lowering where the snippet never returns normally (unwind, deopt...) ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 36d39c597c79 Author: Gilles Duboscq Date: 2014-03-16 19:19 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/36d39c597c79 Respect CIPrintCompilerName and output a timestamp in Graal's PrintCompilation implementation ! 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/HotSpotVMConfig.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: b6aa8c4972aa Author: Gilles Duboscq Date: 2014-03-16 18:36 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b6aa8c4972aa Use CIPrintCompilerName in nmethod::print_on ! src/share/vm/code/nmethod.cpp Changeset: bf7d914b8ef7 Author: Gilles Duboscq Date: 2014-03-16 18:46 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bf7d914b8ef7 Print compilation level in Graal's PrintCompilation output ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java Changeset: 2c78ee2a890f Author: Gilles Duboscq Date: 2014-03-16 18:52 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2c78ee2a890f Graal PrintCompilation: print exception handlers and blocking flags ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java Changeset: 6fb61ad67962 Author: Gilles Duboscq Date: 2014-03-16 19:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6fb61ad67962 Fix mx eclipseformat always adds the 'eclipse' suffix ! mxtool/mx.py From doug.simon at oracle.com Mon Mar 17 10:43:10 2014 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 17 Mar 2014 11:43:10 +0100 Subject: Graal and Clojure In-Reply-To: <5326354D.8010204@yahoo.com> References: <1394063789.8387.YahooMailNeo@web122406.mail.ne1.yahoo.com> <5326354D.8010204@yahoo.com> Message-ID: Hi Julian, In terms of what to test, I?ll leave it up to the Sumatra developers at AMD and Oracle to comment on what may be interesting. As far as I know, no one in the Graal team is that familiar with Clojure. This actually makes the value of having Clojure tests integrated into our gate system somewhat problematic - debugging/fixing failures may be difficult. I?d suggest you report failures your discover on the sumatra-dev and graal-dev lists and we can resolve them that way for now. In addition, for Graal we?re always interested in benchmark suites for JVM hosted languages. Can you recommend any well known and trusted Clojure benchmarks we should consider? -Doug On Mar 17, 2014, at 12:35 AM, Jules Gosnell wrote: > Doug, > > Sorry it has taken me a while to get back - I've been busy playing with code. > > I currently have a small clojure testsuite up and running. I plan to broaden this and then think about providing it in a junit-compatible way to your project. > > I still haven't made up my mind exactly what I should be testing. It seems unnecessary to duplicate all your tests in Clojure, since you are already guarding against regression in these areas - I think I will start out with a fairly general set of tests as I probe for particular problem areas for Clojure, into which I may dive for more detail - time will tell... if you have any ideas, please let me know. > > I've checked my stuff in at github, if anyone is interested - here is the project: > > https://github.com/JulesGosnell/clumatra > > here is some clojure that I reverse engineered from GraalKernelTester: > > https://github.com/JulesGosnell/clumatra/blob/master/src/clumatra/core.clj > > and here are the first successful tests: > > https://github.com/JulesGosnell/clumatra/blob/master/test/clumatra/core_test.clj > > not very pretty yet - I am still feeling my way. > > cheers > > > Jules > > > > > On 06/03/14 10:24, Doug Simon wrote: >> Hi Julian, >> >> This looks very interesting and will be an good alternative testing vector for the Sumatra work as it matures. If Clojure tests can somehow be made to run from Junit, then I?m sure we can try integrating it into our testing. >> >> -Doug >> >> On Mar 6, 2014, at 12:56 AM, Julian Gosnell wrote: >> >>> Guys, >>> >>> I just built the Java8 / Graal / Okra stack and managed to run some very simple Clojure copying the contents of one int array into another one on Okra. >>> >>> https://groups.google.com/forum/#!topic/clojure/JpjK__NTR5Y >>> >>> >>> I find the ramifications of this very exciting :-) >>> >>> I understand that fn-ality is limited at the moment - but I am keen to keep testing and to help ensure early visibility of Clojure related issues to both communities - perhaps even the submission of a Clojure testsuite if Graal developers thought that useful. >>> >>> I'd be very interested in your thoughts on Graal / Clojure. >>> >>> regards, >>> >>> >>> Jules >>> >> >> > From thomas.wuerthinger at oracle.com Mon Mar 17 13:34:36 2014 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Mon, 17 Mar 2014 14:34:36 +0100 Subject: Result: New graal Committer: Bernhard Urban Message-ID: <59341AC6-26E2-417C-BCA5-57548D3F6BF8@oracle.com> Voting for Bernhard Urban [1] is now closed. Yes: 7 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thomas Wuerthinger [1] http://mail.openjdk.java.net/pipermail/graal-dev/2014-January/001398.html From thomas.wuerthinger at oracle.com Mon Mar 17 13:47:03 2014 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Mon, 17 Mar 2014 14:47:03 +0100 Subject: CFV: New Graal Committer: Tom Rodriguez Message-ID: <2E90E983-70F3-4B1B-9664-3A6A1B865A5B@oracle.com> I hereby nominate Tom Rodriguez to Graal committer. Tom has already made 79 contributions to Graal [1]. Most notably, he has contributed support for allocation prefetching [2] and the ability to run Graal in tiered mode in combination with C1 [3]. Tom is a compiler expert, long-term contributor to both compilers of the HotSpot VM, member of the HotSpot Group as well as member of the OpenJDK Members Group. Votes are due March 31, 4:00 pm CET. Only current Graal committers are eligible to vote on this nomination [4]. For Lazy Consensus voting instructions, see [5]. - thomas [1] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/search/?rev=tom%20rodriguez&revcount=80 [2] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/785bbb619238?revcount=80 [3] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/800057208a2c?revcount=80 [4] http://openjdk.java.net/census#graal [5] http://openjdk.java.net/projects/#committer-vote From doug.simon at oracle.com Mon Mar 17 13:44:59 2014 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 17 Mar 2014 14:44:59 +0100 Subject: CFV: New Graal Committer: Tom Rodriguez In-Reply-To: <2E90E983-70F3-4B1B-9664-3A6A1B865A5B@oracle.com> References: <2E90E983-70F3-4B1B-9664-3A6A1B865A5B@oracle.com> Message-ID: <5C8A8313-C703-4892-9766-135A3338B068@oracle.com> Vote: yes On Mar 17, 2014, at 2:47 PM, Thomas Wuerthinger wrote: > I hereby nominate Tom Rodriguez to Graal committer. > > Tom has already made 79 contributions to Graal [1]. Most notably, he has contributed support for allocation prefetching [2] and the ability to run Graal in tiered mode in combination with C1 [3]. > > Tom is a compiler expert, long-term contributor to both compilers of the HotSpot VM, member of the HotSpot Group as well as member of the OpenJDK Members Group. > > Votes are due March 31, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [4]. > For Lazy Consensus voting instructions, see [5]. > > - thomas > > [1] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/search/?rev=tom%20rodriguez&revcount=80 > [2] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/785bbb619238?revcount=80 > [3] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/800057208a2c?revcount=80 > [4] http://openjdk.java.net/census#graal > [5] http://openjdk.java.net/projects/#committer-vote From andreas.woess at jku.at Mon Mar 17 13:47:25 2014 From: andreas.woess at jku.at (Andreas Woess) Date: Mon, 17 Mar 2014 14:47:25 +0100 Subject: CFV: New Graal Committer: Tom Rodriguez In-Reply-To: <2E90E983-70F3-4B1B-9664-3A6A1B865A5B@oracle.com> References: <2E90E983-70F3-4B1B-9664-3A6A1B865A5B@oracle.com> Message-ID: <5326FCED.3010007@jku.at> Vote: yes On 17.03.2014 14:47, Thomas Wuerthinger wrote: > I hereby nominate Tom Rodriguez to Graal committer. > > Tom has already made 79 contributions to Graal [1]. Most notably, he has contributed support for allocation prefetching [2] and the ability to run Graal in tiered mode in combination with C1 [3]. > > Tom is a compiler expert, long-term contributor to both compilers of the HotSpot VM, member of the HotSpot Group as well as member of the OpenJDK Members Group. > > Votes are due March 31, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [4]. > For Lazy Consensus voting instructions, see [5]. > > - thomas > > [1] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/search/?rev=tom%20rodriguez&revcount=80 > [2] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/785bbb619238?revcount=80 > [3] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/800057208a2c?revcount=80 > [4] http://openjdk.java.net/census#graal > [5] http://openjdk.java.net/projects/#committer-vote From duboscq at ssw.jku.at Mon Mar 17 14:03:50 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Mon, 17 Mar 2014 15:03:50 +0100 Subject: CFV: New Graal Committer: Tom Rodriguez In-Reply-To: <5326FCED.3010007@jku.at> References: <2E90E983-70F3-4B1B-9664-3A6A1B865A5B@oracle.com> <5326FCED.3010007@jku.at> Message-ID: Vote: yes On Mon, Mar 17, 2014 at 2:47 PM, Andreas Woess wrote: > Vote: yes > > On 17.03.2014 14:47, Thomas Wuerthinger wrote: >> I hereby nominate Tom Rodriguez to Graal committer. >> >> Tom has already made 79 contributions to Graal [1]. Most notably, he has contributed support for allocation prefetching [2] and the ability to run Graal in tiered mode in combination with C1 [3]. >> >> Tom is a compiler expert, long-term contributor to both compilers of the HotSpot VM, member of the HotSpot Group as well as member of the OpenJDK Members Group. >> >> Votes are due March 31, 4:00 pm CET. >> >> Only current Graal committers are eligible to vote on this nomination [4]. >> For Lazy Consensus voting instructions, see [5]. >> >> - thomas >> >> [1] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/search/?rev=tom%20rodriguez&revcount=80 >> [2] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/785bbb619238?revcount=80 >> [3] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/800057208a2c?revcount=80 >> [4] http://openjdk.java.net/census#graal >> [5] http://openjdk.java.net/projects/#committer-vote > From roland.schatz at oracle.com Mon Mar 17 14:05:07 2014 From: roland.schatz at oracle.com (Roland Schatz) Date: Mon, 17 Mar 2014 15:05:07 +0100 Subject: CFV: New Graal Committer: Tom Rodriguez In-Reply-To: <2E90E983-70F3-4B1B-9664-3A6A1B865A5B@oracle.com> References: <2E90E983-70F3-4B1B-9664-3A6A1B865A5B@oracle.com> Message-ID: <53270113.2040900@oracle.com> Vote: yes On 03/17/2014 02:47 PM, Thomas Wuerthinger wrote: > I hereby nominate Tom Rodriguez to Graal committer. > > Tom has already made 79 contributions to Graal [1]. Most notably, he has contributed support for allocation prefetching [2] and the ability to run Graal in tiered mode in combination with C1 [3]. > > Tom is a compiler expert, long-term contributor to both compilers of the HotSpot VM, member of the HotSpot Group as well as member of the OpenJDK Members Group. > > Votes are due March 31, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [4]. > For Lazy Consensus voting instructions, see [5]. > > - thomas > > [1] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/search/?rev=tom%20rodriguez&revcount=80 > [2] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/785bbb619238?revcount=80 > [3] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/800057208a2c?revcount=80 > [4] http://openjdk.java.net/census#graal > [5] http://openjdk.java.net/projects/#committer-vote From christian.humer at gmail.com Mon Mar 17 14:06:10 2014 From: christian.humer at gmail.com (Christian Humer) Date: Mon, 17 Mar 2014 15:06:10 +0100 Subject: CFV: New Graal Committer: Tom Rodriguez In-Reply-To: <2E90E983-70F3-4B1B-9664-3A6A1B865A5B@oracle.com> References: <2E90E983-70F3-4B1B-9664-3A6A1B865A5B@oracle.com> Message-ID: Vote:yes On Mon, Mar 17, 2014 at 2:47 PM, Thomas Wuerthinger < thomas.wuerthinger at oracle.com> wrote: > I hereby nominate Tom Rodriguez to Graal committer. > > Tom has already made 79 contributions to Graal [1]. Most notably, he has > contributed support for allocation prefetching [2] and the ability to run > Graal in tiered mode in combination with C1 [3]. > > Tom is a compiler expert, long-term contributor to both compilers of the > HotSpot VM, member of the HotSpot Group as well as member of the OpenJDK > Members Group. > > Votes are due March 31, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [4]. > For Lazy Consensus voting instructions, see [5]. > > - thomas > > [1] > https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/search/?rev=tom%20rodriguez&revcount=80 > [2] > https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/785bbb619238?revcount=80 > [3] > https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/800057208a2c?revcount=80 > [4] http://openjdk.java.net/census#graal > [5] http://openjdk.java.net/projects/#committer-vote From lukas.stadler at oracle.com Mon Mar 17 14:07:35 2014 From: lukas.stadler at oracle.com (Lukas Stadler) Date: Mon, 17 Mar 2014 15:07:35 +0100 Subject: CFV: New Graal Committer: Tom Rodriguez In-Reply-To: <2E90E983-70F3-4B1B-9664-3A6A1B865A5B@oracle.com> References: <2E90E983-70F3-4B1B-9664-3A6A1B865A5B@oracle.com> Message-ID: <99E5F7AD-98E1-4AB9-87D5-F8A24FA2AA5C@oracle.com> Vote: yes On 17 Mar 2014, at 14:47, Thomas Wuerthinger wrote: > I hereby nominate Tom Rodriguez to Graal committer. > > Tom has already made 79 contributions to Graal [1]. Most notably, he has contributed support for allocation prefetching [2] and the ability to run Graal in tiered mode in combination with C1 [3]. > > Tom is a compiler expert, long-term contributor to both compilers of the HotSpot VM, member of the HotSpot Group as well as member of the OpenJDK Members Group. > > Votes are due March 31, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [4]. > For Lazy Consensus voting instructions, see [5]. > > - thomas > > [1] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/search/?rev=tom%20rodriguez&revcount=80 > [2] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/785bbb619238?revcount=80 > [3] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/800057208a2c?revcount=80 > [4] http://openjdk.java.net/census#graal > [5] http://openjdk.java.net/projects/#committer-vote From bernhard.urban at jku.at Mon Mar 17 14:13:21 2014 From: bernhard.urban at jku.at (Bernhard Urban) Date: Mon, 17 Mar 2014 15:13:21 +0100 Subject: CFV: New Graal Committer: Tom Rodriguez In-Reply-To: <2E90E983-70F3-4B1B-9664-3A6A1B865A5B@oracle.com> References: <2E90E983-70F3-4B1B-9664-3A6A1B865A5B@oracle.com> Message-ID: Vote: yes On Mon, Mar 17, 2014 at 2:47 PM, Thomas Wuerthinger < thomas.wuerthinger at oracle.com> wrote: > I hereby nominate Tom Rodriguez to Graal committer. > > Tom has already made 79 contributions to Graal [1]. Most notably, he has > contributed support for allocation prefetching [2] and the ability to run > Graal in tiered mode in combination with C1 [3]. > > Tom is a compiler expert, long-term contributor to both compilers of the > HotSpot VM, member of the HotSpot Group as well as member of the OpenJDK > Members Group. > > Votes are due March 31, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [4]. > For Lazy Consensus voting instructions, see [5]. > > - thomas > > [1] > https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/search/?rev=tom%20rodriguez&revcount=80 > [2] > https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/785bbb619238?revcount=80 > [3] > https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/800057208a2c?revcount=80 > [4] http://openjdk.java.net/census#graal > [5] http://openjdk.java.net/projects/#committer-vote > From christian.wimmer at oracle.com Mon Mar 17 16:21:53 2014 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Mon, 17 Mar 2014 09:21:53 -0700 Subject: CFV: New Graal Committer: Tom Rodriguez In-Reply-To: <2E90E983-70F3-4B1B-9664-3A6A1B865A5B@oracle.com> References: <2E90E983-70F3-4B1B-9664-3A6A1B865A5B@oracle.com> Message-ID: <53272121.8020106@oracle.com> Vote: yes On 03/17/2014 06:47 AM, Thomas Wuerthinger wrote: > I hereby nominate Tom Rodriguez to Graal committer. > > Tom has already made 79 contributions to Graal [1]. Most notably, he has contributed support for allocation prefetching [2] and the ability to run Graal in tiered mode in combination with C1 [3]. > > Tom is a compiler expert, long-term contributor to both compilers of the HotSpot VM, member of the HotSpot Group as well as member of the OpenJDK Members Group. > > Votes are due March 31, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [4]. > For Lazy Consensus voting instructions, see [5]. > > - thomas > > [1] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/search/?rev=tom%20rodriguez&revcount=80 > [2] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/785bbb619238?revcount=80 > [3] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/800057208a2c?revcount=80 > [4] http://openjdk.java.net/census#graal > [5] http://openjdk.java.net/projects/#committer-vote > From tom.deneau at amd.com Mon Mar 17 20:40:39 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 17 Mar 2014 20:40:39 +0000 Subject: code optimized away before a deopt In-Reply-To: References: <5C4A5B37-B6B6-4E25-9982-EA0BC543685C@oracle.com> <56957525-604C-4321-9A3D-478913744E0C@jku.at> Message-ID: I was just noticing that the condition mentioned below (first mentioned last November) still affects our snippet for newInstanceNode lowering. When I brought this up originally our DeoptimizeNode.deopt was not really implemented and was just making the workitem return early. Now, DeoptimizeNode.deopt is doing the necessary save state, etc but that doesn't change the fact that side-effecting nodes before the deopt will get thrown away. We have a workaround that seems to work for now (additional if logic around the deopt, which happens to be always true but the compiler hasn't figured that out) but I wonder if that is a robust workaround. Is there already a bug filed for this, or should I file one? -- Tom Here's the workaround we have now... Object result; Word thread = thread(); Word top = atomicGetAndAddTlabTop(thread, size); Word end = readTlabEnd(thread); Word newTop = top.add(size); if (useTLAB() && probability(FAST_PATH_PROBABILITY, newTop.belowOrEqual(end))) { // writeTlabTop(thread, newTop) was done by the atomicGetAndAdd result = formatObject(hub, size, top, prototypeMarkWord, fillContents); } else { atomicGetAndAddTlabTop(thread, -size); new_stub.inc(); // the if statement below should not be necessary, but when I remove it, // the atomicGetAndAddTlabTop(thread, -size) doesn't get generated. if (!newTop.belowOrEqual(end)) { DeoptimizeNode.deopt(DeoptimizationAction.None, DeoptimizationReason.RuntimeConstraint); } . . . > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Saturday, November 23, 2013 10:24 AM > To: Lukas Stadler > Cc: Deneau, Tom; graal-dev at openjdk.java.net > Subject: Re: code optimized away before a deopt > > > On Nov 23, 2013, at 5:18 PM, Lukas Stadler wrote: > > > But it _is_ ok to remove side effecting nodes, because we know they > will be reelected. > > Yes, normally, but when you write this pattern in a snippet, then this > won't be true right, since we don't resume execution in the bytecode of > the snippet (yet!). That why I was thinking at least a warning would be > a good idea. > > -Doug > > > Maybe the cleanup operations could be part of a special purpose deopt > node? > > > > - Lukas > > > > Von meinem iPhone gesendet > > > >> Am 23.11.2013 um 16:39 schrieb Doug Simon : > >> > >> This is done by the ConvertDeoptimizeToGuardPhase which replaces > conditionals where one branch ends in a deopt with a GuardNode. This > does indeed have the side effect of (silently) deleting all other nodes > on that deopt-terminated branch. We should add some code to either make > the deletion not silent or better, throw an error if these are any side- > effecting nodes that will be deleted. > >> > >> -Doug > >> > >>> On Nov 23, 2013, at 1:58 AM, Deneau, Tom wrote: > >>> > >>> I've noticed that if I have a snippet that does a test and if the > test fails, branches to a block that does some cleanup operations and > then calls DeoptimizeNode.deopt(xxx, yyy), the cleanup code gets > "optimized away". I guess this is related to what Gilles was talking > about, maybe the cleanup operations were considered not state changing? > >>> > >>> In our current state of HSAIL backend, a deopt just returns early > from the kernel. Is there something I can do to make the cleanup code > get emitted before the deopt? > >>> > >>> -- Tom > >> > From tom.rodriguez at oracle.com Mon Mar 17 21:17:33 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 17 Mar 2014 14:17:33 -0700 Subject: code optimized away before a deopt In-Reply-To: References: <5C4A5B37-B6B6-4E25-9982-EA0BC543685C@oracle.com> <56957525-604C-4321-9A3D-478913744E0C@jku.at> Message-ID: <6E10CA9C-5B69-4A63-8164-3B086E9BDE98@oracle.com> So you are using a TLAB from multiple threads so you need use atomic?s to actually do the allocation? Writing it using cleanup logic doesn?t seem right. I think should be using something like the edenAllocate code in NewInstanceStub but against the TLAB. Then you don?t need cleanup logic. Or you could just allocate directly from eden instead of using a TLAB. tom On Mar 17, 2014, at 1:40 PM, Deneau, Tom wrote: > I was just noticing that the condition mentioned below (first mentioned last November) still affects our snippet for newInstanceNode lowering. When I brought this up originally our DeoptimizeNode.deopt was not really implemented and was just making the workitem return early. Now, DeoptimizeNode.deopt is doing the necessary save state, etc but that doesn't change the fact that side-effecting nodes before the deopt will get thrown away. > > We have a workaround that seems to work for now (additional if logic around the deopt, which happens to be always true but the compiler hasn't figured that out) but I wonder if that is a robust workaround. Is there already a bug filed for this, or should I file one? > > -- Tom > > Here's the workaround we have now... > > Object result; > Word thread = thread(); > Word top = atomicGetAndAddTlabTop(thread, size); > Word end = readTlabEnd(thread); > Word newTop = top.add(size); > if (useTLAB() && probability(FAST_PATH_PROBABILITY, newTop.belowOrEqual(end))) { > // writeTlabTop(thread, newTop) was done by the atomicGetAndAdd > result = formatObject(hub, size, top, prototypeMarkWord, fillContents); > } else { > atomicGetAndAddTlabTop(thread, -size); > new_stub.inc(); > // the if statement below should not be necessary, but when I remove it, > // the atomicGetAndAddTlabTop(thread, -size) doesn't get generated. > if (!newTop.belowOrEqual(end)) { > DeoptimizeNode.deopt(DeoptimizationAction.None, DeoptimizationReason.RuntimeConstraint); > } > . . . > > > > >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Saturday, November 23, 2013 10:24 AM >> To: Lukas Stadler >> Cc: Deneau, Tom; graal-dev at openjdk.java.net >> Subject: Re: code optimized away before a deopt >> >> >> On Nov 23, 2013, at 5:18 PM, Lukas Stadler wrote: >> >>> But it _is_ ok to remove side effecting nodes, because we know they >> will be reelected. >> >> Yes, normally, but when you write this pattern in a snippet, then this >> won't be true right, since we don't resume execution in the bytecode of >> the snippet (yet!). That why I was thinking at least a warning would be >> a good idea. >> >> -Doug >> >>> Maybe the cleanup operations could be part of a special purpose deopt >> node? >>> >>> - Lukas >>> >>> Von meinem iPhone gesendet >>> >>>> Am 23.11.2013 um 16:39 schrieb Doug Simon : >>>> >>>> This is done by the ConvertDeoptimizeToGuardPhase which replaces >> conditionals where one branch ends in a deopt with a GuardNode. This >> does indeed have the side effect of (silently) deleting all other nodes >> on that deopt-terminated branch. We should add some code to either make >> the deletion not silent or better, throw an error if these are any side- >> effecting nodes that will be deleted. >>>> >>>> -Doug >>>> >>>>> On Nov 23, 2013, at 1:58 AM, Deneau, Tom wrote: >>>>> >>>>> I've noticed that if I have a snippet that does a test and if the >> test fails, branches to a block that does some cleanup operations and >> then calls DeoptimizeNode.deopt(xxx, yyy), the cleanup code gets >> "optimized away". I guess this is related to what Gilles was talking >> about, maybe the cleanup operations were considered not state changing? >>>>> >>>>> In our current state of HSAIL backend, a deopt just returns early >> from the kernel. Is there something I can do to make the cleanup code >> get emitted before the deopt? >>>>> >>>>> -- Tom >>>> >> > > From tom.deneau at amd.com Mon Mar 17 21:28:46 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 17 Mar 2014 21:28:46 +0000 Subject: code optimized away before a deopt In-Reply-To: <6E10CA9C-5B69-4A63-8164-3B086E9BDE98@oracle.com> References: <5C4A5B37-B6B6-4E25-9982-EA0BC543685C@oracle.com> <56957525-604C-4321-9A3D-478913744E0C@jku.at> <6E10CA9C-5B69-4A63-8164-3B086E9BDE98@oracle.com> Message-ID: I'll take a look at edenAllocate logic but I was trying to avoid the while(true) loop which the compareAndSwap logic requires. -- Tom > -----Original Message----- > From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > Sent: Monday, March 17, 2014 4:18 PM > To: Deneau, Tom > Cc: Douglas Simon; Lukas Stadler; graal-dev at openjdk.java.net > Subject: Re: code optimized away before a deopt > > So you are using a TLAB from multiple threads so you need use atomic's > to actually do the allocation? Writing it using cleanup logic doesn't > seem right. I think should be using something like the edenAllocate code > in NewInstanceStub but against the TLAB. Then you don't need cleanup > logic. Or you could just allocate directly from eden instead of using a > TLAB. > > tom > > On Mar 17, 2014, at 1:40 PM, Deneau, Tom wrote: > > > I was just noticing that the condition mentioned below (first > mentioned last November) still affects our snippet for newInstanceNode > lowering. When I brought this up originally our DeoptimizeNode.deopt > was not really implemented and was just making the workitem return > early. Now, DeoptimizeNode.deopt is doing the necessary save state, etc > but that doesn't change the fact that side-effecting nodes before the > deopt will get thrown away. > > > > We have a workaround that seems to work for now (additional if logic > around the deopt, which happens to be always true but the compiler > hasn't figured that out) but I wonder if that is a robust workaround. > Is there already a bug filed for this, or should I file one? > > > > -- Tom > > > > Here's the workaround we have now... > > > > Object result; > > Word thread = thread(); > > Word top = atomicGetAndAddTlabTop(thread, size); > > Word end = readTlabEnd(thread); > > Word newTop = top.add(size); > > if (useTLAB() && probability(FAST_PATH_PROBABILITY, > newTop.belowOrEqual(end))) { > > // writeTlabTop(thread, newTop) was done by the > atomicGetAndAdd > > result = formatObject(hub, size, top, prototypeMarkWord, > fillContents); > > } else { > > atomicGetAndAddTlabTop(thread, -size); > > new_stub.inc(); > > // the if statement below should not be necessary, but when > I remove it, > > // the atomicGetAndAddTlabTop(thread, -size) doesn't get > generated. > > if (!newTop.belowOrEqual(end)) { > > DeoptimizeNode.deopt(DeoptimizationAction.None, > DeoptimizationReason.RuntimeConstraint); > > } > > . . . > > > > > > > > > >> -----Original Message----- > >> From: Doug Simon [mailto:doug.simon at oracle.com] > >> Sent: Saturday, November 23, 2013 10:24 AM > >> To: Lukas Stadler > >> Cc: Deneau, Tom; graal-dev at openjdk.java.net > >> Subject: Re: code optimized away before a deopt > >> > >> > >> On Nov 23, 2013, at 5:18 PM, Lukas Stadler > wrote: > >> > >>> But it _is_ ok to remove side effecting nodes, because we know they > >> will be reelected. > >> > >> Yes, normally, but when you write this pattern in a snippet, then > >> this won't be true right, since we don't resume execution in the > >> bytecode of the snippet (yet!). That why I was thinking at least a > >> warning would be a good idea. > >> > >> -Doug > >> > >>> Maybe the cleanup operations could be part of a special purpose > >>> deopt > >> node? > >>> > >>> - Lukas > >>> > >>> Von meinem iPhone gesendet > >>> > >>>> Am 23.11.2013 um 16:39 schrieb Doug Simon : > >>>> > >>>> This is done by the ConvertDeoptimizeToGuardPhase which replaces > >> conditionals where one branch ends in a deopt with a GuardNode. This > >> does indeed have the side effect of (silently) deleting all other > >> nodes on that deopt-terminated branch. We should add some code to > >> either make the deletion not silent or better, throw an error if > >> these are any side- effecting nodes that will be deleted. > >>>> > >>>> -Doug > >>>> > >>>>> On Nov 23, 2013, at 1:58 AM, Deneau, Tom > wrote: > >>>>> > >>>>> I've noticed that if I have a snippet that does a test and if the > >> test fails, branches to a block that does some cleanup operations and > >> then calls DeoptimizeNode.deopt(xxx, yyy), the cleanup code gets > >> "optimized away". I guess this is related to what Gilles was talking > >> about, maybe the cleanup operations were considered not state > changing? > >>>>> > >>>>> In our current state of HSAIL backend, a deopt just returns early > >> from the kernel. Is there something I can do to make the cleanup > code > >> get emitted before the deopt? > >>>>> > >>>>> -- Tom > >>>> > >> > > > > > From christian.thalinger at oracle.com Mon Mar 17 22:13:14 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 17 Mar 2014 15:13:14 -0700 Subject: CFV: New Graal Committer: Tom Rodriguez In-Reply-To: <2E90E983-70F3-4B1B-9664-3A6A1B865A5B@oracle.com> References: <2E90E983-70F3-4B1B-9664-3A6A1B865A5B@oracle.com> Message-ID: Vote: yes On Mar 17, 2014, at 6:47 AM, Thomas Wuerthinger wrote: > I hereby nominate Tom Rodriguez to Graal committer. > > Tom has already made 79 contributions to Graal [1]. Most notably, he has contributed support for allocation prefetching [2] and the ability to run Graal in tiered mode in combination with C1 [3]. > > Tom is a compiler expert, long-term contributor to both compilers of the HotSpot VM, member of the HotSpot Group as well as member of the OpenJDK Members Group. > > Votes are due March 31, 4:00 pm CET. > > Only current Graal committers are eligible to vote on this nomination [4]. > For Lazy Consensus voting instructions, see [5]. > > - thomas > > [1] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/search/?rev=tom%20rodriguez&revcount=80 > [2] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/785bbb619238?revcount=80 > [3] https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/rev/800057208a2c?revcount=80 > [4] http://openjdk.java.net/census#graal > [5] http://openjdk.java.net/projects/#committer-vote From eric.caspole at amd.com Mon Mar 17 22:20:34 2014 From: eric.caspole at amd.com (Eric Caspole) Date: Mon, 17 Mar 2014 18:20:34 -0400 Subject: Graal and Clojure In-Reply-To: References: <1394063789.8387.YahooMailNeo@web122406.mail.ne1.yahoo.com> <5326354D.8010204@yahoo.com> Message-ID: <53277532.3030807@amd.com> Hi everybody, I was setting up a new HSA system today and I installed Clumatra and got it working under the simulator. I have a real HSA system not too different from this: http://code.google.com/p/aparapi/wiki/SettingUpLinuxHSAMachineForAparapi In the clojure/lein/maven based system there is so much harness I can't immediately see how to switch in the real hardware version of Okra instead of the simulator Okra that gets installed into maven and exploded in /tmp when the tests run. Jules, could you show how to bypass the harness etc to switch the Okra? Can I just run 1 test with a simple java command line? This makes it a lot easier to use a debugger which I will definitely want to do. Otherwise this is a cool project and we already found 1 or 2 issues we can fix in HSAIL Graal related to your clojure tests. Regards, Eric On 03/17/2014 06:43 AM, Doug Simon wrote: > Hi Julian, > > In terms of what to test, I?ll leave it up to the Sumatra developers at AMD and Oracle to comment on what may be interesting. > > As far as I know, no one in the Graal team is that familiar with Clojure. This actually makes the value of having Clojure tests integrated into our gate system somewhat problematic - debugging/fixing failures may be difficult. I?d suggest you report failures your discover on the sumatra-dev and graal-dev lists and we can resolve them that way for now. > > In addition, for Graal we?re always interested in benchmark suites for JVM hosted languages. Can you recommend any well known and trusted Clojure benchmarks we should consider? > > -Doug > > On Mar 17, 2014, at 12:35 AM, Jules Gosnell wrote: > >> Doug, >> >> Sorry it has taken me a while to get back - I've been busy playing with code. >> >> I currently have a small clojure testsuite up and running. I plan to broaden this and then think about providing it in a junit-compatible way to your project. >> >> I still haven't made up my mind exactly what I should be testing. It seems unnecessary to duplicate all your tests in Clojure, since you are already guarding against regression in these areas - I think I will start out with a fairly general set of tests as I probe for particular problem areas for Clojure, into which I may dive for more detail - time will tell... if you have any ideas, please let me know. >> >> I've checked my stuff in at github, if anyone is interested - here is the project: >> >> https://github.com/JulesGosnell/clumatra >> >> here is some clojure that I reverse engineered from GraalKernelTester: >> >> https://github.com/JulesGosnell/clumatra/blob/master/src/clumatra/core.clj >> >> and here are the first successful tests: >> >> https://github.com/JulesGosnell/clumatra/blob/master/test/clumatra/core_test.clj >> >> not very pretty yet - I am still feeling my way. >> >> cheers >> >> >> Jules >> >> >> >> >> On 06/03/14 10:24, Doug Simon wrote: >>> Hi Julian, >>> >>> This looks very interesting and will be an good alternative testing vector for the Sumatra work as it matures. If Clojure tests can somehow be made to run from Junit, then I?m sure we can try integrating it into our testing. >>> >>> -Doug >>> >>> On Mar 6, 2014, at 12:56 AM, Julian Gosnell wrote: >>> >>>> Guys, >>>> >>>> I just built the Java8 / Graal / Okra stack and managed to run some very simple Clojure copying the contents of one int array into another one on Okra. >>>> >>>> https://groups.google.com/forum/#!topic/clojure/JpjK__NTR5Y >>>> >>>> >>>> I find the ramifications of this very exciting :-) >>>> >>>> I understand that fn-ality is limited at the moment - but I am keen to keep testing and to help ensure early visibility of Clojure related issues to both communities - perhaps even the submission of a Clojure testsuite if Graal developers thought that useful. >>>> >>>> I'd be very interested in your thoughts on Graal / Clojure. >>>> >>>> regards, >>>> >>>> >>>> Jules >>>> >>> >>> >> > > From tom.rodriguez at oracle.com Mon Mar 17 23:06:40 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 17 Mar 2014 16:06:40 -0700 Subject: code optimized away before a deopt In-Reply-To: References: <5C4A5B37-B6B6-4E25-9982-EA0BC543685C@oracle.com> <56957525-604C-4321-9A3D-478913744E0C@jku.at> <6E10CA9C-5B69-4A63-8164-3B086E9BDE98@oracle.com> Message-ID: <93452F27-3778-4397-8D82-1F7A3C7EB390@oracle.com> How is atomicGetAndAddTlabTop actually implemented? tom On Mar 17, 2014, at 2:28 PM, Deneau, Tom wrote: > I'll take a look at edenAllocate logic but I was trying to avoid the while(true) loop which the compareAndSwap logic requires. > > -- Tom > >> -----Original Message----- >> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] >> Sent: Monday, March 17, 2014 4:18 PM >> To: Deneau, Tom >> Cc: Douglas Simon; Lukas Stadler; graal-dev at openjdk.java.net >> Subject: Re: code optimized away before a deopt >> >> So you are using a TLAB from multiple threads so you need use atomic's >> to actually do the allocation? Writing it using cleanup logic doesn't >> seem right. I think should be using something like the edenAllocate code >> in NewInstanceStub but against the TLAB. Then you don't need cleanup >> logic. Or you could just allocate directly from eden instead of using a >> TLAB. >> >> tom >> >> On Mar 17, 2014, at 1:40 PM, Deneau, Tom wrote: >> >>> I was just noticing that the condition mentioned below (first >> mentioned last November) still affects our snippet for newInstanceNode >> lowering. When I brought this up originally our DeoptimizeNode.deopt >> was not really implemented and was just making the workitem return >> early. Now, DeoptimizeNode.deopt is doing the necessary save state, etc >> but that doesn't change the fact that side-effecting nodes before the >> deopt will get thrown away. >>> >>> We have a workaround that seems to work for now (additional if logic >> around the deopt, which happens to be always true but the compiler >> hasn't figured that out) but I wonder if that is a robust workaround. >> Is there already a bug filed for this, or should I file one? >>> >>> -- Tom >>> >>> Here's the workaround we have now... >>> >>> Object result; >>> Word thread = thread(); >>> Word top = atomicGetAndAddTlabTop(thread, size); >>> Word end = readTlabEnd(thread); >>> Word newTop = top.add(size); >>> if (useTLAB() && probability(FAST_PATH_PROBABILITY, >> newTop.belowOrEqual(end))) { >>> // writeTlabTop(thread, newTop) was done by the >> atomicGetAndAdd >>> result = formatObject(hub, size, top, prototypeMarkWord, >> fillContents); >>> } else { >>> atomicGetAndAddTlabTop(thread, -size); >>> new_stub.inc(); >>> // the if statement below should not be necessary, but when >> I remove it, >>> // the atomicGetAndAddTlabTop(thread, -size) doesn't get >> generated. >>> if (!newTop.belowOrEqual(end)) { >>> DeoptimizeNode.deopt(DeoptimizationAction.None, >> DeoptimizationReason.RuntimeConstraint); >>> } >>> . . . >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>> Sent: Saturday, November 23, 2013 10:24 AM >>>> To: Lukas Stadler >>>> Cc: Deneau, Tom; graal-dev at openjdk.java.net >>>> Subject: Re: code optimized away before a deopt >>>> >>>> >>>> On Nov 23, 2013, at 5:18 PM, Lukas Stadler >> wrote: >>>> >>>>> But it _is_ ok to remove side effecting nodes, because we know they >>>> will be reelected. >>>> >>>> Yes, normally, but when you write this pattern in a snippet, then >>>> this won't be true right, since we don't resume execution in the >>>> bytecode of the snippet (yet!). That why I was thinking at least a >>>> warning would be a good idea. >>>> >>>> -Doug >>>> >>>>> Maybe the cleanup operations could be part of a special purpose >>>>> deopt >>>> node? >>>>> >>>>> - Lukas >>>>> >>>>> Von meinem iPhone gesendet >>>>> >>>>>> Am 23.11.2013 um 16:39 schrieb Doug Simon : >>>>>> >>>>>> This is done by the ConvertDeoptimizeToGuardPhase which replaces >>>> conditionals where one branch ends in a deopt with a GuardNode. This >>>> does indeed have the side effect of (silently) deleting all other >>>> nodes on that deopt-terminated branch. We should add some code to >>>> either make the deletion not silent or better, throw an error if >>>> these are any side- effecting nodes that will be deleted. >>>>>> >>>>>> -Doug >>>>>> >>>>>>> On Nov 23, 2013, at 1:58 AM, Deneau, Tom >> wrote: >>>>>>> >>>>>>> I've noticed that if I have a snippet that does a test and if the >>>> test fails, branches to a block that does some cleanup operations and >>>> then calls DeoptimizeNode.deopt(xxx, yyy), the cleanup code gets >>>> "optimized away". I guess this is related to what Gilles was talking >>>> about, maybe the cleanup operations were considered not state >> changing? >>>>>>> >>>>>>> In our current state of HSAIL backend, a deopt just returns early >>>> from the kernel. Is there something I can do to make the cleanup >> code >>>> get emitted before the deopt? >>>>>>> >>>>>>> -- Tom >>>>>> >>>> >>> >>> >> > > From doug.simon at oracle.com Tue Mar 18 02:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 18 Mar 2014 02:00:07 +0000 Subject: hg: graal/graal: 21 new changesets Message-ID: <201403180200.s2I20ZwO010210@aojmv0008> Changeset: 29f47f2c6388 Author: Matthias Grimmer Date: 2014-03-17 09:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/29f47f2c6388 DebugPrinter: fix findbugs issues + graal/com.oracle.graal.java.decompiler.test/src/com/oracle/graal/java/decompiler/test/DecompilerTest.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.decompiler/src/com/oracle/graal/java/decompiler/DecompilerIfSimplify.java ! graal/com.oracle.graal.java.decompiler/src/com/oracle/graal/java/decompiler/block/DecompilerIfBlock.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/DecompilerDebugDumpHandler.java ! mx/projects Changeset: 2e672570021a Author: Matthias Grimmer Date: 2014-03-17 09:37 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2e672570021a DebugPrinter: remove unittest init ! graal/com.oracle.graal.java.decompiler.test/src/com/oracle/graal/java/decompiler/test/DecompilerTest.java Changeset: 24cd779e5d94 Author: Bernhard Urban Date: 2014-03-17 11:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/24cd779e5d94 complevel: use COMPILERGRAAL flag (fixes hosted-mode with ClientVM) ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 498b81be6cda Author: Bernhard Urban Date: 2014-03-17 11:46 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/498b81be6cda high tier: remove VerifyUsage*Phase (replaced by CheckGraalInvariants) ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/HighTier.java Changeset: fabf5447603e Author: Roland Schatz Date: 2014-03-17 11:21 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/fabf5447603e Use stamp constructor in PhiNode. ! graal/com.oracle.graal.java/src/com/oracle/graal/java/FrameStateBuilder.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInside.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/IllegalStamp.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/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ReadEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PEReadEliminationClosure.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/ReadEliminationClosure.java Changeset: 883fbd3e06e0 Author: Roland Schatz Date: 2014-03-17 11:27 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/883fbd3e06e0 Make size of PlatformKind overridable by VM specific code. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CalleeSaveLayout.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CompilationResult.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/TargetDescription.java ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64MacroAssembler.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRegisterConfig.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/SPARCHotSpotCodeCacheProvider.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRegisterConfig.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/HotSpotCompiledCode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotCompiledNmethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotCompiledRuntimeStub.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/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/stubs/Stub.java ! graal/com.oracle.graal.hsail/src/com/oracle/graal/hsail/HSAILRegisterConfig.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/FrameMap.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/nodes/WordCastNode.java Changeset: 570910f5412b Author: Roland Schatz Date: 2014-03-17 11:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/570910f5412b Introduce Hotspot-specific NarrowOop kind. ! 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/AMD64HotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackendFactory.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/HotSpotTargetDescription.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/type/NarrowOopStamp.java Changeset: e14198669e5c Author: Roland Schatz Date: 2014-03-17 11:53 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e14198669e5c Make data patch system use vm specific NarrowOop kind. ! 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/CompilationResult.java ! graal/com.oracle.graal.asm.amd64.test/src/com/oracle/graal/asm/amd64/test/SimpleAssemblerTest.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/AMD64HotSpotMove.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotCompiledCode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotCompiledRuntimeStub.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/data/DataSection.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/data/DataSectionReference.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/data/MetaspaceData.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/data/OopData.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/data/PatchedData.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotCodeCacheProvider.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/CompilationResultBuilder.java ! src/cpu/sparc/vm/graalCodeInstaller_sparc.hpp ! src/cpu/x86/vm/graalCodeInstaller_x86.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalCodeInstaller.hpp ! src/share/vm/graal/graalJavaAccess.hpp Changeset: 45812e05cdb3 Author: Roland Schatz Date: 2014-03-17 12:07 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/45812e05cdb3 Move narrow oop handling in reference maps to hotspot specific code. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CodeUtil.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CompilationResult.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ReferenceMap.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/TargetDescription.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReferenceMap.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotTargetDescription.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/FrameMap.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CompilationPrinter.java ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalJavaAccess.hpp Changeset: 82e4fe6fa525 Author: Roland Schatz Date: 2014-03-17 13:08 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/82e4fe6fa525 Remove all references to NarrowOop from VM independent code. ! graal/com.oracle.graal.amd64/src/com/oracle/graal/amd64/AMD64.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Architecture.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Constant.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Kind.java ! graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/type/NarrowOopStamp.java ! graal/com.oracle.graal.hsail/src/com/oracle/graal/hsail/HSAIL.java ! graal/com.oracle.graal.hsail/src/com/oracle/graal/hsail/HSAILRegisterConfig.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.java ! graal/com.oracle.graal.sparc/src/com/oracle/graal/sparc/SPARC.java Changeset: 5d1308c78ddc Author: Christian Humer Date: 2014-03-17 14:29 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5d1308c78ddc Truffle: Introduced NodeCost as a replacement for NodeInfo.Kind. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/PolymorphicTest.java ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/PolymorphicTest2.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/TruffleOptions.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/GraphPrintVisitor.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeCost.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeInfo.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.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/node/NodeCodeGenerator.java Changeset: 9c01fabfb167 Author: Christian Humer Date: 2014-03-17 14:29 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9c01fabfb167 Truffle: Removed deprecated API; Added NodeFilter to customize filter when counting nodes. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/CallNode.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/RootNode.java Changeset: 6681b9eb3f4c Author: Christian Humer Date: 2014-03-17 14:29 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6681b9eb3f4c Truffle: API cleanup and javadoc for CallNodes. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallNode.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultCallNode.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/CallNode.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeCost.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeInfo.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/RootNode.java Changeset: b1dded9c748a Author: Christian Humer Date: 2014-03-17 14:30 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b1dded9c748a Merge. - agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java - graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaslineCompiler.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotGraphCache.java - graal/com.oracle.graal.java.decompiler.test/src/com/oracle/graal/java/decompiler/test/Test.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/GraphCache.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java - src/os/bsd/dtrace/hotspot.d - src/os/bsd/dtrace/hotspot_jni.d - src/os/bsd/dtrace/hs_private.d - src/os/solaris/dtrace/hotspot.d - src/os/solaris/dtrace/hotspot_jni.d - src/os/solaris/dtrace/hs_private.d - src/share/vm/utilities/dtrace_usdt2_disabled.hpp Changeset: 2e90d9a9a677 Author: Christian Humer Date: 2014-03-17 14:57 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2e90d9a9a677 Truffle: Added API changes to the changelog. ! CHANGELOG.md Changeset: 5e04917e6616 Author: Christian Humer Date: 2014-03-17 18:46 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5e04917e6616 Truffle: renamed NodeFilter to NodeCountFilter and changed it to have inclusive implementation semantics. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: c828417b7037 Author: Michael Van De Vanter Date: 2014-03-17 12:39 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c828417b7037 Remove TODOs no longer relevant ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/debug/KillException.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/debug/QuitException.java Changeset: 24431a9b878c Author: Michael Van De Vanter Date: 2014-03-17 12:40 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/24431a9b878c Merge with 5e04917e66165ef93fe7b61030c4d89a08b3d53c - graal/com.oracle.graal.java.decompiler.test/src/com/oracle/graal/java/decompiler/test/Test.java Changeset: 1d35a2b84553 Author: Doug Simon Date: 2014-03-17 23:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1d35a2b84553 use Java Allocation Instrumenter to observe allocation in Graal compiler tests + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/AllocationScope.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugHistogram.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugHistogramAsciiPrinter.java ! mx/projects Changeset: e3888db8b8a1 Author: Doug Simon Date: 2014-03-17 23:46 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e3888db8b8a1 Backed out changeset: 1d35a2b84553 - graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/AllocationScope.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugHistogram.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugHistogramAsciiPrinter.java ! mx/projects Changeset: 6bab029d6e3a Author: twisti Date: 2014-03-17 17:32 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6bab029d6e3a removed com/oracle/graal/hotspot/bridge/Marks.java and replaced with enum ! 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/AMD64HotSpotSafepointOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotspotDirectStaticCallOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotspotDirectVirtualCallOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64IndirectCallOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotSafepointOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotspotDirectStaticCallOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotspotDirectVirtualCallOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCIndirectCallOp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/Marks.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotCodeCacheProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java ! graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/OptimizedCallTargetInstrumentation.java ! src/cpu/sparc/vm/graalCodeInstaller_sparc.hpp ! src/cpu/x86/vm/graalCodeInstaller_x86.hpp ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalCodeInstaller.hpp ! src/share/vm/graal/vmStructs_graal.hpp From tom.deneau at amd.com Tue Mar 18 14:57:53 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 18 Mar 2014 14:57:53 +0000 Subject: code optimized away before a deopt In-Reply-To: <93452F27-3778-4397-8D82-1F7A3C7EB390@oracle.com> References: <5C4A5B37-B6B6-4E25-9982-EA0BC543685C@oracle.com> <56957525-604C-4321-9A3D-478913744E0C@jku.at> <6E10CA9C-5B69-4A63-8164-3B086E9BDE98@oracle.com> <93452F27-3778-4397-8D82-1F7A3C7EB390@oracle.com> Message-ID: Tom -- It generates an HSAIL instruction atomic_add_global (similar to lock xadd in x86). I don't know for sure what that becomes in the gpu Instructions. In rough perf measurements I made it was more performant than doing a similar thing using an atomic_cas loop -- Tom > -----Original Message----- > From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > Sent: Monday, March 17, 2014 6:07 PM > To: Deneau, Tom > Cc: Douglas Simon; Lukas Stadler; graal-dev at openjdk.java.net > Subject: Re: code optimized away before a deopt > > How is atomicGetAndAddTlabTop actually implemented? > > tom > > On Mar 17, 2014, at 2:28 PM, Deneau, Tom wrote: > > > I'll take a look at edenAllocate logic but I was trying to avoid the > while(true) loop which the compareAndSwap logic requires. > > > > -- Tom > > > >> -----Original Message----- > >> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > >> Sent: Monday, March 17, 2014 4:18 PM > >> To: Deneau, Tom > >> Cc: Douglas Simon; Lukas Stadler; graal-dev at openjdk.java.net > >> Subject: Re: code optimized away before a deopt > >> > >> So you are using a TLAB from multiple threads so you need use > >> atomic's to actually do the allocation? Writing it using cleanup > >> logic doesn't seem right. I think should be using something like the > >> edenAllocate code in NewInstanceStub but against the TLAB. Then you > >> don't need cleanup logic. Or you could just allocate directly from > >> eden instead of using a TLAB. > >> > >> tom > >> > >> On Mar 17, 2014, at 1:40 PM, Deneau, Tom wrote: > >> > >>> I was just noticing that the condition mentioned below (first > >> mentioned last November) still affects our snippet for > >> newInstanceNode lowering. When I brought this up originally our > >> DeoptimizeNode.deopt was not really implemented and was just making > >> the workitem return early. Now, DeoptimizeNode.deopt is doing the > >> necessary save state, etc but that doesn't change the fact that > >> side-effecting nodes before the deopt will get thrown away. > >>> > >>> We have a workaround that seems to work for now (additional if logic > >> around the deopt, which happens to be always true but the compiler > >> hasn't figured that out) but I wonder if that is a robust workaround. > >> Is there already a bug filed for this, or should I file one? > >>> > >>> -- Tom > >>> > >>> Here's the workaround we have now... > >>> > >>> Object result; > >>> Word thread = thread(); > >>> Word top = atomicGetAndAddTlabTop(thread, size); > >>> Word end = readTlabEnd(thread); > >>> Word newTop = top.add(size); > >>> if (useTLAB() && probability(FAST_PATH_PROBABILITY, > >> newTop.belowOrEqual(end))) { > >>> // writeTlabTop(thread, newTop) was done by the > >> atomicGetAndAdd > >>> result = formatObject(hub, size, top, prototypeMarkWord, > >> fillContents); > >>> } else { > >>> atomicGetAndAddTlabTop(thread, -size); > >>> new_stub.inc(); > >>> // the if statement below should not be necessary, but > >>> when > >> I remove it, > >>> // the atomicGetAndAddTlabTop(thread, -size) doesn't get > >> generated. > >>> if (!newTop.belowOrEqual(end)) { > >>> DeoptimizeNode.deopt(DeoptimizationAction.None, > >> DeoptimizationReason.RuntimeConstraint); > >>> } > >>> . . . > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Doug Simon [mailto:doug.simon at oracle.com] > >>>> Sent: Saturday, November 23, 2013 10:24 AM > >>>> To: Lukas Stadler > >>>> Cc: Deneau, Tom; graal-dev at openjdk.java.net > >>>> Subject: Re: code optimized away before a deopt > >>>> > >>>> > >>>> On Nov 23, 2013, at 5:18 PM, Lukas Stadler > >> wrote: > >>>> > >>>>> But it _is_ ok to remove side effecting nodes, because we know > >>>>> they > >>>> will be reelected. > >>>> > >>>> Yes, normally, but when you write this pattern in a snippet, then > >>>> this won't be true right, since we don't resume execution in the > >>>> bytecode of the snippet (yet!). That why I was thinking at least a > >>>> warning would be a good idea. > >>>> > >>>> -Doug > >>>> > >>>>> Maybe the cleanup operations could be part of a special purpose > >>>>> deopt > >>>> node? > >>>>> > >>>>> - Lukas > >>>>> > >>>>> Von meinem iPhone gesendet > >>>>> > >>>>>> Am 23.11.2013 um 16:39 schrieb Doug Simon > : > >>>>>> > >>>>>> This is done by the ConvertDeoptimizeToGuardPhase which replaces > >>>> conditionals where one branch ends in a deopt with a GuardNode. > >>>> This does indeed have the side effect of (silently) deleting all > >>>> other nodes on that deopt-terminated branch. We should add some > >>>> code to either make the deletion not silent or better, throw an > >>>> error if these are any side- effecting nodes that will be deleted. > >>>>>> > >>>>>> -Doug > >>>>>> > >>>>>>> On Nov 23, 2013, at 1:58 AM, Deneau, Tom > >> wrote: > >>>>>>> > >>>>>>> I've noticed that if I have a snippet that does a test and if > >>>>>>> the > >>>> test fails, branches to a block that does some cleanup operations > >>>> and then calls DeoptimizeNode.deopt(xxx, yyy), the cleanup code > >>>> gets "optimized away". I guess this is related to what Gilles was > >>>> talking about, maybe the cleanup operations were considered not > >>>> state > >> changing? > >>>>>>> > >>>>>>> In our current state of HSAIL backend, a deopt just returns > >>>>>>> early > >>>> from the kernel. Is there something I can do to make the cleanup > >> code > >>>> get emitted before the deopt? > >>>>>>> > >>>>>>> -- Tom > >>>>>> > >>>> > >>> > >>> > >> > > > > > From tom.rodriguez at oracle.com Tue Mar 18 16:41:33 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 18 Mar 2014 09:41:33 -0700 Subject: code optimized away before a deopt In-Reply-To: References: <5C4A5B37-B6B6-4E25-9982-EA0BC543685C@oracle.com> <56957525-604C-4321-9A3D-478913744E0C@jku.at> <6E10CA9C-5B69-4A63-8164-3B086E9BDE98@oracle.com> <93452F27-3778-4397-8D82-1F7A3C7EB390@oracle.com> Message-ID: <710063CF-DCD4-4328-8314-0EA798B134A6@oracle.com> So it?s a custom node of some sort? I think you probably need make sure it behaves like a WriteNode by implementing StateSplit and having hasSideEffect return true. The state can be null. tom On Mar 18, 2014, at 7:57 AM, Deneau, Tom wrote: > Tom -- > > It generates an HSAIL instruction atomic_add_global (similar to lock xadd in x86). I don't know for sure what that becomes in the gpu Instructions. In rough perf measurements I made it was more performant than doing a similar thing using an atomic_cas loop > > -- Tom >> -----Original Message----- >> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] >> Sent: Monday, March 17, 2014 6:07 PM >> To: Deneau, Tom >> Cc: Douglas Simon; Lukas Stadler; graal-dev at openjdk.java.net >> Subject: Re: code optimized away before a deopt >> >> How is atomicGetAndAddTlabTop actually implemented? >> >> tom >> >> On Mar 17, 2014, at 2:28 PM, Deneau, Tom wrote: >> >>> I'll take a look at edenAllocate logic but I was trying to avoid the >> while(true) loop which the compareAndSwap logic requires. >>> >>> -- Tom >>> >>>> -----Original Message----- >>>> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] >>>> Sent: Monday, March 17, 2014 4:18 PM >>>> To: Deneau, Tom >>>> Cc: Douglas Simon; Lukas Stadler; graal-dev at openjdk.java.net >>>> Subject: Re: code optimized away before a deopt >>>> >>>> So you are using a TLAB from multiple threads so you need use >>>> atomic's to actually do the allocation? Writing it using cleanup >>>> logic doesn't seem right. I think should be using something like the >>>> edenAllocate code in NewInstanceStub but against the TLAB. Then you >>>> don't need cleanup logic. Or you could just allocate directly from >>>> eden instead of using a TLAB. >>>> >>>> tom >>>> >>>> On Mar 17, 2014, at 1:40 PM, Deneau, Tom wrote: >>>> >>>>> I was just noticing that the condition mentioned below (first >>>> mentioned last November) still affects our snippet for >>>> newInstanceNode lowering. When I brought this up originally our >>>> DeoptimizeNode.deopt was not really implemented and was just making >>>> the workitem return early. Now, DeoptimizeNode.deopt is doing the >>>> necessary save state, etc but that doesn't change the fact that >>>> side-effecting nodes before the deopt will get thrown away. >>>>> >>>>> We have a workaround that seems to work for now (additional if logic >>>> around the deopt, which happens to be always true but the compiler >>>> hasn't figured that out) but I wonder if that is a robust workaround. >>>> Is there already a bug filed for this, or should I file one? >>>>> >>>>> -- Tom >>>>> >>>>> Here's the workaround we have now... >>>>> >>>>> Object result; >>>>> Word thread = thread(); >>>>> Word top = atomicGetAndAddTlabTop(thread, size); >>>>> Word end = readTlabEnd(thread); >>>>> Word newTop = top.add(size); >>>>> if (useTLAB() && probability(FAST_PATH_PROBABILITY, >>>> newTop.belowOrEqual(end))) { >>>>> // writeTlabTop(thread, newTop) was done by the >>>> atomicGetAndAdd >>>>> result = formatObject(hub, size, top, prototypeMarkWord, >>>> fillContents); >>>>> } else { >>>>> atomicGetAndAddTlabTop(thread, -size); >>>>> new_stub.inc(); >>>>> // the if statement below should not be necessary, but >>>>> when >>>> I remove it, >>>>> // the atomicGetAndAddTlabTop(thread, -size) doesn't get >>>> generated. >>>>> if (!newTop.belowOrEqual(end)) { >>>>> DeoptimizeNode.deopt(DeoptimizationAction.None, >>>> DeoptimizationReason.RuntimeConstraint); >>>>> } >>>>> . . . >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>>>> Sent: Saturday, November 23, 2013 10:24 AM >>>>>> To: Lukas Stadler >>>>>> Cc: Deneau, Tom; graal-dev at openjdk.java.net >>>>>> Subject: Re: code optimized away before a deopt >>>>>> >>>>>> >>>>>> On Nov 23, 2013, at 5:18 PM, Lukas Stadler >>>> wrote: >>>>>> >>>>>>> But it _is_ ok to remove side effecting nodes, because we know >>>>>>> they >>>>>> will be reelected. >>>>>> >>>>>> Yes, normally, but when you write this pattern in a snippet, then >>>>>> this won't be true right, since we don't resume execution in the >>>>>> bytecode of the snippet (yet!). That why I was thinking at least a >>>>>> warning would be a good idea. >>>>>> >>>>>> -Doug >>>>>> >>>>>>> Maybe the cleanup operations could be part of a special purpose >>>>>>> deopt >>>>>> node? >>>>>>> >>>>>>> - Lukas >>>>>>> >>>>>>> Von meinem iPhone gesendet >>>>>>> >>>>>>>> Am 23.11.2013 um 16:39 schrieb Doug Simon >> : >>>>>>>> >>>>>>>> This is done by the ConvertDeoptimizeToGuardPhase which replaces >>>>>> conditionals where one branch ends in a deopt with a GuardNode. >>>>>> This does indeed have the side effect of (silently) deleting all >>>>>> other nodes on that deopt-terminated branch. We should add some >>>>>> code to either make the deletion not silent or better, throw an >>>>>> error if these are any side- effecting nodes that will be deleted. >>>>>>>> >>>>>>>> -Doug >>>>>>>> >>>>>>>>> On Nov 23, 2013, at 1:58 AM, Deneau, Tom >>>> wrote: >>>>>>>>> >>>>>>>>> I've noticed that if I have a snippet that does a test and if >>>>>>>>> the >>>>>> test fails, branches to a block that does some cleanup operations >>>>>> and then calls DeoptimizeNode.deopt(xxx, yyy), the cleanup code >>>>>> gets "optimized away". I guess this is related to what Gilles was >>>>>> talking about, maybe the cleanup operations were considered not >>>>>> state >>>> changing? >>>>>>>>> >>>>>>>>> In our current state of HSAIL backend, a deopt just returns >>>>>>>>> early >>>>>> from the kernel. Is there something I can do to make the cleanup >>>> code >>>>>> get emitted before the deopt? >>>>>>>>> >>>>>>>>> -- Tom >>>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From tom.deneau at amd.com Tue Mar 18 16:49:58 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 18 Mar 2014 16:49:58 +0000 Subject: code optimized away before a deopt In-Reply-To: <710063CF-DCD4-4328-8314-0EA798B134A6@oracle.com> References: <5C4A5B37-B6B6-4E25-9982-EA0BC543685C@oracle.com> <56957525-604C-4321-9A3D-478913744E0C@jku.at> <6E10CA9C-5B69-4A63-8164-3B086E9BDE98@oracle.com> <93452F27-3778-4397-8D82-1F7A3C7EB390@oracle.com> <710063CF-DCD4-4328-8314-0EA798B134A6@oracle.com> Message-ID: OK, thanks, that makes sense. > -----Original Message----- > From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > Sent: Tuesday, March 18, 2014 11:42 AM > To: Deneau, Tom > Cc: Douglas Simon; Lukas Stadler; graal-dev at openjdk.java.net > Subject: Re: code optimized away before a deopt > > So it's a custom node of some sort? I think you probably need make sure > it behaves like a WriteNode by implementing StateSplit and having > hasSideEffect return true. The state can be null. > > tom > > On Mar 18, 2014, at 7:57 AM, Deneau, Tom wrote: > > > Tom -- > > > > It generates an HSAIL instruction atomic_add_global (similar to lock > > xadd in x86). I don't know for sure what that becomes in the gpu > > Instructions. In rough perf measurements I made it was more > > performant than doing a similar thing using an atomic_cas loop > > > > -- Tom > >> -----Original Message----- > >> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > >> Sent: Monday, March 17, 2014 6:07 PM > >> To: Deneau, Tom > >> Cc: Douglas Simon; Lukas Stadler; graal-dev at openjdk.java.net > >> Subject: Re: code optimized away before a deopt > >> > >> How is atomicGetAndAddTlabTop actually implemented? > >> > >> tom > >> > >> On Mar 17, 2014, at 2:28 PM, Deneau, Tom wrote: > >> > >>> I'll take a look at edenAllocate logic but I was trying to avoid the > >> while(true) loop which the compareAndSwap logic requires. > >>> > >>> -- Tom > >>> > >>>> -----Original Message----- > >>>> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > >>>> Sent: Monday, March 17, 2014 4:18 PM > >>>> To: Deneau, Tom > >>>> Cc: Douglas Simon; Lukas Stadler; graal-dev at openjdk.java.net > >>>> Subject: Re: code optimized away before a deopt > >>>> > >>>> So you are using a TLAB from multiple threads so you need use > >>>> atomic's to actually do the allocation? Writing it using cleanup > >>>> logic doesn't seem right. I think should be using something like > >>>> the edenAllocate code in NewInstanceStub but against the TLAB. > >>>> Then you don't need cleanup logic. Or you could just allocate > >>>> directly from eden instead of using a TLAB. > >>>> > >>>> tom > >>>> > >>>> On Mar 17, 2014, at 1:40 PM, Deneau, Tom > wrote: > >>>> > >>>>> I was just noticing that the condition mentioned below (first > >>>> mentioned last November) still affects our snippet for > >>>> newInstanceNode lowering. When I brought this up originally our > >>>> DeoptimizeNode.deopt was not really implemented and was just making > >>>> the workitem return early. Now, DeoptimizeNode.deopt is doing the > >>>> necessary save state, etc but that doesn't change the fact that > >>>> side-effecting nodes before the deopt will get thrown away. > >>>>> > >>>>> We have a workaround that seems to work for now (additional if > >>>>> logic > >>>> around the deopt, which happens to be always true but the compiler > >>>> hasn't figured that out) but I wonder if that is a robust > workaround. > >>>> Is there already a bug filed for this, or should I file one? > >>>>> > >>>>> -- Tom > >>>>> > >>>>> Here's the workaround we have now... > >>>>> > >>>>> Object result; > >>>>> Word thread = thread(); > >>>>> Word top = atomicGetAndAddTlabTop(thread, size); > >>>>> Word end = readTlabEnd(thread); > >>>>> Word newTop = top.add(size); > >>>>> if (useTLAB() && probability(FAST_PATH_PROBABILITY, > >>>> newTop.belowOrEqual(end))) { > >>>>> // writeTlabTop(thread, newTop) was done by the > >>>> atomicGetAndAdd > >>>>> result = formatObject(hub, size, top, prototypeMarkWord, > >>>> fillContents); > >>>>> } else { > >>>>> atomicGetAndAddTlabTop(thread, -size); > >>>>> new_stub.inc(); > >>>>> // the if statement below should not be necessary, but > >>>>> when > >>>> I remove it, > >>>>> // the atomicGetAndAddTlabTop(thread, -size) doesn't get > >>>> generated. > >>>>> if (!newTop.belowOrEqual(end)) { > >>>>> DeoptimizeNode.deopt(DeoptimizationAction.None, > >>>> DeoptimizationReason.RuntimeConstraint); > >>>>> } > >>>>> . . . > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Doug Simon [mailto:doug.simon at oracle.com] > >>>>>> Sent: Saturday, November 23, 2013 10:24 AM > >>>>>> To: Lukas Stadler > >>>>>> Cc: Deneau, Tom; graal-dev at openjdk.java.net > >>>>>> Subject: Re: code optimized away before a deopt > >>>>>> > >>>>>> > >>>>>> On Nov 23, 2013, at 5:18 PM, Lukas Stadler > >>>> wrote: > >>>>>> > >>>>>>> But it _is_ ok to remove side effecting nodes, because we know > >>>>>>> they > >>>>>> will be reelected. > >>>>>> > >>>>>> Yes, normally, but when you write this pattern in a snippet, then > >>>>>> this won't be true right, since we don't resume execution in the > >>>>>> bytecode of the snippet (yet!). That why I was thinking at least > >>>>>> a warning would be a good idea. > >>>>>> > >>>>>> -Doug > >>>>>> > >>>>>>> Maybe the cleanup operations could be part of a special purpose > >>>>>>> deopt > >>>>>> node? > >>>>>>> > >>>>>>> - Lukas > >>>>>>> > >>>>>>> Von meinem iPhone gesendet > >>>>>>> > >>>>>>>> Am 23.11.2013 um 16:39 schrieb Doug Simon > >> : > >>>>>>>> > >>>>>>>> This is done by the ConvertDeoptimizeToGuardPhase which > >>>>>>>> replaces > >>>>>> conditionals where one branch ends in a deopt with a GuardNode. > >>>>>> This does indeed have the side effect of (silently) deleting all > >>>>>> other nodes on that deopt-terminated branch. We should add some > >>>>>> code to either make the deletion not silent or better, throw an > >>>>>> error if these are any side- effecting nodes that will be > deleted. > >>>>>>>> > >>>>>>>> -Doug > >>>>>>>> > >>>>>>>>> On Nov 23, 2013, at 1:58 AM, Deneau, Tom > >>>> wrote: > >>>>>>>>> > >>>>>>>>> I've noticed that if I have a snippet that does a test and if > >>>>>>>>> the > >>>>>> test fails, branches to a block that does some cleanup operations > >>>>>> and then calls DeoptimizeNode.deopt(xxx, yyy), the cleanup code > >>>>>> gets "optimized away". I guess this is related to what Gilles > >>>>>> was talking about, maybe the cleanup operations were considered > >>>>>> not state > >>>> changing? > >>>>>>>>> > >>>>>>>>> In our current state of HSAIL backend, a deopt just returns > >>>>>>>>> early > >>>>>> from the kernel. Is there something I can do to make the > cleanup > >>>> code > >>>>>> get emitted before the deopt? > >>>>>>>>> > >>>>>>>>> -- Tom > >>>>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >> > > > > > From tom.rodriguez at oracle.com Tue Mar 18 17:01:33 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 18 Mar 2014 10:01:33 -0700 Subject: code optimized away before a deopt In-Reply-To: References: <5C4A5B37-B6B6-4E25-9982-EA0BC543685C@oracle.com> <56957525-604C-4321-9A3D-478913744E0C@jku.at> <6E10CA9C-5B69-4A63-8164-3B086E9BDE98@oracle.com> <93452F27-3778-4397-8D82-1F7A3C7EB390@oracle.com> <710063CF-DCD4-4328-8314-0EA798B134A6@oracle.com> Message-ID: <335F428E-B1EB-44B6-B8FC-25C143B14F0D@oracle.com> After looking at little bit more, I think CompareAndSwapNode would be a better model which behaves as a memory checkpoint which includes the state split stuff. Chris Thalinger may be adding a node which represents lock xadd to support Unsafe.getAndSet which will probably have the semantics you want. You could probably use that once it lands. tom On Mar 18, 2014, at 9:49 AM, Deneau, Tom wrote: > OK, thanks, that makes sense. > >> -----Original Message----- >> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] >> Sent: Tuesday, March 18, 2014 11:42 AM >> To: Deneau, Tom >> Cc: Douglas Simon; Lukas Stadler; graal-dev at openjdk.java.net >> Subject: Re: code optimized away before a deopt >> >> So it's a custom node of some sort? I think you probably need make sure >> it behaves like a WriteNode by implementing StateSplit and having >> hasSideEffect return true. The state can be null. >> >> tom >> >> On Mar 18, 2014, at 7:57 AM, Deneau, Tom wrote: >> >>> Tom -- >>> >>> It generates an HSAIL instruction atomic_add_global (similar to lock >>> xadd in x86). I don't know for sure what that becomes in the gpu >>> Instructions. In rough perf measurements I made it was more >>> performant than doing a similar thing using an atomic_cas loop >>> >>> -- Tom >>>> -----Original Message----- >>>> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] >>>> Sent: Monday, March 17, 2014 6:07 PM >>>> To: Deneau, Tom >>>> Cc: Douglas Simon; Lukas Stadler; graal-dev at openjdk.java.net >>>> Subject: Re: code optimized away before a deopt >>>> >>>> How is atomicGetAndAddTlabTop actually implemented? >>>> >>>> tom >>>> >>>> On Mar 17, 2014, at 2:28 PM, Deneau, Tom wrote: >>>> >>>>> I'll take a look at edenAllocate logic but I was trying to avoid the >>>> while(true) loop which the compareAndSwap logic requires. >>>>> >>>>> -- Tom >>>>> >>>>>> -----Original Message----- >>>>>> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] >>>>>> Sent: Monday, March 17, 2014 4:18 PM >>>>>> To: Deneau, Tom >>>>>> Cc: Douglas Simon; Lukas Stadler; graal-dev at openjdk.java.net >>>>>> Subject: Re: code optimized away before a deopt >>>>>> >>>>>> So you are using a TLAB from multiple threads so you need use >>>>>> atomic's to actually do the allocation? Writing it using cleanup >>>>>> logic doesn't seem right. I think should be using something like >>>>>> the edenAllocate code in NewInstanceStub but against the TLAB. >>>>>> Then you don't need cleanup logic. Or you could just allocate >>>>>> directly from eden instead of using a TLAB. >>>>>> >>>>>> tom >>>>>> >>>>>> On Mar 17, 2014, at 1:40 PM, Deneau, Tom >> wrote: >>>>>> >>>>>>> I was just noticing that the condition mentioned below (first >>>>>> mentioned last November) still affects our snippet for >>>>>> newInstanceNode lowering. When I brought this up originally our >>>>>> DeoptimizeNode.deopt was not really implemented and was just making >>>>>> the workitem return early. Now, DeoptimizeNode.deopt is doing the >>>>>> necessary save state, etc but that doesn't change the fact that >>>>>> side-effecting nodes before the deopt will get thrown away. >>>>>>> >>>>>>> We have a workaround that seems to work for now (additional if >>>>>>> logic >>>>>> around the deopt, which happens to be always true but the compiler >>>>>> hasn't figured that out) but I wonder if that is a robust >> workaround. >>>>>> Is there already a bug filed for this, or should I file one? >>>>>>> >>>>>>> -- Tom >>>>>>> >>>>>>> Here's the workaround we have now... >>>>>>> >>>>>>> Object result; >>>>>>> Word thread = thread(); >>>>>>> Word top = atomicGetAndAddTlabTop(thread, size); >>>>>>> Word end = readTlabEnd(thread); >>>>>>> Word newTop = top.add(size); >>>>>>> if (useTLAB() && probability(FAST_PATH_PROBABILITY, >>>>>> newTop.belowOrEqual(end))) { >>>>>>> // writeTlabTop(thread, newTop) was done by the >>>>>> atomicGetAndAdd >>>>>>> result = formatObject(hub, size, top, prototypeMarkWord, >>>>>> fillContents); >>>>>>> } else { >>>>>>> atomicGetAndAddTlabTop(thread, -size); >>>>>>> new_stub.inc(); >>>>>>> // the if statement below should not be necessary, but >>>>>>> when >>>>>> I remove it, >>>>>>> // the atomicGetAndAddTlabTop(thread, -size) doesn't get >>>>>> generated. >>>>>>> if (!newTop.belowOrEqual(end)) { >>>>>>> DeoptimizeNode.deopt(DeoptimizationAction.None, >>>>>> DeoptimizationReason.RuntimeConstraint); >>>>>>> } >>>>>>> . . . >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>>>>>> Sent: Saturday, November 23, 2013 10:24 AM >>>>>>>> To: Lukas Stadler >>>>>>>> Cc: Deneau, Tom; graal-dev at openjdk.java.net >>>>>>>> Subject: Re: code optimized away before a deopt >>>>>>>> >>>>>>>> >>>>>>>> On Nov 23, 2013, at 5:18 PM, Lukas Stadler >>>>>> wrote: >>>>>>>> >>>>>>>>> But it _is_ ok to remove side effecting nodes, because we know >>>>>>>>> they >>>>>>>> will be reelected. >>>>>>>> >>>>>>>> Yes, normally, but when you write this pattern in a snippet, then >>>>>>>> this won't be true right, since we don't resume execution in the >>>>>>>> bytecode of the snippet (yet!). That why I was thinking at least >>>>>>>> a warning would be a good idea. >>>>>>>> >>>>>>>> -Doug >>>>>>>> >>>>>>>>> Maybe the cleanup operations could be part of a special purpose >>>>>>>>> deopt >>>>>>>> node? >>>>>>>>> >>>>>>>>> - Lukas >>>>>>>>> >>>>>>>>> Von meinem iPhone gesendet >>>>>>>>> >>>>>>>>>> Am 23.11.2013 um 16:39 schrieb Doug Simon >>>> : >>>>>>>>>> >>>>>>>>>> This is done by the ConvertDeoptimizeToGuardPhase which >>>>>>>>>> replaces >>>>>>>> conditionals where one branch ends in a deopt with a GuardNode. >>>>>>>> This does indeed have the side effect of (silently) deleting all >>>>>>>> other nodes on that deopt-terminated branch. We should add some >>>>>>>> code to either make the deletion not silent or better, throw an >>>>>>>> error if these are any side- effecting nodes that will be >> deleted. >>>>>>>>>> >>>>>>>>>> -Doug >>>>>>>>>> >>>>>>>>>>> On Nov 23, 2013, at 1:58 AM, Deneau, Tom >>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> I've noticed that if I have a snippet that does a test and if >>>>>>>>>>> the >>>>>>>> test fails, branches to a block that does some cleanup operations >>>>>>>> and then calls DeoptimizeNode.deopt(xxx, yyy), the cleanup code >>>>>>>> gets "optimized away". I guess this is related to what Gilles >>>>>>>> was talking about, maybe the cleanup operations were considered >>>>>>>> not state >>>>>> changing? >>>>>>>>>>> >>>>>>>>>>> In our current state of HSAIL backend, a deopt just returns >>>>>>>>>>> early >>>>>>>> from the kernel. Is there something I can do to make the >> cleanup >>>>>> code >>>>>>>> get emitted before the deopt? >>>>>>>>>>> >>>>>>>>>>> -- Tom >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From juan.fumero at ed.ac.uk Tue Mar 18 17:17:33 2014 From: juan.fumero at ed.ac.uk (Juan Jose Fumero) Date: Tue, 18 Mar 2014 17:17:33 +0000 Subject: Nodes in Graal: ParameterNode Message-ID: <1395163053.29018.17.camel@gofio> Hello, I am working with lambda expression on JDK8 and Graal. My question is related with the creation of new nodes in the Graph to update or change the information. Given this lambda expression: stream.map((x,y) -> x + y); The StructuredGraph is the following: 0|StartNode 1|Parameter(0) 2|Parameter(1) 3|FrameState at 0 4|MethodCallTarget 5|Invoke#intValue 6|FrameState at 4 8|MethodCallTarget 9|Invoke#intValue 10|FrameState at 8 12|+ 13|MethodCallTarget 14|Invoke#valueOf 15|FrameState at 12 17|Return 13|Invoke#valueOf Parameter(0) and Parameter(1) are Objects in the moment that I get the lambda expression. But later on, I know that could be Integer[], Double[], etc. I would like to rewrite this part of the Graph with the new information. Is there any utility in Graal to do that? For instance: if I get the parameterNode from the previous graph: if (((ObjectStamp) parameterNode.stamp()).type().isArray()) { ... } The nodes Parameter(0) and Parameter(1) in the lambda expression are not arrays. What I want to do is to change or update these nodes. What I am using now is a new node (paramNode): IntegerStamp integerStamp = new IntegerStamp(Kind.Int); ParameterNode paramNode = new ParameterNode(index, integerStamp); newGraph.unique(paramNode); But I need also to store the array information (size and dimension). The aim is facilitates the OpenCL code generation from this expression. Many thanks Juanjo -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From jules_gosnell at yahoo.com Tue Mar 18 21:26:31 2014 From: jules_gosnell at yahoo.com (Jules Gosnell) Date: Tue, 18 Mar 2014 21:26:31 +0000 Subject: Graal and Clojure In-Reply-To: <53277532.3030807@amd.com> References: <1394063789.8387.YahooMailNeo@web122406.mail.ne1.yahoo.com> <5326354D.8010204@yahoo.com> <53277532.3030807@amd.com> Message-ID: <5328BA07.6030100@yahoo.com> Eric, Thanks for checking out Clumatra :-) : https://github.com/JulesGosnell/clumatra I'm only just getting it off the ground at the moment, so I'm afraid that there is not much there yet. Its aim is to promote Clojure/Sumatra/Graal friendliness and I hope, ensure that Clojure can take advantage of all the benefits of HSA as soon as Java9 comes out. OK - that's the plug over with - now to your questions. 1. enabling a real 'finalizer' instead of the Okra simulator - Hmmm... I haven't bought my HSA box yet - it is still a wishlist on Amazon. So I have not been able to try this yet. However, I get the feeling from looking at the Okra src, that it might detect if the finalizer is available and switch over for you. The OkraContext has an isSimulator() method on it. So it must be able to run in simulated and some other mode ... I think the HSAIL->GPU finalizer is available in one of the AMD d/ls - you probably have it already... I'll log something about whether we are on a simulator or not in the test harness. - There might be a -X flag to the jvm to enable a finalizer... 2. I'll have to dig around in the Clojure test harness to see if it can be integrated with junit - otherwise I'll have to switch over. I can see the obvious benefit in being able to kick these tests off in your debugger. I'll look into it. 3. I'm glad that it is helping uncover issues. I have added a few more test today and will keep building. I'm looking forward to getting more and more of the stack runnning. I have a few thoughts / questions - if I may :-) Is there a web page on which you guys are ticking off each bytecode instruction as it is implemented ? This would be a help to me when I have a test that fails. I can look at the page to see if it should work or not. What might I reasonably expect to get working eventually ? I'm assuming that there are limits to what can be done on the GPU - I'm assuming that i/o for instance is not feasible etc... Is there some sort of a road map published anywhere that I could take a peek at ? I think that is enough for the moment, Thanks again, Eric, for your interest in Clumatra - I look forward to working with you guys to get Clojure and Graal to work well together. Jules On 17/03/14 22:20, Eric Caspole wrote: > Hi everybody, > I was setting up a new HSA system today and I installed Clumatra and got > it working under the simulator. I have a real HSA system not too > different from this: > > http://code.google.com/p/aparapi/wiki/SettingUpLinuxHSAMachineForAparapi > > In the clojure/lein/maven based system there is so much harness I can't > immediately see how to switch in the real hardware version of Okra > instead of the simulator Okra that gets installed into maven and > exploded in /tmp when the tests run. > > Jules, could you show how to bypass the harness etc to switch the Okra? > Can I just run 1 test with a simple java command line? This makes it a > lot easier to use a debugger which I will definitely want to do. > > Otherwise this is a cool project and we already found 1 or 2 issues we > can fix in HSAIL Graal related to your clojure tests. > Regards, > Eric > > > > On 03/17/2014 06:43 AM, Doug Simon wrote: >> Hi Julian, >> >> In terms of what to test, I?ll leave it up to the Sumatra developers >> at AMD and Oracle to comment on what may be interesting. >> >> As far as I know, no one in the Graal team is that familiar with >> Clojure. This actually makes the value of having Clojure tests >> integrated into our gate system somewhat problematic - >> debugging/fixing failures may be difficult. I?d suggest you report >> failures your discover on the sumatra-dev and graal-dev lists and we >> can resolve them that way for now. >> >> In addition, for Graal we?re always interested in benchmark suites for >> JVM hosted languages. Can you recommend any well known and trusted >> Clojure benchmarks we should consider? >> >> -Doug >> >> On Mar 17, 2014, at 12:35 AM, Jules Gosnell >> wrote: >> >>> Doug, >>> >>> Sorry it has taken me a while to get back - I've been busy playing >>> with code. >>> >>> I currently have a small clojure testsuite up and running. I plan to >>> broaden this and then think about providing it in a junit-compatible >>> way to your project. >>> >>> I still haven't made up my mind exactly what I should be testing. It >>> seems unnecessary to duplicate all your tests in Clojure, since you >>> are already guarding against regression in these areas - I think I >>> will start out with a fairly general set of tests as I probe for >>> particular problem areas for Clojure, into which I may dive for more >>> detail - time will tell... if you have any ideas, please let me know. >>> >>> I've checked my stuff in at github, if anyone is interested - here is >>> the project: >>> >>> https://github.com/JulesGosnell/clumatra >>> >>> here is some clojure that I reverse engineered from GraalKernelTester: >>> >>> https://github.com/JulesGosnell/clumatra/blob/master/src/clumatra/core.clj >>> >>> >>> and here are the first successful tests: >>> >>> https://github.com/JulesGosnell/clumatra/blob/master/test/clumatra/core_test.clj >>> >>> >>> not very pretty yet - I am still feeling my way. >>> >>> cheers >>> >>> >>> Jules >>> >>> >>> >>> >>> On 06/03/14 10:24, Doug Simon wrote: >>>> Hi Julian, >>>> >>>> This looks very interesting and will be an good alternative testing >>>> vector for the Sumatra work as it matures. If Clojure tests can >>>> somehow be made to run from Junit, then I?m sure we can try >>>> integrating it into our testing. >>>> >>>> -Doug >>>> >>>> On Mar 6, 2014, at 12:56 AM, Julian Gosnell >>>> wrote: >>>> >>>>> Guys, >>>>> >>>>> I just built the Java8 / Graal / Okra stack and managed to run some >>>>> very simple Clojure copying the contents of one int array into >>>>> another one on Okra. >>>>> >>>>> https://groups.google.com/forum/#!topic/clojure/JpjK__NTR5Y >>>>> >>>>> >>>>> I find the ramifications of this very exciting :-) >>>>> >>>>> I understand that fn-ality is limited at the moment - but I am keen >>>>> to keep testing and to help ensure early visibility of Clojure >>>>> related issues to both communities - perhaps even the submission of >>>>> a Clojure testsuite if Graal developers thought that useful. >>>>> >>>>> I'd be very interested in your thoughts on Graal / Clojure. >>>>> >>>>> regards, >>>>> >>>>> >>>>> Jules >>>>> >>>> >>>> >>> >> >> > > From tom.deneau at amd.com Tue Mar 18 21:56:26 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 18 Mar 2014 21:56:26 +0000 Subject: NullPointerException in ControlFlowGraph.commonDominator during SchedulePhase Message-ID: I noticed in some hsail junit tests that were storing objects that I didn't see the card table setting code. I remember this was working about 4 months ago but we haven't really looked at Object Storing junits since then and I know a lot of the infrastructure has changed since then. Anyway in igv I noticed that the WriteBarrierAdditionPhase was not one of the phases for hsail compileGraph. Previously the setup in HSAILHotSpotBackendFactory was SuitesProvider suites = new DefaultSuitesProvider(); which I changed to the following to make it match more the AMD64HotSpotBackendFactory SuitesProvider suites = new HotSpotSuitesProvider(runtime); This seemed to do the trick as far as generating the card table stores, but now I notice when I run with -G:Dump=, I get a NullPointerException during the SchedulePhase [1] com.oracle.graal.nodes.cfg.ControlFlowGraph.commonDominator (ControlFlowGraph.java:336) [2] com.oracle.graal.phases.schedule.SchedulePhase$CommonDominatorBlockClosure.apply (SchedulePhase.java:625) [3] com.oracle.graal.phases.schedule.SchedulePhase.blocksForUsage (SchedulePhase.java:780) [4] com.oracle.graal.phases.schedule.SchedulePhase.latestBlock (SchedulePhase.java:599) [5] com.oracle.graal.phases.schedule.SchedulePhase.assignBlockToNode (SchedulePhase.java:417) [6] com.oracle.graal.phases.schedule.SchedulePhase.assignBlockToNodes (SchedulePhase.java:379) [7] com.oracle.graal.phases.schedule.SchedulePhase.run (SchedulePhase.java:273) I admit I didn't really look at all the differences between DefaultSuitesProvider and HotSpotSuitesProvider(runtime) but does anyone have any suggestions as to what might be causing this? -- Tom From jules_gosnell at yahoo.com Tue Mar 18 22:47:42 2014 From: jules_gosnell at yahoo.com (Jules Gosnell) Date: Tue, 18 Mar 2014 22:47:42 +0000 Subject: Graal and Clojure In-Reply-To: <5328BA07.6030100@yahoo.com> References: <1394063789.8387.YahooMailNeo@web122406.mail.ne1.yahoo.com> <5326354D.8010204@yahoo.com> <53277532.3030807@amd.com> <5328BA07.6030100@yahoo.com> Message-ID: <5328CD0E.2040206@yahoo.com> Eric, I've just added a -Dsumatra.verbose flag - it is set in the project.clj. When set, Okra is asked to be verbose about the HSAIL generation and I also print the disassembled bytecode that Okra is about to compile. I have updated the readme accordingly. Okra also logs whether it is running in simulated or native mode. I'll give the JUnit / launch from CLI some thought now. regards Jules On 18/03/14 21:26, Jules Gosnell wrote: > Eric, > > Thanks for checking out Clumatra :-) : > > https://github.com/JulesGosnell/clumatra > > I'm only just getting it off the ground at the moment, so I'm afraid > that there is not much there yet. > > Its aim is to promote Clojure/Sumatra/Graal friendliness and I hope, > ensure that Clojure can take advantage of all the benefits of HSA as > soon as Java9 comes out. > > OK - that's the plug over with - now to your questions. > > 1. enabling a real 'finalizer' instead of the Okra simulator - Hmmm... I > haven't bought my HSA box yet - it is still a wishlist on Amazon. So I > have not been able to try this yet. However, I get the feeling from > looking at the Okra src, that it might detect if the finalizer is > available and switch over for you. The OkraContext has an isSimulator() > method on it. So it must be able to run in simulated and some other mode > ... I think the HSAIL->GPU finalizer is available in one of the AMD d/ls > - you probably have it already... I'll log something about whether we > are on a simulator or not in the test harness. - There might be a -X > flag to the jvm to enable a finalizer... > > 2. I'll have to dig around in the Clojure test harness to see if it can > be integrated with junit - otherwise I'll have to switch over. I can see > the obvious benefit in being able to kick these tests off in your > debugger. I'll look into it. > > 3. I'm glad that it is helping uncover issues. I have added a few more > test today and will keep building. I'm looking forward to getting more > and more of the stack runnning. > > I have a few thoughts / questions - if I may :-) > > Is there a web page on which you guys are ticking off each bytecode > instruction as it is implemented ? This would be a help to me when I > have a test that fails. I can look at the page to see if it should work > or not. > > What might I reasonably expect to get working eventually ? I'm assuming > that there are limits to what can be done on the GPU - I'm assuming that > i/o for instance is not feasible etc... Is there some sort of a road map > published anywhere that I could take a peek at ? > > I think that is enough for the moment, > > Thanks again, Eric, for your interest in Clumatra - I look forward to > working with you guys to get Clojure and Graal to work well together. > > > Jules > > > > > On 17/03/14 22:20, Eric Caspole wrote: >> Hi everybody, >> I was setting up a new HSA system today and I installed Clumatra and got >> it working under the simulator. I have a real HSA system not too >> different from this: >> >> http://code.google.com/p/aparapi/wiki/SettingUpLinuxHSAMachineForAparapi >> >> In the clojure/lein/maven based system there is so much harness I can't >> immediately see how to switch in the real hardware version of Okra >> instead of the simulator Okra that gets installed into maven and >> exploded in /tmp when the tests run. >> >> Jules, could you show how to bypass the harness etc to switch the Okra? >> Can I just run 1 test with a simple java command line? This makes it a >> lot easier to use a debugger which I will definitely want to do. >> >> Otherwise this is a cool project and we already found 1 or 2 issues we >> can fix in HSAIL Graal related to your clojure tests. >> Regards, >> Eric >> >> >> >> On 03/17/2014 06:43 AM, Doug Simon wrote: >>> Hi Julian, >>> >>> In terms of what to test, I?ll leave it up to the Sumatra developers >>> at AMD and Oracle to comment on what may be interesting. >>> >>> As far as I know, no one in the Graal team is that familiar with >>> Clojure. This actually makes the value of having Clojure tests >>> integrated into our gate system somewhat problematic - >>> debugging/fixing failures may be difficult. I?d suggest you report >>> failures your discover on the sumatra-dev and graal-dev lists and we >>> can resolve them that way for now. >>> >>> In addition, for Graal we?re always interested in benchmark suites for >>> JVM hosted languages. Can you recommend any well known and trusted >>> Clojure benchmarks we should consider? >>> >>> -Doug >>> >>> On Mar 17, 2014, at 12:35 AM, Jules Gosnell >>> wrote: >>> >>>> Doug, >>>> >>>> Sorry it has taken me a while to get back - I've been busy playing >>>> with code. >>>> >>>> I currently have a small clojure testsuite up and running. I plan to >>>> broaden this and then think about providing it in a junit-compatible >>>> way to your project. >>>> >>>> I still haven't made up my mind exactly what I should be testing. It >>>> seems unnecessary to duplicate all your tests in Clojure, since you >>>> are already guarding against regression in these areas - I think I >>>> will start out with a fairly general set of tests as I probe for >>>> particular problem areas for Clojure, into which I may dive for more >>>> detail - time will tell... if you have any ideas, please let me know. >>>> >>>> I've checked my stuff in at github, if anyone is interested - here is >>>> the project: >>>> >>>> https://github.com/JulesGosnell/clumatra >>>> >>>> here is some clojure that I reverse engineered from GraalKernelTester: >>>> >>>> https://github.com/JulesGosnell/clumatra/blob/master/src/clumatra/core.clj >>>> >>>> >>>> >>>> and here are the first successful tests: >>>> >>>> https://github.com/JulesGosnell/clumatra/blob/master/test/clumatra/core_test.clj >>>> >>>> >>>> >>>> not very pretty yet - I am still feeling my way. >>>> >>>> cheers >>>> >>>> >>>> Jules >>>> >>>> >>>> >>>> >>>> On 06/03/14 10:24, Doug Simon wrote: >>>>> Hi Julian, >>>>> >>>>> This looks very interesting and will be an good alternative testing >>>>> vector for the Sumatra work as it matures. If Clojure tests can >>>>> somehow be made to run from Junit, then I?m sure we can try >>>>> integrating it into our testing. >>>>> >>>>> -Doug >>>>> >>>>> On Mar 6, 2014, at 12:56 AM, Julian Gosnell >>>>> wrote: >>>>> >>>>>> Guys, >>>>>> >>>>>> I just built the Java8 / Graal / Okra stack and managed to run some >>>>>> very simple Clojure copying the contents of one int array into >>>>>> another one on Okra. >>>>>> >>>>>> https://groups.google.com/forum/#!topic/clojure/JpjK__NTR5Y >>>>>> >>>>>> >>>>>> I find the ramifications of this very exciting :-) >>>>>> >>>>>> I understand that fn-ality is limited at the moment - but I am keen >>>>>> to keep testing and to help ensure early visibility of Clojure >>>>>> related issues to both communities - perhaps even the submission of >>>>>> a Clojure testsuite if Graal developers thought that useful. >>>>>> >>>>>> I'd be very interested in your thoughts on Graal / Clojure. >>>>>> >>>>>> regards, >>>>>> >>>>>> >>>>>> Jules >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> > From doug.simon at oracle.com Wed Mar 19 02:00:09 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 19 Mar 2014 02:00:09 +0000 Subject: hg: graal/graal: 35 new changesets Message-ID: <201403190200.s2J20tiU024016@aojmv0008> Changeset: f5c368c08508 Author: Lukas Stadler Date: 2014-03-18 09:55 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f5c368c08508 fix typo ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ObjectLocationIdentity.java Changeset: 00d1f5391b2e Author: Lukas Stadler Date: 2014-03-18 09:56 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/00d1f5391b2e relax assertion in emitNullCheck to Kind.Object to allow for IllegalStamp ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java Changeset: 532d9b78c7d4 Author: Lukas Stadler Date: 2014-03-18 09:57 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/532d9b78c7d4 assert that only live ValueNodes are added as inputs and successors ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java Changeset: d927132f45a4 Author: Lukas Stadler Date: 2014-03-18 09:59 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d927132f45a4 update comments on BenchmarkCounters (-XX options instead of preprocessor defs) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/debug/BenchmarkCounters.java Changeset: c98fa2ed91d9 Author: Lukas Stadler Date: 2014-03-18 10:00 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c98fa2ed91d9 fix return type of createOutOfBoundsException foreign call ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: a15776cb4e6c Author: Lukas Stadler Date: 2014-03-18 10:01 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a15776cb4e6c small additional null check in GraphPrinterDumpHandler ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java Changeset: 69dfb976fd26 Author: Lukas Stadler Date: 2014-03-18 10:04 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/69dfb976fd26 clean state before merging iteration in PEA MergeProcessor ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/loop/LoopParseLong.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java Changeset: 5fc6b8b54d82 Author: Doug Simon Date: 2014-03-18 12:39 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5fc6b8b54d82 reduced overhead of Debug.metric() and Debug.timer() when no metrics or timers are enabled ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java Changeset: 2ec76bd5f309 Author: Andreas Woess Date: 2014-03-18 12:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2ec76bd5f309 fix windows compiler warning (C4800) ! src/share/vm/graal/graalCodeInstaller.cpp Changeset: 6189c1983cd3 Author: Andreas Woess Date: 2014-03-18 13:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6189c1983cd3 Truffle: make Node#replace accept any CharSequence as reason ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/ReplaceObserver.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/CallNode.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java Changeset: 7e9409cb656f Author: Lukas Stadler Date: 2014-03-18 16:35 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7e9409cb656f make ArrayEqualsNode fixed instead of floating ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/ArraysSubstitutionsTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/ArrayEqualsNode.java Changeset: d2fe05d5cc96 Author: Doug Simon Date: 2014-03-18 17:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d2fe05d5cc96 added support for lazy computation of names for use with Debug ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugConfig.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugHistogram.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugScope.java + graal/com.oracle.graal.phases/src/com/oracle/graal/phases/LazyName.java Changeset: 8a6612e8e1e1 Author: Doug Simon Date: 2014-03-18 17:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8a6612e8e1e1 use lazy names in BasePhase ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/BasePhase.java Changeset: 3ef845ec7771 Author: Doug Simon Date: 2014-03-18 17:16 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3ef845ec7771 guard call to Debug.dump ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsPhase.java Changeset: 90b43a808eb0 Author: Doug Simon Date: 2014-03-18 18:02 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/90b43a808eb0 use lazy names for snippet and replacements related debug values + graal/com.oracle.graal.phases/src/com/oracle/graal/phases/util/MethodDebugValueName.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: e754ac1331ef Author: Tom Rodriguez Date: 2014-03-13 15:38 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e754ac1331ef fix string contains call ! mx/mx_graal.py Changeset: dbe41340d0a6 Author: Tom Rodriguez Date: 2014-03-13 15:40 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/dbe41340d0a6 eliminate sequential reinterprets ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ReinterpretNode.java Changeset: a23ca654a882 Author: Tom Rodriguez Date: 2014-03-13 15:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a23ca654a882 fix array length load location identity ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotLoweringProvider.java Changeset: 9e05e9770c1e Author: Tom Rodriguez Date: 2014-03-18 09:48 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9e05e9770c1e eliminate useless masking ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/AndNode.java Changeset: 3eda945af90a Author: Tom Rodriguez Date: 2014-03-18 11:07 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3eda945af90a dump final HIR schedule to c1visualizer ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.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 Changeset: ff2095ec7bdb Author: Tom Rodriguez Date: 2014-03-18 11:51 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ff2095ec7bdb Merge ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/Marks.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotLoweringProvider.java - graal/com.oracle.graal.java.decompiler.test/src/com/oracle/graal/java/decompiler/test/Test.java ! mx/mx_graal.py Changeset: 2e35f6eb8684 Author: Christian Humer Date: 2014-03-18 18:13 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2e35f6eb8684 Fixed option processor to always produce unix line feeds which led to checkstyle warnings on windows. ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionProcessor.java Changeset: 918b0360bdb2 Author: Christian Humer Date: 2014-03-18 19:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/918b0360bdb2 Merge. Changeset: 40eedef0a586 Author: Christian Humer Date: 2014-03-18 19:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/40eedef0a586 Truffle-DSL: fixed some findbugs errors for (CR-2223) ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: fdabadc7980d Author: Christian Humer Date: 2014-03-18 20:35 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/fdabadc7980d Truffle-DSL: fixed wrong generation of costs for polymorphic nodes. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: d5cae5698316 Author: Christian Humer Date: 2014-03-18 20:36 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d5cae5698316 Truffle: fixed indefinite splitting of recursive calls. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallNodeProfile.java Changeset: e845cd0b033f Author: Christian Humer Date: 2014-03-18 20:36 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e845cd0b033f Merge. Changeset: 591f4a575ebf Author: Doug Simon Date: 2014-03-18 22:50 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/591f4a575ebf issue warning/error where ever relevant if a non-supported VM (e.g., client VM on Mac) is used in mx ! mx/mx_graal.py Changeset: a378e5922932 Author: Doug Simon Date: 2014-03-18 22:51 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a378e5922932 take into account BasePhase subclasses whose name does not end with "Phase" ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/BasePhase.java Changeset: bd7cf02d1756 Author: Doug Simon Date: 2014-03-18 22:56 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bd7cf02d1756 added fast path for HotSpotResolvedObjectType.resolveMethod() when the receiver is the declarer of the method ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java Changeset: 5953ac9e0d93 Author: Doug Simon Date: 2014-03-18 22:58 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5953ac9e0d93 fixed pylint errors ! mx/mx_graal.py Changeset: f50dece27798 Author: Doug Simon Date: 2014-03-18 23:50 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f50dece27798 fixed regression in gate command ! mx/mx_graal.py Changeset: 7573ba6dfba2 Author: Tom Rodriguez Date: 2014-03-18 15:32 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7573ba6dfba2 fix comment ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java Changeset: 682fba1bcf95 Author: Tom Rodriguez Date: 2014-03-18 15:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/682fba1bcf95 add missing null check in is_interrupted ! src/share/vm/graal/graalRuntime.cpp Changeset: a65db4b0d185 Author: Tom Rodriguez Date: 2014-03-18 16:45 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a65db4b0d185 Merge From duboscq at ssw.jku.at Wed Mar 19 10:49:11 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Wed, 19 Mar 2014 11:49:11 +0100 Subject: Nodes in Graal: ParameterNode In-Reply-To: <1395163053.29018.17.camel@gofio> References: <1395163053.29018.17.camel@gofio> Message-ID: Hello, The graph you present is the code for: Integer foo(Integer x, Integer y) { return x + y; } There are no arrays involved and you can not force the parameters to be arrays, that would just not work. If you want to work with integer streams you can use IntStream which will allow you to work without the boxing (even for the lambdas). I'm not sure what the example should do exactly since map seems to only accept unary functions. In any case, this lambda would be the kernel which is the "what to run" and thus does not/can not contain any information about "what to run *on*". This information can only be available in the code which is applying this lambda to some specific data. Maybe you can give a small example of what you would like to achieve from java code to OpenCL code? -Gilles On Tue, Mar 18, 2014 at 6:17 PM, Juan Jose Fumero wrote: > Hello, > I am working with lambda expression on JDK8 and Graal. My question is > related with the creation of new nodes in the Graph to update or change > the information. > > > Given this lambda expression: > > stream.map((x,y) -> x + y); > > The StructuredGraph is the following: > > 0|StartNode > 1|Parameter(0) > 2|Parameter(1) > 3|FrameState at 0 > 4|MethodCallTarget > 5|Invoke#intValue > 6|FrameState at 4 > 8|MethodCallTarget > 9|Invoke#intValue > 10|FrameState at 8 > 12|+ > 13|MethodCallTarget > 14|Invoke#valueOf > 15|FrameState at 12 > 17|Return > 13|Invoke#valueOf > > > Parameter(0) and Parameter(1) are Objects in the moment that I get the > lambda expression. But later on, I know that could be Integer[], > Double[], etc. > > I would like to rewrite this part of the Graph with the new information. > Is there any utility in Graal to do that? > > > For instance: if I get the parameterNode from the previous graph: > > if (((ObjectStamp) parameterNode.stamp()).type().isArray()) { > ... > } > > > The nodes Parameter(0) and Parameter(1) in the lambda expression are not > arrays. What I want to do is to change or update these nodes. What I am > using now is a new node (paramNode): > > > IntegerStamp integerStamp = new IntegerStamp(Kind.Int); > ParameterNode paramNode = new ParameterNode(index, integerStamp); > newGraph.unique(paramNode); > > But I need also to store the array information (size and dimension). The > aim is facilitates the OpenCL code generation from this expression. > > > Many thanks > Juanjo > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > From duboscq at ssw.jku.at Wed Mar 19 11:01:38 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Wed, 19 Mar 2014 12:01:38 +0100 Subject: NullPointerException in ControlFlowGraph.commonDominator during SchedulePhase In-Reply-To: References: Message-ID: Hello Tom, Do you have any more context (full stack trace)? When dumping, there can be exceptions in the schedules that are used for dumping but those should in theory just be ignored. -Gilles On Tue, Mar 18, 2014 at 10:56 PM, Tom Deneau wrote: > I noticed in some hsail junit tests that were storing objects that I didn't see the card table setting code. I remember this was working about 4 months ago but we haven't really looked at Object Storing junits since then and I know a lot of the infrastructure has changed since then. Anyway in igv I noticed that the WriteBarrierAdditionPhase was not one of the phases for hsail compileGraph. > > Previously the setup in HSAILHotSpotBackendFactory was > SuitesProvider suites = new DefaultSuitesProvider(); > > which I changed to the following to make it match more the AMD64HotSpotBackendFactory > SuitesProvider suites = new HotSpotSuitesProvider(runtime); > > This seemed to do the trick as far as generating the card table stores, but now I notice when I run with -G:Dump=, I get a NullPointerException during the SchedulePhase > > > [1] com.oracle.graal.nodes.cfg.ControlFlowGraph.commonDominator (ControlFlowGraph.java:336) > [2] com.oracle.graal.phases.schedule.SchedulePhase$CommonDominatorBlockClosure.apply (SchedulePhase.java:625) > [3] com.oracle.graal.phases.schedule.SchedulePhase.blocksForUsage (SchedulePhase.java:780) > [4] com.oracle.graal.phases.schedule.SchedulePhase.latestBlock (SchedulePhase.java:599) > [5] com.oracle.graal.phases.schedule.SchedulePhase.assignBlockToNode (SchedulePhase.java:417) > [6] com.oracle.graal.phases.schedule.SchedulePhase.assignBlockToNodes (SchedulePhase.java:379) > [7] com.oracle.graal.phases.schedule.SchedulePhase.run (SchedulePhase.java:273) > > I admit I didn't really look at all the differences between DefaultSuitesProvider and HotSpotSuitesProvider(runtime) but does anyone have any suggestions as to what might be causing this? > > -- Tom > From Eric.Caspole at amd.com Wed Mar 19 12:54:39 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Wed, 19 Mar 2014 12:54:39 +0000 Subject: new webrev for HSAILHotSpotLIRGenerator small fixes Message-ID: Hi everybody, I put a new webrev here - http://cr.openjdk.java.net/~ecaspole/hsail_lir/webrev/ This fixes 2 issues I found while trying Clumatra: storing compressed constants was not implemented yet (thanks Tom D for this), and previously HSAILHotSpotLIRGenerator did not "implements HotSpotLIRGenerator" so some methods would fail to compile with ClassCastExceptions in the middle of compilation. I implemented dummy stubs for all that that throws NYI instead. Regards, Eric From juan.fumero at ed.ac.uk Wed Mar 19 14:16:18 2014 From: juan.fumero at ed.ac.uk (Juan Jose Fumero) Date: Wed, 19 Mar 2014 14:16:18 +0000 Subject: Nodes in Graal: ParameterNode In-Reply-To: References: <1395163053.29018.17.camel@gofio> Message-ID: <1395238578.29018.44.camel@gofio> Hello, Thanks Gilles for your explanation. As you said, map in stream.util is IntUnaryOperator. What I am using now is BiFunction. Maybe I should change to a specific one as IntBinaryOperator. More specifically I am trying is this (this is an example): // Vector Addition Stream stream = new Stream<>(); stream.map((x,y) -> x + y).run(input); This is now running in CPU with my library. This map does not have side effects and each operation returns a new Stream. When the run is called, the pipeline is executed. What I am trying is to generate OpenCL code from the map lambda expression, but I need to "transform" or replace Parameters x and y to Arrays for example. Is there other ways available in Graal? Thanks Juanjo On Wed, 2014-03-19 at 11:49 +0100, Gilles Duboscq wrote: > Hello, > > The graph you present is the code for: > > Integer foo(Integer x, Integer y) { > return x + y; > } > > There are no arrays involved and you can not force the parameters to > be arrays, that would just not work. > > If you want to work with integer streams you can use IntStream which > will allow you to work without the boxing (even for the lambdas). > I'm not sure what the example should do exactly since map seems to > only accept unary functions. > In any case, this lambda would be the kernel which is the "what to > run" and thus does not/can not contain any information about "what to > run *on*". > This information can only be available in the code which is applying > this lambda to some specific data. > > Maybe you can give a small example of what you would like to achieve > from java code to OpenCL code? > > -Gilles > > On Tue, Mar 18, 2014 at 6:17 PM, Juan Jose Fumero wrote: > > Hello, > > I am working with lambda expression on JDK8 and Graal. My question is > > related with the creation of new nodes in the Graph to update or change > > the information. > > > > > > Given this lambda expression: > > > > stream.map((x,y) -> x + y); > > > > The StructuredGraph is the following: > > > > 0|StartNode > > 1|Parameter(0) > > 2|Parameter(1) > > 3|FrameState at 0 > > 4|MethodCallTarget > > 5|Invoke#intValue > > 6|FrameState at 4 > > 8|MethodCallTarget > > 9|Invoke#intValue > > 10|FrameState at 8 > > 12|+ > > 13|MethodCallTarget > > 14|Invoke#valueOf > > 15|FrameState at 12 > > 17|Return > > 13|Invoke#valueOf > > > > > > Parameter(0) and Parameter(1) are Objects in the moment that I get the > > lambda expression. But later on, I know that could be Integer[], > > Double[], etc. > > > > I would like to rewrite this part of the Graph with the new information. > > Is there any utility in Graal to do that? > > > > > > For instance: if I get the parameterNode from the previous graph: > > > > if (((ObjectStamp) parameterNode.stamp()).type().isArray()) { > > ... > > } > > > > > > The nodes Parameter(0) and Parameter(1) in the lambda expression are not > > arrays. What I want to do is to change or update these nodes. What I am > > using now is a new node (paramNode): > > > > > > IntegerStamp integerStamp = new IntegerStamp(Kind.Int); > > ParameterNode paramNode = new ParameterNode(index, integerStamp); > > newGraph.unique(paramNode); > > > > But I need also to store the array information (size and dimension). The > > aim is facilitates the OpenCL code generation from this expression. > > > > > > Many thanks > > Juanjo > > > > > > -- > > The University of Edinburgh is a charitable body, registered in > > Scotland, with registration number SC005336. > > > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From doug.simon at oracle.com Wed Mar 19 15:12:08 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 19 Mar 2014 15:12:08 +0000 Subject: hg: graal/graal: 4 new changesets Message-ID: <201403191512.s2JFCEXX021323@aojmv0008> Changeset: aef9e4224076 Author: Lukas Stadler Date: 2014-03-19 09:08 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/aef9e4224076 refactored state cleaning in PEA MergeProcessor ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java Changeset: 1d853e629891 Author: Lukas Stadler Date: 2014-03-19 12:01 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1d853e629891 fixed canonicalization of ArrayEqualsNode, added Virtualizable implementation ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/ArraysSubstitutionsTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/ArrayEqualsNode.java Changeset: 3c8de2692867 Author: Bernhard Urban Date: 2014-03-19 11:07 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3c8de2692867 TruffleCompiler: print hint if hitting the assertion ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java Changeset: f3f4aaa4f480 Author: Bernhard Urban Date: 2014-03-19 15:26 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f3f4aaa4f480 AbstractNewObjectNode: simplification should not remove a node more than once + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PoorMansEATest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AbstractNewObjectNode.java From tom.deneau at amd.com Wed Mar 19 16:31:03 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 19 Mar 2014 16:31:03 +0000 Subject: NullPointerException in ControlFlowGraph.commonDominator during SchedulePhase In-Reply-To: References: Message-ID: Gilles -- You're right, the nullPointerException in my original email was caught... Here's a fuller stack trace... I notice it is coming from the compileGraph for the host trampoline code. But I don't understand why changing the SuitesProvider for the hsail compilation should affect this. (and I only see it with -G:Dump=) -- Tom There was 1 failure: 1) test(com.oracle.graal.compiler.hsail.test.EscapingNewVec3Test) com.oracle.graal.graph.GraalInternalError: java.lang.RuntimeException: Exception while intercepting exception at node: 17|VMError at com.oracle.graal.compiler.gen.LIRGenerator.doBlock(LIRGenerator.java:453) at com.oracle.graal.compiler.GraalCompiler.emitBlock(GraalCompiler.java:215) at com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:246) at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:149) at com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.installKernel(HSAILHotSpotBackend.java:263) at com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.compileAndInstallKernel(HSAILHotSpotBackend.java:142) at com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.dispatchKernelOkra(GraalKernelTester.java:115) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchMethodKernelOkra(KernelTester.java:635) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchMethodKernel(KernelTester.java:370) at com.oracle.graal.compiler.hsail.test.EscapingNewVec3Base.runTest(EscapingNewVec3Base.java:32) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.runOkraInstance(KernelTester.java:786) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.compareOkraToSeq(KernelTester.java:776) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.compareOkraToSeq(KernelTester.java:761) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.testGeneratedHsail(KernelTester.java:799) at com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.testGeneratedHsail(GraalKernelTester.java:148) at com.oracle.graal.compiler.hsail.test.EscapingNewVec3Test.test(EscapingNewVec3Test.java:21) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) 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) Caused by: java.lang.RuntimeException: Exception while intercepting exception at com.oracle.graal.debug.internal.DebugScope.interceptException(DebugScope.java:299) at com.oracle.graal.debug.internal.DebugScope.handle(DebugScope.java:254) at com.oracle.graal.debug.Debug.handle(Debug.java:232) at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:145) at com.oracle.graal.hotspot.stubs.Stub.getCode(Stub.java:148) 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.meta.HotSpotForeignCallsProviderImpl.lookupForeignCall(HotSpotForeignCallsProviderImpl.java:42) at com.oracle.graal.hotspot.nodes.VMErrorNode.generate(VMErrorNode.java:60) at com.oracle.graal.compiler.gen.LIRGenerator.emitNode(LIRGenerator.java:515) at com.oracle.graal.compiler.gen.LIRGenerator.doRoot(LIRGenerator.java:506) at com.oracle.graal.compiler.gen.LIRGenerator.doBlock(LIRGenerator.java:449) ... 45 more Caused by: java.lang.NullPointerException at com.oracle.graal.printer.GraphPrinterDumpHandler.getInlineContext(GraphPrinterDumpHandler.java:205) at com.oracle.graal.printer.GraphPrinterDumpHandler.dump(GraphPrinterDumpHandler.java:157) at com.oracle.graal.debug.internal.DebugScope.dump(DebugScope.java:203) at com.oracle.graal.debug.Debug.dump(Debug.java:269) at com.oracle.graal.compiler.GraalDebugConfig.interceptException(GraalDebugConfig.java:225) at com.oracle.graal.debug.internal.DebugScope.interceptException(DebugScope.java:297) ... 56 more > -----Original Message----- > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of > Gilles Duboscq > Sent: Wednesday, March 19, 2014 6:02 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: NullPointerException in ControlFlowGraph.commonDominator > during SchedulePhase > > Hello Tom, > > Do you have any more context (full stack trace)? > When dumping, there can be exceptions in the schedules that are used for > dumping but those should in theory just be ignored. > > -Gilles > > On Tue, Mar 18, 2014 at 10:56 PM, Tom Deneau wrote: > > I noticed in some hsail junit tests that were storing objects that I > didn't see the card table setting code. I remember this was working > about 4 months ago but we haven't really looked at Object Storing junits > since then and I know a lot of the infrastructure has changed since > then. Anyway in igv I noticed that the WriteBarrierAdditionPhase was > not one of the phases for hsail compileGraph. > > > > Previously the setup in HSAILHotSpotBackendFactory was > > SuitesProvider suites = new DefaultSuitesProvider(); > > > > which I changed to the following to make it match more the > AMD64HotSpotBackendFactory > > SuitesProvider suites = new HotSpotSuitesProvider(runtime); > > > > This seemed to do the trick as far as generating the card table > > stores, but now I notice when I run with -G:Dump=, I get a > > NullPointerException during the SchedulePhase > > > > > > [1] com.oracle.graal.nodes.cfg.ControlFlowGraph.commonDominator > (ControlFlowGraph.java:336) > > [2] > com.oracle.graal.phases.schedule.SchedulePhase$CommonDominatorBlockClosu > re.apply (SchedulePhase.java:625) > > [3] com.oracle.graal.phases.schedule.SchedulePhase.blocksForUsage > (SchedulePhase.java:780) > > [4] com.oracle.graal.phases.schedule.SchedulePhase.latestBlock > (SchedulePhase.java:599) > > [5] com.oracle.graal.phases.schedule.SchedulePhase.assignBlockToNode > (SchedulePhase.java:417) > > [6] > com.oracle.graal.phases.schedule.SchedulePhase.assignBlockToNodes > (SchedulePhase.java:379) > > [7] com.oracle.graal.phases.schedule.SchedulePhase.run > > (SchedulePhase.java:273) > > > > I admit I didn't really look at all the differences between > DefaultSuitesProvider and HotSpotSuitesProvider(runtime) but does anyone > have any suggestions as to what might be causing this? > > > > -- Tom > > From lukas.stadler at oracle.com Wed Mar 19 16:55:41 2014 From: lukas.stadler at oracle.com (Lukas Stadler) Date: Wed, 19 Mar 2014 17:55:41 +0100 Subject: NullPointerException in ControlFlowGraph.commonDominator during SchedulePhase In-Reply-To: References: Message-ID: A fix for this is on its way. It sometimes happens for null-method graphs within inlining contexts - which may be why your change exposed it. - Lukas Here?s the change: --- graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java @@ -202,7 +202,7 @@ for (Object o : Debug.context()) { JavaMethod method = asJavaMethod(o); if (method != null) { - if (lastMethodOrGraph == null || !asJavaMethod(lastMethodOrGraph).equals(method)) { + if (lastMethodOrGraph == null || asJavaMethod(lastMethodOrGraph) == null || !asJavaMethod(lastMethodOrGraph).equals(method)) { result.add(MetaUtil.format("%H::%n(%p)", method)); } else { // This prevents multiple adjacent method context objects for the same method On 19 Mar 2014, at 17:31, Deneau, Tom wrote: > Gilles -- > > You're right, the nullPointerException in my original email was caught... > Here's a fuller stack trace... > I notice it is coming from the compileGraph for the host trampoline code. > But I don't understand why changing the SuitesProvider for the hsail compilation should affect this. > (and I only see it with -G:Dump=) > > -- Tom > > > > There was 1 failure: > 1) test(com.oracle.graal.compiler.hsail.test.EscapingNewVec3Test) > com.oracle.graal.graph.GraalInternalError: java.lang.RuntimeException: Exception while intercepting exception > at node: 17|VMError > at com.oracle.graal.compiler.gen.LIRGenerator.doBlock(LIRGenerator.java:453) > at com.oracle.graal.compiler.GraalCompiler.emitBlock(GraalCompiler.java:215) > at com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:246) > at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:149) > at com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.installKernel(HSAILHotSpotBackend.java:263) > at com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.compileAndInstallKernel(HSAILHotSpotBackend.java:142) > at com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.dispatchKernelOkra(GraalKernelTester.java:115) > at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchMethodKernelOkra(KernelTester.java:635) > at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchMethodKernel(KernelTester.java:370) > at com.oracle.graal.compiler.hsail.test.EscapingNewVec3Base.runTest(EscapingNewVec3Base.java:32) > at com.oracle.graal.compiler.hsail.test.infra.KernelTester.runOkraInstance(KernelTester.java:786) > at com.oracle.graal.compiler.hsail.test.infra.KernelTester.compareOkraToSeq(KernelTester.java:776) > at com.oracle.graal.compiler.hsail.test.infra.KernelTester.compareOkraToSeq(KernelTester.java:761) > at com.oracle.graal.compiler.hsail.test.infra.KernelTester.testGeneratedHsail(KernelTester.java:799) > at com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.testGeneratedHsail(GraalKernelTester.java:148) > at com.oracle.graal.compiler.hsail.test.EscapingNewVec3Test.test(EscapingNewVec3Test.java:21) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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) > Caused by: java.lang.RuntimeException: Exception while intercepting exception > at com.oracle.graal.debug.internal.DebugScope.interceptException(DebugScope.java:299) > at com.oracle.graal.debug.internal.DebugScope.handle(DebugScope.java:254) > at com.oracle.graal.debug.Debug.handle(Debug.java:232) > at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:145) > at com.oracle.graal.hotspot.stubs.Stub.getCode(Stub.java:148) > 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.meta.HotSpotForeignCallsProviderImpl.lookupForeignCall(HotSpotForeignCallsProviderImpl.java:42) > at com.oracle.graal.hotspot.nodes.VMErrorNode.generate(VMErrorNode.java:60) > at com.oracle.graal.compiler.gen.LIRGenerator.emitNode(LIRGenerator.java:515) > at com.oracle.graal.compiler.gen.LIRGenerator.doRoot(LIRGenerator.java:506) > at com.oracle.graal.compiler.gen.LIRGenerator.doBlock(LIRGenerator.java:449) > ... 45 more > Caused by: java.lang.NullPointerException > at com.oracle.graal.printer.GraphPrinterDumpHandler.getInlineContext(GraphPrinterDumpHandler.java:205) > at com.oracle.graal.printer.GraphPrinterDumpHandler.dump(GraphPrinterDumpHandler.java:157) > at com.oracle.graal.debug.internal.DebugScope.dump(DebugScope.java:203) > at com.oracle.graal.debug.Debug.dump(Debug.java:269) > at com.oracle.graal.compiler.GraalDebugConfig.interceptException(GraalDebugConfig.java:225) > at com.oracle.graal.debug.internal.DebugScope.interceptException(DebugScope.java:297) > ... 56 more > > >> -----Original Message----- >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of >> Gilles Duboscq >> Sent: Wednesday, March 19, 2014 6:02 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: NullPointerException in ControlFlowGraph.commonDominator >> during SchedulePhase >> >> Hello Tom, >> >> Do you have any more context (full stack trace)? >> When dumping, there can be exceptions in the schedules that are used for >> dumping but those should in theory just be ignored. >> >> -Gilles >> >> On Tue, Mar 18, 2014 at 10:56 PM, Tom Deneau wrote: >>> I noticed in some hsail junit tests that were storing objects that I >> didn't see the card table setting code. I remember this was working >> about 4 months ago but we haven't really looked at Object Storing junits >> since then and I know a lot of the infrastructure has changed since >> then. Anyway in igv I noticed that the WriteBarrierAdditionPhase was >> not one of the phases for hsail compileGraph. >>> >>> Previously the setup in HSAILHotSpotBackendFactory was >>> SuitesProvider suites = new DefaultSuitesProvider(); >>> >>> which I changed to the following to make it match more the >> AMD64HotSpotBackendFactory >>> SuitesProvider suites = new HotSpotSuitesProvider(runtime); >>> >>> This seemed to do the trick as far as generating the card table >>> stores, but now I notice when I run with -G:Dump=, I get a >>> NullPointerException during the SchedulePhase >>> >>> >>> [1] com.oracle.graal.nodes.cfg.ControlFlowGraph.commonDominator >> (ControlFlowGraph.java:336) >>> [2] >> com.oracle.graal.phases.schedule.SchedulePhase$CommonDominatorBlockClosu >> re.apply (SchedulePhase.java:625) >>> [3] com.oracle.graal.phases.schedule.SchedulePhase.blocksForUsage >> (SchedulePhase.java:780) >>> [4] com.oracle.graal.phases.schedule.SchedulePhase.latestBlock >> (SchedulePhase.java:599) >>> [5] com.oracle.graal.phases.schedule.SchedulePhase.assignBlockToNode >> (SchedulePhase.java:417) >>> [6] >> com.oracle.graal.phases.schedule.SchedulePhase.assignBlockToNodes >> (SchedulePhase.java:379) >>> [7] com.oracle.graal.phases.schedule.SchedulePhase.run >>> (SchedulePhase.java:273) >>> >>> I admit I didn't really look at all the differences between >> DefaultSuitesProvider and HotSpotSuitesProvider(runtime) but does anyone >> have any suggestions as to what might be causing this? >>> >>> -- Tom >>> > From tom.deneau at amd.com Wed Mar 19 17:04:04 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 19 Mar 2014 17:04:04 +0000 Subject: code optimized away before a deopt In-Reply-To: <335F428E-B1EB-44B6-B8FC-25C143B14F0D@oracle.com> References: <5C4A5B37-B6B6-4E25-9982-EA0BC543685C@oracle.com> <56957525-604C-4321-9A3D-478913744E0C@jku.at> <6E10CA9C-5B69-4A63-8164-3B086E9BDE98@oracle.com> <93452F27-3778-4397-8D82-1F7A3C7EB390@oracle.com> <710063CF-DCD4-4328-8314-0EA798B134A6@oracle.com> <335F428E-B1EB-44B6-B8FC-25C143B14F0D@oracle.com> Message-ID: Tom -- I looked back and I did model our AtomicGetAndAddNode and LoweredAtomicGetAndAddNode after the corresponding CompareAndSwapNodes. Here is the nodeIntrinsic @NodeIntrinsic public static long atomicGetAndAdd(long base, int offset, LocationIdentity locationIdentity, int delta) { // dummy filler code here } and here is how it is getting called public static Word atomicGetAndAddTlabTop(Word thread, int size) { return Word.unsigned(AtomicGetAndAddNode.atomicGetAndAdd(thread.rawValue(), threadTlabTopOffset(), TLAB_TOP_LOCATION, size)); } In AtomicGetAndAddNode, we basically ignore the location parameter, I don't know if that would be causing this behavior. The LoweredAtomicGetAndAddNode looks like LoweredCompareAndSwapNode and is shown here: public class LoweredAtomicGetAndAddNode extends FixedAccessNode implements StateSplit, LIRLowerable, MemoryCheckpoint.Single { @Input private ValueNode delta; @Input(notDataflow = true) private FrameState stateAfter; public FrameState stateAfter() { return stateAfter; } public void setStateAfter(FrameState x) { assert x == null || x.isAlive() : "frame state must be in a graph"; updateUsages(stateAfter, x); stateAfter = x; } public boolean hasSideEffect() { return true; } public ValueNode getDelta() { return delta; } public LoweredAtomicGetAndAddNode(ValueNode object, LocationNode location, ValueNode delta, BarrierType barrierType, boolean compressible) { super(object, location, StampFactory.forKind(Kind.Long.getStackKind()), barrierType, compressible); this.delta = delta; } @Override public LocationIdentity getLocationIdentity() { return location().getLocationIdentity(); } @Override public void generate(LIRGeneratorTool gen) { HSAILHotSpotLIRGenerator hsailGen = (HSAILHotSpotLIRGenerator) gen; hsailGen.visitAtomicGetAndAdd(this, location().generateAddress(hsailGen, hsailGen.operand(object()))); } @Override public MemoryCheckpoint asMemoryCheckpoint() { return this; } @Override public MemoryPhiNode asMemoryPhi() { return null; } } > -----Original Message----- > From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > Sent: Tuesday, March 18, 2014 12:02 PM > To: Deneau, Tom > Cc: Douglas Simon; Lukas Stadler; graal-dev at openjdk.java.net > Subject: Re: code optimized away before a deopt > > After looking at little bit more, I think CompareAndSwapNode would be a > better model which behaves as a memory checkpoint which includes the > state split stuff. Chris Thalinger may be adding a node which > represents lock xadd to support Unsafe.getAndSet which will probably > have the semantics you want. You could probably use that once it lands. > > tom > > On Mar 18, 2014, at 9:49 AM, Deneau, Tom > wrote: > > > OK, thanks, that makes sense. > > > >> -----Original Message----- > >> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > >> Sent: Tuesday, March 18, 2014 11:42 AM > >> To: Deneau, Tom > >> Cc: Douglas Simon; Lukas Stadler; graal-dev at openjdk.java.net > >> Subject: Re: code optimized away before a deopt > >> > >> So it's a custom node of some sort? I think you probably need make > >> sure it behaves like a WriteNode by implementing StateSplit and > >> having hasSideEffect return true. The state can be null. > >> > >> tom > >> > >> On Mar 18, 2014, at 7:57 AM, Deneau, Tom > wrote: > >> > >>> Tom -- > >>> > >>> It generates an HSAIL instruction atomic_add_global (similar to lock > >>> xadd in x86). I don't know for sure what that becomes in the gpu > >>> Instructions. In rough perf measurements I made it was more > >>> performant than doing a similar thing using an atomic_cas loop > >>> > >>> -- Tom > >>>> -----Original Message----- > >>>> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > >>>> Sent: Monday, March 17, 2014 6:07 PM > >>>> To: Deneau, Tom > >>>> Cc: Douglas Simon; Lukas Stadler; graal-dev at openjdk.java.net > >>>> Subject: Re: code optimized away before a deopt > >>>> > >>>> How is atomicGetAndAddTlabTop actually implemented? > >>>> > >>>> tom > >>>> > >>>> On Mar 17, 2014, at 2:28 PM, Deneau, Tom > > wrote: > >>>> > >>>>> I'll take a look at edenAllocate logic but I was trying to avoid > >>>>> the > >>>> while(true) loop which the compareAndSwap logic requires. > >>>>> > >>>>> -- Tom > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > >>>>>> Sent: Monday, March 17, 2014 4:18 PM > >>>>>> To: Deneau, Tom > >>>>>> Cc: Douglas Simon; Lukas Stadler; graal-dev at openjdk.java.net > >>>>>> Subject: Re: code optimized away before a deopt > >>>>>> > >>>>>> So you are using a TLAB from multiple threads so you need use > >>>>>> atomic's to actually do the allocation? Writing it using cleanup > >>>>>> logic doesn't seem right. I think should be using something like > >>>>>> the edenAllocate code in NewInstanceStub but against the TLAB. > >>>>>> Then you don't need cleanup logic. Or you could just allocate > >>>>>> directly from eden instead of using a TLAB. > >>>>>> > >>>>>> tom > >>>>>> > >>>>>> On Mar 17, 2014, at 1:40 PM, Deneau, Tom > > >> wrote: > >>>>>> > >>>>>>> I was just noticing that the condition mentioned below (first > >>>>>> mentioned last November) still affects our snippet for > >>>>>> newInstanceNode lowering. When I brought this up originally our > >>>>>> DeoptimizeNode.deopt was not really implemented and was just > >>>>>> making the workitem return early. Now, DeoptimizeNode.deopt is > >>>>>> doing the necessary save state, etc but that doesn't change the > >>>>>> fact that side-effecting nodes before the deopt will get thrown > away. > >>>>>>> > >>>>>>> We have a workaround that seems to work for now (additional if > >>>>>>> logic > >>>>>> around the deopt, which happens to be always true but the > >>>>>> compiler hasn't figured that out) but I wonder if that is a > >>>>>> robust > >> workaround. > >>>>>> Is there already a bug filed for this, or should I file one? > >>>>>>> > >>>>>>> -- Tom > >>>>>>> > >>>>>>> Here's the workaround we have now... > >>>>>>> > >>>>>>> Object result; > >>>>>>> Word thread = thread(); > >>>>>>> Word top = atomicGetAndAddTlabTop(thread, size); > >>>>>>> Word end = readTlabEnd(thread); > >>>>>>> Word newTop = top.add(size); > >>>>>>> if (useTLAB() && probability(FAST_PATH_PROBABILITY, > >>>>>> newTop.belowOrEqual(end))) { > >>>>>>> // writeTlabTop(thread, newTop) was done by the > >>>>>> atomicGetAndAdd > >>>>>>> result = formatObject(hub, size, top, prototypeMarkWord, > >>>>>> fillContents); > >>>>>>> } else { > >>>>>>> atomicGetAndAddTlabTop(thread, -size); > >>>>>>> new_stub.inc(); > >>>>>>> // the if statement below should not be necessary, but > >>>>>>> when > >>>>>> I remove it, > >>>>>>> // the atomicGetAndAddTlabTop(thread, -size) doesn't get > >>>>>> generated. > >>>>>>> if (!newTop.belowOrEqual(end)) { > >>>>>>> DeoptimizeNode.deopt(DeoptimizationAction.None, > >>>>>> DeoptimizationReason.RuntimeConstraint); > >>>>>>> } > >>>>>>> . . . > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com] > >>>>>>>> Sent: Saturday, November 23, 2013 10:24 AM > >>>>>>>> To: Lukas Stadler > >>>>>>>> Cc: Deneau, Tom; graal-dev at openjdk.java.net > >>>>>>>> Subject: Re: code optimized away before a deopt > >>>>>>>> > >>>>>>>> > >>>>>>>> On Nov 23, 2013, at 5:18 PM, Lukas Stadler > >>>>>>>> > > >>>>>> wrote: > >>>>>>>> > >>>>>>>>> But it _is_ ok to remove side effecting nodes, because we know > >>>>>>>>> they > >>>>>>>> will be reelected. > >>>>>>>> > >>>>>>>> Yes, normally, but when you write this pattern in a snippet, > >>>>>>>> then this won't be true right, since we don't resume execution > >>>>>>>> in the bytecode of the snippet (yet!). That why I was thinking > >>>>>>>> at least a warning would be a good idea. > >>>>>>>> > >>>>>>>> -Doug > >>>>>>>> > >>>>>>>>> Maybe the cleanup operations could be part of a special > >>>>>>>>> purpose deopt > >>>>>>>> node? > >>>>>>>>> > >>>>>>>>> - Lukas > >>>>>>>>> > >>>>>>>>> Von meinem iPhone gesendet > >>>>>>>>> > >>>>>>>>>> Am 23.11.2013 um 16:39 schrieb Doug Simon > >>>> >: > >>>>>>>>>> > >>>>>>>>>> This is done by the ConvertDeoptimizeToGuardPhase which > >>>>>>>>>> replaces > >>>>>>>> conditionals where one branch ends in a deopt with a GuardNode. > >>>>>>>> This does indeed have the side effect of (silently) deleting > >>>>>>>> all other nodes on that deopt-terminated branch. We should add > >>>>>>>> some code to either make the deletion not silent or better, > >>>>>>>> throw an error if these are any side- effecting nodes that will > >>>>>>>> be > >> deleted. > >>>>>>>>>> > >>>>>>>>>> -Doug > >>>>>>>>>> > >>>>>>>>>>> On Nov 23, 2013, at 1:58 AM, Deneau, Tom > >>>>>>>>>>> > > >>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> I've noticed that if I have a snippet that does a test and > >>>>>>>>>>> if the > >>>>>>>> test fails, branches to a block that does some cleanup > >>>>>>>> operations and then calls DeoptimizeNode.deopt(xxx, yyy), the > >>>>>>>> cleanup code gets "optimized away". I guess this is related to > >>>>>>>> what Gilles was talking about, maybe the cleanup operations > >>>>>>>> were considered not state > >>>>>> changing? > >>>>>>>>>>> > >>>>>>>>>>> In our current state of HSAIL backend, a deopt just returns > >>>>>>>>>>> early > >>>>>>>> from the kernel. Is there something I can do to make the > >> cleanup > >>>>>> code > >>>>>>>> get emitted before the deopt? > >>>>>>>>>>> > >>>>>>>>>>> -- Tom > >>>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >> > > > > > From tom.deneau at amd.com Wed Mar 19 17:21:58 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 19 Mar 2014 17:21:58 +0000 Subject: NullPointerException in ControlFlowGraph.commonDominator during SchedulePhase In-Reply-To: References: Message-ID: Yes, that helped... From: Lukas Stadler [mailto:lukas.stadler at oracle.com] Sent: Wednesday, March 19, 2014 11:56 AM To: Deneau, Tom Cc: Gilles Duboscq; graal-dev at openjdk.java.net Subject: Re: NullPointerException in ControlFlowGraph.commonDominator during SchedulePhase A fix for this is on its way. It sometimes happens for null-method graphs within inlining contexts - which may be why your change exposed it. - Lukas Here's the change: --- graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java @@ -202,7 +202,7 @@ for (Object o : Debug.context()) { JavaMethod method = asJavaMethod(o); if (method != null) { - if (lastMethodOrGraph == null || !asJavaMethod(lastMethodOrGraph).equals(method)) { + if (lastMethodOrGraph == null || asJavaMethod(lastMethodOrGraph) == null || !asJavaMethod(lastMethodOrGraph).equals(method)) { result.add(MetaUtil.format("%H::%n(%p)", method)); } else { // This prevents multiple adjacent method context objects for the same method On 19 Mar 2014, at 17:31, Deneau, Tom > wrote: Gilles -- You're right, the nullPointerException in my original email was caught... Here's a fuller stack trace... I notice it is coming from the compileGraph for the host trampoline code. But I don't understand why changing the SuitesProvider for the hsail compilation should affect this. (and I only see it with -G:Dump=) -- Tom There was 1 failure: 1) test(com.oracle.graal.compiler.hsail.test.EscapingNewVec3Test) com.oracle.graal.graph.GraalInternalError: java.lang.RuntimeException: Exception while intercepting exception at node: 17|VMError at com.oracle.graal.compiler.gen.LIRGenerator.doBlock(LIRGenerator.java:453) at com.oracle.graal.compiler.GraalCompiler.emitBlock(GraalCompiler.java:215) at com.oracle.graal.compiler.GraalCompiler.emitLIR(GraalCompiler.java:246) at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:149) at com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.installKernel(HSAILHotSpotBackend.java:263) at com.oracle.graal.hotspot.hsail.HSAILHotSpotBackend.compileAndInstallKernel(HSAILHotSpotBackend.java:142) at com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.dispatchKernelOkra(GraalKernelTester.java:115) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchMethodKernelOkra(KernelTester.java:635) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.dispatchMethodKernel(KernelTester.java:370) at com.oracle.graal.compiler.hsail.test.EscapingNewVec3Base.runTest(EscapingNewVec3Base.java:32) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.runOkraInstance(KernelTester.java:786) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.compareOkraToSeq(KernelTester.java:776) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.compareOkraToSeq(KernelTester.java:761) at com.oracle.graal.compiler.hsail.test.infra.KernelTester.testGeneratedHsail(KernelTester.java:799) at com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.testGeneratedHsail(GraalKernelTester.java:148) at com.oracle.graal.compiler.hsail.test.EscapingNewVec3Test.test(EscapingNewVec3Test.java:21) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) 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) Caused by: java.lang.RuntimeException: Exception while intercepting exception at com.oracle.graal.debug.internal.DebugScope.interceptException(DebugScope.java:299) at com.oracle.graal.debug.internal.DebugScope.handle(DebugScope.java:254) at com.oracle.graal.debug.Debug.handle(Debug.java:232) at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:145) at com.oracle.graal.hotspot.stubs.Stub.getCode(Stub.java:148) 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.meta.HotSpotForeignCallsProviderImpl.lookupForeignCall(HotSpotForeignCallsProviderImpl.java:42) at com.oracle.graal.hotspot.nodes.VMErrorNode.generate(VMErrorNode.java:60) at com.oracle.graal.compiler.gen.LIRGenerator.emitNode(LIRGenerator.java:515) at com.oracle.graal.compiler.gen.LIRGenerator.doRoot(LIRGenerator.java:506) at com.oracle.graal.compiler.gen.LIRGenerator.doBlock(LIRGenerator.java:449) ... 45 more Caused by: java.lang.NullPointerException at com.oracle.graal.printer.GraphPrinterDumpHandler.getInlineContext(GraphPrinterDumpHandler.java:205) at com.oracle.graal.printer.GraphPrinterDumpHandler.dump(GraphPrinterDumpHandler.java:157) at com.oracle.graal.debug.internal.DebugScope.dump(DebugScope.java:203) at com.oracle.graal.debug.Debug.dump(Debug.java:269) at com.oracle.graal.compiler.GraalDebugConfig.interceptException(GraalDebugConfig.java:225) at com.oracle.graal.debug.internal.DebugScope.interceptException(DebugScope.java:297) ... 56 more -----Original Message----- From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Wednesday, March 19, 2014 6:02 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: NullPointerException in ControlFlowGraph.commonDominator during SchedulePhase Hello Tom, Do you have any more context (full stack trace)? When dumping, there can be exceptions in the schedules that are used for dumping but those should in theory just be ignored. -Gilles On Tue, Mar 18, 2014 at 10:56 PM, Tom Deneau > wrote: I noticed in some hsail junit tests that were storing objects that I didn't see the card table setting code. I remember this was working about 4 months ago but we haven't really looked at Object Storing junits since then and I know a lot of the infrastructure has changed since then. Anyway in igv I noticed that the WriteBarrierAdditionPhase was not one of the phases for hsail compileGraph. Previously the setup in HSAILHotSpotBackendFactory was SuitesProvider suites = new DefaultSuitesProvider(); which I changed to the following to make it match more the AMD64HotSpotBackendFactory SuitesProvider suites = new HotSpotSuitesProvider(runtime); This seemed to do the trick as far as generating the card table stores, but now I notice when I run with -G:Dump=, I get a NullPointerException during the SchedulePhase [1] com.oracle.graal.nodes.cfg.ControlFlowGraph.commonDominator (ControlFlowGraph.java:336) [2] com.oracle.graal.phases.schedule.SchedulePhase$CommonDominatorBlockClosu re.apply (SchedulePhase.java:625) [3] com.oracle.graal.phases.schedule.SchedulePhase.blocksForUsage (SchedulePhase.java:780) [4] com.oracle.graal.phases.schedule.SchedulePhase.latestBlock (SchedulePhase.java:599) [5] com.oracle.graal.phases.schedule.SchedulePhase.assignBlockToNode (SchedulePhase.java:417) [6] com.oracle.graal.phases.schedule.SchedulePhase.assignBlockToNodes (SchedulePhase.java:379) [7] com.oracle.graal.phases.schedule.SchedulePhase.run (SchedulePhase.java:273) I admit I didn't really look at all the differences between DefaultSuitesProvider and HotSpotSuitesProvider(runtime) but does anyone have any suggestions as to what might be causing this? -- Tom From miguelalfredo.garcia at epfl.ch Wed Mar 19 18:16:07 2014 From: miguelalfredo.garcia at epfl.ch (Garcia Gutierrez Miguel Alfredo) Date: Wed, 19 Mar 2014 18:16:07 +0000 Subject: Node ids Message-ID: <7E4228B446372948BBB2916FC53FA49E2F5DCD35@rexma.intranet.epfl.ch> Sometimes a Set is needed just to track Node ids (ie, the elements are strongly reachable even if not in that set, or we don't care). In those cases, a dedicated IntSet data structure takes less memory. What about Node.id() ? (1) is it stable (doesn't change after read for the first time) (2) is it unique across (live and dead) nodes in a graph? Miguel -- Miguel Garcia Swiss Federal Institute of Technology EPFL - IC - LAMP1 - INR 328 - Station 14 CH-1015 Lausanne - Switzerland http://lamp.epfl.ch/~magarcia/ From duboscq at ssw.jku.at Wed Mar 19 18:32:38 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Wed, 19 Mar 2014 19:32:38 +0100 Subject: Node ids In-Reply-To: <7E4228B446372948BBB2916FC53FA49E2F5DCD35@rexma.intranet.epfl.ch> References: <7E4228B446372948BBB2916FC53FA49E2F5DCD35@rexma.intranet.epfl.ch> Message-ID: Hello Miguel, Yes, it's stable, Yes it's unique in a graph. As you already guessed, it's that way such that we can use bitsets for Set (NodeBitMap [1]) and a simple array for densely populated Map (NodeMap [2]) [1] http://lafo.ssw.uni-linz.ac.at/javadoc/graalvm/all/com/oracle/graal/graph/NodeBitMap.html [2] http://lafo.ssw.uni-linz.ac.at/javadoc/graalvm/all/com/oracle/graal/graph/NodeMap.html -Gilles On Wed, Mar 19, 2014 at 7:16 PM, Garcia Gutierrez Miguel Alfredo wrote: > > Sometimes a Set is needed just to track Node ids (ie, the elements are strongly reachable even if not in that set, or we don't care). In those cases, a dedicated IntSet data structure takes less memory. What about Node.id() ? > > (1) is it stable (doesn't change after read for the first time) > > (2) is it unique across (live and dead) nodes in a graph? > > > Miguel > > -- > Miguel Garcia > Swiss Federal Institute of Technology > EPFL - IC - LAMP1 - INR 328 - Station 14 > CH-1015 Lausanne - Switzerland > http://lamp.epfl.ch/~magarcia/ From tom.rodriguez at oracle.com Wed Mar 19 19:12:02 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 19 Mar 2014 12:12:02 -0700 Subject: Node ids In-Reply-To: References: <7E4228B446372948BBB2916FC53FA49E2F5DCD35@rexma.intranet.epfl.ch> Message-ID: <32906E92-7078-4ABD-94F4-016D37BC7998@oracle.com> It?s not stable for the entire compilation since the node id range may be compressed between tiers. Within a phase it?s certainly stable though. suites.getHighTier().apply(graph, highTierContext); graph.maybeCompress(); MidTierContext midTierContext = new MidTierContext(providers, assumptions, target, optimisticOpts, profilingInfo, speculationLog); suites.getMidTier().apply(graph, midTierContext); graph.maybeCompress(); LowTierContext lowTierContext = new LowTierContext(providers, assumptions, target); suites.getLowTier().apply(graph, lowTierContext); graph.maybeCompress(); tom On Mar 19, 2014, at 11:32 AM, Gilles Duboscq wrote: > Hello Miguel, > > Yes, it's stable, Yes it's unique in a graph. > As you already guessed, it's that way such that we can use bitsets for > Set (NodeBitMap [1]) and a simple array for densely populated > Map (NodeMap [2]) > > [1] http://lafo.ssw.uni-linz.ac.at/javadoc/graalvm/all/com/oracle/graal/graph/NodeBitMap.html > [2] http://lafo.ssw.uni-linz.ac.at/javadoc/graalvm/all/com/oracle/graal/graph/NodeMap.html > > -Gilles > > On Wed, Mar 19, 2014 at 7:16 PM, Garcia Gutierrez Miguel Alfredo > wrote: >> >> Sometimes a Set is needed just to track Node ids (ie, the elements are strongly reachable even if not in that set, or we don't care). In those cases, a dedicated IntSet data structure takes less memory. What about Node.id() ? >> >> (1) is it stable (doesn't change after read for the first time) >> >> (2) is it unique across (live and dead) nodes in a graph? >> >> >> Miguel >> >> -- >> Miguel Garcia >> Swiss Federal Institute of Technology >> EPFL - IC - LAMP1 - INR 328 - Station 14 >> CH-1015 Lausanne - Switzerland >> http://lamp.epfl.ch/~magarcia/ From tom.deneau at amd.com Wed Mar 19 22:39:11 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 19 Mar 2014 22:39:11 +0000 Subject: hsail compiler emitting useless cvt instruction Message-ID: I noticed that in some cases our hsail codegen contains patterns like cvt_s64_s32 $d4, $s1; cvt_s64_s32 $d4, $d4; I was surprised that the second cvt is legal hsail, but I guess for cvt, s32 can apply to a $d register. (of course in this context it is useless). We could ignore this in the Assembler but it would be nice to understand why it is happening. What is a good way to find this out? At least one place it seems to come from is the TypeCheck code that occurs when an object is stored into an array. -- Tom Here is from ciVisualizer after LIR generation -1 v30|j = LOADCOMPRESSEDPOINTER long[v2|a + 8] v31|j kind: long shift: 3 base: 0 alignment: 3 -1 v32|j = LOAD long[v30|j + 232] kind: long -1 v33|i = LOAD long[v32|j + 16] kind: int -1 v34|j = CONVERT v33|i from: s32 to: s64 -1 v35|j = CONVERT v34|j from: s32 to: s64 -1 v36|j = LADD (x: v15|j, ~y: v35|j) -1 v37|j = LOAD long[v36|j] kind: long and after register number assignment 80 d2|j = LOADCOMPRESSEDPOINTER long[d1|a + 8] d4|j kind: long shift: 3 base: 0 alignment: 3 82 d2|j = LOAD long[d2|j + 232] kind: long 84 s1|i = LOAD long[d2|j + 16] kind: int 86 d4|j = CONVERT s1|i from: s32 to: s64 88 d4|j = CONVERT d4|j from: s32 to: s64 90 d5|j = LADD (x: d6|j, ~y: d4|j) 92 d4|j = LOAD long[d5|j] kind: long From tom.rodriguez at oracle.com Wed Mar 19 22:53:52 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 19 Mar 2014 15:53:52 -0700 Subject: hsail compiler emitting useless cvt instruction In-Reply-To: References: Message-ID: <389B4447-7189-455C-960C-78A5B4F6D186@oracle.com> Presumably it's there in your IR but it seems malformed to me. The second convert has a long input but it still thinks it?s converting from s32 to s64. What?s in the original IR? tom On Mar 19, 2014, at 3:39 PM, Deneau, Tom wrote: > I noticed that in some cases our hsail codegen contains patterns like > > cvt_s64_s32 $d4, $s1; > cvt_s64_s32 $d4, $d4; > > I was surprised that the second cvt is legal hsail, but I guess for cvt, s32 can apply to a $d register. > (of course in this context it is useless). > We could ignore this in the Assembler but it would be nice to understand why it is happening. > What is a good way to find this out? > At least one place it seems to come from is the TypeCheck code that occurs when an object is stored into an array. > > -- Tom > > Here is from ciVisualizer after LIR generation > > -1 v30|j = LOADCOMPRESSEDPOINTER long[v2|a + 8] v31|j kind: long shift: 3 base: 0 alignment: 3 > -1 v32|j = LOAD long[v30|j + 232] kind: long > -1 v33|i = LOAD long[v32|j + 16] kind: int > -1 v34|j = CONVERT v33|i from: s32 to: s64 > -1 v35|j = CONVERT v34|j from: s32 to: s64 > -1 v36|j = LADD (x: v15|j, ~y: v35|j) > -1 v37|j = LOAD long[v36|j] kind: long > > and after register number assignment > > 80 d2|j = LOADCOMPRESSEDPOINTER long[d1|a + 8] d4|j kind: long shift: 3 base: 0 alignment: 3 > 82 d2|j = LOAD long[d2|j + 232] kind: long > 84 s1|i = LOAD long[d2|j + 16] kind: int > 86 d4|j = CONVERT s1|i from: s32 to: s64 > 88 d4|j = CONVERT d4|j from: s32 to: s64 > 90 d5|j = LADD (x: d6|j, ~y: d4|j) > 92 d4|j = LOAD long[d5|j] kind: long From tom.deneau at amd.com Wed Mar 19 23:02:16 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 19 Mar 2014 23:02:16 +0000 Subject: hsail compiler emitting useless cvt instruction In-Reply-To: <389B4447-7189-455C-960C-78A5B4F6D186@oracle.com> References: <389B4447-7189-455C-960C-78A5B4F6D186@oracle.com> Message-ID: what is the best way to get the original IR? > -----Original Message----- > From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] > Sent: Wednesday, March 19, 2014 5:54 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: hsail compiler emitting useless cvt instruction > > Presumably it's there in your IR but it seems malformed to me. The > second convert has a long input but it still thinks it's converting from > s32 to s64. What's in the original IR? > > tom > > On Mar 19, 2014, at 3:39 PM, Deneau, Tom wrote: > > > I noticed that in some cases our hsail codegen contains patterns like > > > > cvt_s64_s32 $d4, $s1; > > cvt_s64_s32 $d4, $d4; > > > > I was surprised that the second cvt is legal hsail, but I guess for > cvt, s32 can apply to a $d register. > > (of course in this context it is useless). > > We could ignore this in the Assembler but it would be nice to > understand why it is happening. > > What is a good way to find this out? > > At least one place it seems to come from is the TypeCheck code that > occurs when an object is stored into an array. > > > > -- Tom > > > > Here is from ciVisualizer after LIR generation > > > > -1 v30|j = LOADCOMPRESSEDPOINTER long[v2|a + 8] v31|j kind: long > shift: 3 base: 0 alignment: 3 > > -1 v32|j = LOAD long[v30|j + 232] kind: long > > -1 v33|i = LOAD long[v32|j + 16] kind: int > > -1 v34|j = CONVERT v33|i from: s32 to: s64 > > -1 v35|j = CONVERT v34|j from: s32 to: s64 > > -1 v36|j = LADD (x: v15|j, ~y: v35|j) > > -1 v37|j = LOAD long[v36|j] kind: long > > > > and after register number assignment > > > > 80 d2|j = LOADCOMPRESSEDPOINTER long[d1|a + 8] d4|j kind: long > shift: 3 base: 0 alignment: 3 > > 82 d2|j = LOAD long[d2|j + 232] kind: long > > 84 s1|i = LOAD long[d2|j + 16] kind: int > > 86 d4|j = CONVERT s1|i from: s32 to: s64 > > 88 d4|j = CONVERT d4|j from: s32 to: s64 > > 90 d5|j = LADD (x: d6|j, ~y: d4|j) > > 92 d4|j = LOAD long[d5|j] kind: long > From tom.rodriguez at oracle.com Wed Mar 19 23:40:52 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 19 Mar 2014 16:40:52 -0700 Subject: hsail compiler emitting useless cvt instruction In-Reply-To: References: <389B4447-7189-455C-960C-78A5B4F6D186@oracle.com> Message-ID: The c1visualizer used to have both HIR and LIR in some of the views but that?s currently not working because of changes for the baseline compiler. In the interim, if you have the latest bits, the first dump the c1visualizer gets should be called ?After final schedule? which is a scheduled dump of the HIR. The blocks should correspond to your LIR output so it should be easy to match them up. Otherwise you can dump to IGV and try to find something that matches. tom On Mar 19, 2014, at 4:02 PM, Deneau, Tom wrote: > what is the best way to get the original IR? > >> -----Original Message----- >> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] >> Sent: Wednesday, March 19, 2014 5:54 PM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: hsail compiler emitting useless cvt instruction >> >> Presumably it's there in your IR but it seems malformed to me. The >> second convert has a long input but it still thinks it's converting from >> s32 to s64. What's in the original IR? >> >> tom >> >> On Mar 19, 2014, at 3:39 PM, Deneau, Tom wrote: >> >>> I noticed that in some cases our hsail codegen contains patterns like >>> >>> cvt_s64_s32 $d4, $s1; >>> cvt_s64_s32 $d4, $d4; >>> >>> I was surprised that the second cvt is legal hsail, but I guess for >> cvt, s32 can apply to a $d register. >>> (of course in this context it is useless). >>> We could ignore this in the Assembler but it would be nice to >> understand why it is happening. >>> What is a good way to find this out? >>> At least one place it seems to come from is the TypeCheck code that >> occurs when an object is stored into an array. >>> >>> -- Tom >>> >>> Here is from ciVisualizer after LIR generation >>> >>> -1 v30|j = LOADCOMPRESSEDPOINTER long[v2|a + 8] v31|j kind: long >> shift: 3 base: 0 alignment: 3 >>> -1 v32|j = LOAD long[v30|j + 232] kind: long >>> -1 v33|i = LOAD long[v32|j + 16] kind: int >>> -1 v34|j = CONVERT v33|i from: s32 to: s64 >>> -1 v35|j = CONVERT v34|j from: s32 to: s64 >>> -1 v36|j = LADD (x: v15|j, ~y: v35|j) >>> -1 v37|j = LOAD long[v36|j] kind: long >>> >>> and after register number assignment >>> >>> 80 d2|j = LOADCOMPRESSEDPOINTER long[d1|a + 8] d4|j kind: long >> shift: 3 base: 0 alignment: 3 >>> 82 d2|j = LOAD long[d2|j + 232] kind: long >>> 84 s1|i = LOAD long[d2|j + 16] kind: int >>> 86 d4|j = CONVERT s1|i from: s32 to: s64 >>> 88 d4|j = CONVERT d4|j from: s32 to: s64 >>> 90 d5|j = LADD (x: d6|j, ~y: d4|j) >>> 92 d4|j = LOAD long[d5|j] kind: long >> > > From doug.simon at oracle.com Thu Mar 20 02:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 20 Mar 2014 02:00:06 +0000 Subject: hg: graal/graal: 14 new changesets Message-ID: <201403200200.s2K20OAQ006662@aojmv0008> Changeset: abf7cf57df5e Author: Doug Simon Date: 2014-03-19 12:42 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/abf7cf57df5e added RegisterConfig.areAllAllocatableRegistersCallerSaved() ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/RegisterConfig.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRegisterConfig.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/SPARCHotSpotRegisterConfig.java ! graal/com.oracle.graal.hsail/src/com/oracle/graal/hsail/HSAILRegisterConfig.java Changeset: bd106238e885 Author: Doug Simon Date: 2014-03-19 15:21 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bd106238e885 return false for HSAILRegisterConfig.areAllAllocatableRegisterCallerSaved() ! graal/com.oracle.graal.hsail/src/com/oracle/graal/hsail/HSAILRegisterConfig.java Changeset: aa7bcf1fa423 Author: Doug Simon Date: 2014-03-19 16:30 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/aa7bcf1fa423 expanded Debug API to avoid any allocation for timer and metric creation if debugging is disabled ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethod.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/BasePhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: c03d4de23448 Author: Doug Simon Date: 2014-03-19 16:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c03d4de23448 Merge. Changeset: affd2b3b0cbb Author: Christian Humer Date: 2014-03-19 19:54 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/affd2b3b0cbb Truffle: tuned inlining. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallNodeProfile.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: ed3bfe43d772 Author: Christian Humer Date: 2014-03-19 21:10 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ed3bfe43d772 Merge. Changeset: a0baf4eeb018 Author: Doug Simon Date: 2014-03-19 16:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a0baf4eeb018 removed allocation for name of debug scope ! 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/EATestBase.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/IterativeInliningPhase.java Changeset: a6fda38d8484 Author: Doug Simon Date: 2014-03-19 18:05 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a6fda38d8484 refactored System.out|err into local variables to avoid need for Checkstyle disabling filters (which the Eclipse CS plugin doesn't always see) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/logging/CountingProxy.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/jdk/System_setOut.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/HexCodeFile.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TimedCompilationPolicy.java Changeset: aff1511f13a9 Author: Doug Simon Date: 2014-03-19 22:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/aff1511f13a9 added AllocSpy tool for analyzing allocation in Graal using the Java Allocation Instrumenter (https://code.google.com/p/java-allocation-instrumenter/) + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/AllocSpy.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! mx/projects Changeset: 5507d2f586ef Author: Doug Simon Date: 2014-03-19 22:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5507d2f586ef Merge. Changeset: f3510d0dcf67 Author: Doug Simon Date: 2014-03-19 23:11 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f3510d0dcf67 removed use of varargs from Debug.scope() API ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/LazyName.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleDebugJavaMethod.java Changeset: 3ab42370f636 Author: Doug Simon Date: 2014-03-19 23:41 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3ab42370f636 removed use of varargs from Debug.log() API ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugConfig.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java Changeset: 4f8268dee8aa Author: Christian Humer Date: 2014-03-20 00:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4f8268dee8aa mx: eclipseformat now prints all the changes that were found to the console. ! mxtool/mx.py Changeset: 46c020971d9c Author: Christian Humer Date: 2014-03-20 00:16 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/46c020971d9c Merge. From doug.simon at oracle.com Thu Mar 20 15:15:41 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 20 Mar 2014 15:15:41 +0000 Subject: hg: graal/graal: 11 new changesets Message-ID: <201403201515.s2KFFvKJ003219@aojmv0008> Changeset: a08b8694f556 Author: Andreas Woess Date: 2014-03-19 23:11 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a08b8694f556 Truffle: Node API changes deprecate adoptChild, no longer needed in constructor add Node#insert for inserting new nodes into the tree (previously adoptChild) add Node#adoptChildren() helper method that adopts all (direct and indirect) children of a node, automatically called in TruffleRuntime#createCallTarget ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/ControlFlowExceptionPartialEvaluationTest.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/nodes/AddTestNode.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/nodes/BlockTestNode.java ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/nodes/LoopTestNode.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/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/nodes/serial/TestNodes.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/RootCallTarget.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/instrument/InstrumentationProbeNode.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/SLRootNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/call/SLDirectDispatchNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/call/SLInvokeNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/controlflow/SLBlockNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/controlflow/SLFunctionBodyNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/controlflow/SLIfNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/controlflow/SLReturnNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/controlflow/SLWhileNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/demo/SLAddWithoutSpecializationNode.java Changeset: ba52fbec5b6c Author: Andreas Woess Date: 2014-03-20 01:29 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ba52fbec5b6c Truffle: atomic node rewriting make Node#replace thread-safe add Node#atomic helper method for atomic tree operations add basic test for thread-safety + graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/ThreadSafetyTest.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java Changeset: 51d774eb5e14 Author: Andreas Woess Date: 2014-03-20 01:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/51d774eb5e14 update changelog ! CHANGELOG.md Changeset: 97321295c974 Author: Andreas Woess Date: 2014-03-20 02:22 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/97321295c974 fix PostOrderDeserializerTest ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/nodes/serial/PostOrderDeserializerTest.java Changeset: 5f5e2711dc24 Author: Andreas Woess Date: 2014-03-20 03:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5f5e2711dc24 fix TruffleDSL tests ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/ImplicitCastTest.java ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/TestHelper.java Changeset: da2431cc1506 Author: Josef Eisl Date: 2014-03-20 11:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/da2431cc1506 Rename ValueNode kind() to getKind(). ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/deopt/CompiledMethodTest.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.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64RawNativeCallNode.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXWrapperBuilder.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/meta/HotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nfi/NativeCallStubGraphBuilder.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/phases/AheadOfTimeVerificationPhase.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/FrameStateBuilder.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FrameState.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/InvokeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/UnwindNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValueNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValueNodeUtil.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/IntegerBelowThanNode.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/LeftShiftNode.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/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/extended/ForeignCallNode.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/SwitchNode.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/InstanceOfDynamicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoweredCompareAndSwapNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/TypeSwitchNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java ! graal/com.oracle.graal.replacements.hsail/src/com/oracle/graal/replacements/hsail/HSAILMathIntrinsicsNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/GraphKit.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.replacements/src/com/oracle/graal/replacements/nodes/DirectObjectStoreNode.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/ReadRegisterNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/ReverseBytesNode.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/nodes/typesystem/CustomizedUnsafeLoadFinalNode.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/PartialEscapeClosure.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 ! graal/com.oracle.graal.word/src/com/oracle/graal/word/nodes/WordCastNode.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: 2496f9f49f6b Author: Doug Simon Date: 2014-03-20 12:36 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2496f9f49f6b improved javadoc for Debug.logv() to explain why it should be avoided ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java Changeset: 186e57fa5eaa Author: Doug Simon Date: 2014-03-20 12:37 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/186e57fa5eaa added checker to catch usages of Debug.log() with string concatenation expressions ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/CheckGraalInvariants.java + graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyDebugUsage.java Changeset: 733e50d96f9b Author: Doug Simon Date: 2014-03-20 12:42 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/733e50d96f9b fixed usages of Debug.log() ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/ForEachToGraal.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopEx.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopTransformLowPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java Changeset: 04e317d1daa4 Author: Doug Simon Date: 2014-03-20 12:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/04e317d1daa4 fixed spelling ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyDebugUsage.java Changeset: b2e2132c0eff Author: Doug Simon Date: 2014-03-20 13:53 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b2e2132c0eff fixed null phase names in IGV ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/BasePhase.java From doug.simon at oracle.com Thu Mar 20 15:17:51 2014 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 20 Mar 2014 16:17:51 +0100 Subject: new webrev for HSAILHotSpotLIRGenerator small fixes In-Reply-To: References: Message-ID: <80EEE310-5184-4ED0-B866-D8A1DCDB832A@oracle.com> Hi Eric, Since submitting this patch, the Kind.NarrowOop value was removed[1]. Can you please generate a new webrev based on the tip. -Doug [1] http://hg.openjdk.java.net/graal/graal/rev/82e4fe6fa525 On Mar 19, 2014, at 1:54 PM, Caspole, Eric wrote: > Hi everybody, > I put a new webrev here - > > http://cr.openjdk.java.net/~ecaspole/hsail_lir/webrev/ > > This fixes 2 issues I found while trying Clumatra: storing compressed constants was not implemented yet (thanks Tom D for this), and previously HSAILHotSpotLIRGenerator did not "implements HotSpotLIRGenerator" so some methods would fail to compile with ClassCastExceptions in the middle of compilation. I implemented dummy stubs for all that that throws NYI instead. > Regards, > Eric > From tom.deneau at amd.com Thu Mar 20 19:52:05 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 20 Mar 2014 19:52:05 +0000 Subject: java.lang.Error running build from ecj compiler In-Reply-To: References: <898DD1C1-4FC5-4794-9D54-B4CA11D7AEAD@oracle.com> <44EE458D-5C7E-4727-B124-22EDEC0C04DE@oracle.com> Message-ID: Widening beyond just Doug and Gilles... I was cleaning up warnings from a webrev using the following sequence: (My webrev was based off of 5f5e2711dc24 although I'm not sure that matters) mx clean mx eclipseinit # has a side effect of preparing the annotation processor jars mx build --vm server --vmbuild product --jdt /path/to/ecj-4.3.2.jar --jdt-warning-as-error mx checkstyle repeat build... So eventually I got a build with no compiler errors or warnings. Then I wanted to run our junit tests, I used the ecj produced bytecodes and I got java.lang.Error: Unresolved compilation problem: The method getId() from the type Node is deprecated at com.oracle.graal.phases.common.GuardLoweringPhase$LowerGuards.lowerToIf(GuardLoweringPhase.java:153) at com.oracle.graal.phases.common.GuardLoweringPhase$LowerGuards.processNode(GuardLoweringPhase.java:144) at com.oracle.graal.phases.graph.ScheduledNodeIterator.processNodes(ScheduledNodeIterator.java:63) at com.oracle.graal.phases.common.GuardLoweringPhase.processBlock(GuardLoweringPhase.java:200) at com.oracle.graal.phases.common.GuardLoweringPhase.run(GuardLoweringPhase.java:188) at com.oracle.graal.phases.common.GuardLoweringPhase.run(GuardLoweringPhase.java:1) I went back and did a javac build using mx clean mx build --vm server --vmbuild product This javac build ran the junits fine. I can see that Node.getId() was indeed marked @Deprecated, and that GuardLoweringPhase had a @SuppressWarnings("deprecation") before it's call to getId() Is this just because --jdt-warning-as-error is fighting against @SuppressWarnings here or it this a problem in the ecj compiler? -- Tom From tom.deneau at amd.com Thu Mar 20 20:57:45 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 20 Mar 2014 20:57:45 +0000 Subject: webrev-hsail-deopt-v2 Message-ID: Doug, Gilles -- I believe I have gotten rid of the warnings from the original hsail-deopt webrev. I also fixed a few casts that Eric Caspole noticed were preventing the fastdebug build from building (but did not affect product and debug builds). Please take a look at http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt-v2 I've included here the explanatory text from the first submission This consists of at least the start of support for deoptimization in HSAIL kernels. Although the list of files changed may look long, many of the files have only a few lines changed. Special thanks to Gilles Duboscq and Doug Simon who provided some of the infrastructure that this webrev uses. -- Tom Deneau Below I have described * an overview of the codepaths the data structures * java and hotspot source changes Deoptimization Data Structures and Overview =========================================== At kernel dispatch time, we allocate space for any workitems should want to deopt. To reduce the space requirements, space is only reserved for the maximum number of possible concurrent workitems that could be running on that hsa device. A deopting workitem sets a "deopt happened" flag, and future workitems that see "deopt happened" as true will just set a flag saying they never ran and exit early. Currently the never_ran array is one per workitem. We are looking at ways to make this smaller but HSA devices have a lot of freedom in how they schedule workitems (current hardware and the simulator are quite different). Workitems that deopt atomically bump an index saying where they should store their deopt data. The deopt data consists of * workitemid * deopt actionAndReason * the first HSAILFrame An HSAILFrame consists of * the deoptId or "pc" offset where the deopt occurred * number of s registers * number of d registers * a bitmap indicating which d registers are oops * space for saving the d and s registers Currently we always set num_s_registers to 32 and num_d_registers to 16 but in the hsail code of the kernel we only save the union of the actual registers that are live at any of the infopoints. On return from the GPU, we check if there were any deopts. If not, we just return back to java. If there was at least one deopt then a) for the workitems that finished normally, there is nothing to do b) if there are any deopted workitems, we want to run each deopting workitem thru the interpreter going first thru the special host trampoline code infrastructure that Gilles created. The trampoline host code takes the deoptId and a pointer to the saved hsail frame. We currently do this sequentially although other policies are possible. c) for each never ran workitem, we can just run it from the beginning of the kernel "method", just making sure we pass the arguments and the appropriate workitem id for each one. Again, we currently do this sequentially although other policies are possible. Because running either type b or c above can cause GCs, and because some of our saved d registers are pointers into the java heap, we take care in case any of these saved pointers are affected by GC. The current strategy of using an Object array supplied by the java side will be replaced later with an oops_do type of strategy. Description of source changes in this webrev. ============================================= graal source changes ==================== Assembler, HSAILAssembler minor changes for new instructions needed for saving deopt information GraalKernelTester.java force simulator to run single threaded. KernelTester.java minor changes to handle exceptions which escape the kernel method HSAILLIRGenerator.java support switches with keys of type long HSAILHotSpotBackend.java * compileKernel uses some new optimisticOpts which help generate deopts when needed. Also, we dump the infopoints if Log:CodeGen is on * HSAILNonNullParametersPhase stamps the appropriate parameters as nonNull * installKernel uses the new trampoline infrastructure added by Gilles do produce the host trampoline deopt method and install it. * emitCode adds a little bit of code to the prologue and a lot of code to the epilogue. See description at the bottom for the data structures used by the never-ran path and the deopt path. HSAILHotSpotLIRGenerator.java * code added by Gilles to build the host graph for the host trampoline deopt method. I suppose some of this would be common to any gpu trampoline deopt and should be moved to some hsail-independent location. * code to handle the creation of a DeoptimizeOp for emitting HSAIL code for a deoptimization HSAILHotSpotLoweringProvider.java * refactored to support different strategies for different nodes. UnwindNode strategy is to get replaced by a DeoptimizeNode. HotSpotVMConfig.java * define offets to fields in the deopt data structures VMErrorNode.java * public access to constructor (used by building of host graph for trampoline code) HSAIL.java * some new non-allocatable registers defined (used by deopt paths) HSAILControlFlow.java * code to emit hsail for a deoptimizationNode ComputeProbabilityClosure.java * just using a change that Gilles made in the patch he gave me. mx/projects was affected by the move of ExternalCompilationResult to com.oracle.graal.gpu. In addition, several files had one line import changes from the move of ExternalCompilationResult. hotspot source changes ====================== gpu_hsail.cpp, hpp * the execute_kernel routine pushes an extra parameter where deopt info can be saved * while pushing kernel args, keeps track if any are null and if so sets some new gpu_exception fields in thread structure which gets used when thread returns to java mode * on return from kernel checks if any deopt occurred. If so, * runs any deopting workitems thru the trampoline deopt code which ends up running the kernel method thru the interpreter for that workitem. * runs any never-ran workitems using simple javaCall. gpu_hsail_Frame.hpp * new structure that defines the layout of a physical HSAIL frame hsailArgumentsBase.*, hsailKernelArguments.hpp hsailJavaCallArguments.hpp * refactored to share code between kernel argument setup and javaCall argument setup javaClasses.cpp * contains logic to check the new gpu_exception fields in thread structure and if detected, set as top frame on return graalCompiler.cpp, hpp * logic added by Gilles for external_deopt_i2c javaCalls.cpp, hpp * logic added by Gilles for external_deopt_i2c sharedRuntime.cpp * maybe Gilles can explain why the assert was removed in the patch he gave me (it asserts if I put it back in) thread.cpp, hpp * handle new gpu_exception fields vmStructs.cpp vmStructs_hsail.hpp * handle new hsail deopt structs From doug.simon at oracle.com Thu Mar 20 21:02:59 2014 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 20 Mar 2014 22:02:59 +0100 Subject: java.lang.Error running build from ecj compiler In-Reply-To: References: <898DD1C1-4FC5-4794-9D54-B4CA11D7AEAD@oracle.com> <44EE458D-5C7E-4727-B124-22EDEC0C04DE@oracle.com> Message-ID: <9188A9E0-B6DB-40F0-A3A2-BB892BC5D54D@oracle.com> I?m not sure what?s going as I tried your steps (using ecj-4.3.2.jar) and never got that error when running the HSAIL unit tests. On Mar 20, 2014, at 8:52 PM, Deneau, Tom wrote: > Widening beyond just Doug and Gilles... > > I was cleaning up warnings from a webrev using the following sequence: > (My webrev was based off of 5f5e2711dc24 although I'm not sure that matters) > > > mx clean > mx eclipseinit # has a side effect of preparing the annotation processor jars > mx build --vm server --vmbuild product --jdt /path/to/ecj-4.3.2.jar --jdt-warning-as-error > mx checkstyle > repeat build... > > > So eventually I got a build with no compiler errors or warnings. > Then I wanted to run our junit tests, I used the ecj produced bytecodes > and I got > > > java.lang.Error: Unresolved compilation problem: > The method getId() from the type Node is deprecated > > at com.oracle.graal.phases.common.GuardLoweringPhase$LowerGuards.lowerToIf(GuardLoweringPhase.java:153) > at com.oracle.graal.phases.common.GuardLoweringPhase$LowerGuards.processNode(GuardLoweringPhase.java:144) > at com.oracle.graal.phases.graph.ScheduledNodeIterator.processNodes(ScheduledNodeIterator.java:63) > at com.oracle.graal.phases.common.GuardLoweringPhase.processBlock(GuardLoweringPhase.java:200) > at com.oracle.graal.phases.common.GuardLoweringPhase.run(GuardLoweringPhase.java:188) > at com.oracle.graal.phases.common.GuardLoweringPhase.run(GuardLoweringPhase.java:1) > > I went back and did a javac build using > mx clean > mx build --vm server --vmbuild product > > This javac build ran the junits fine. > > I can see that Node.getId() was indeed marked @Deprecated, and that GuardLoweringPhase had a @SuppressWarnings("deprecation") before it's call to getId() > > Is this just because --jdt-warning-as-error is fighting against @SuppressWarnings here or it this a problem in the ecj compiler? > > -- Tom From jules_gosnell at yahoo.com Thu Mar 20 21:27:17 2014 From: jules_gosnell at yahoo.com (Jules Gosnell) Date: Thu, 20 Mar 2014 21:27:17 +0000 Subject: Graal and Clojure In-Reply-To: <53277532.3030807@amd.com> References: <1394063789.8387.YahooMailNeo@web122406.mail.ne1.yahoo.com> <5326354D.8010204@yahoo.com> <53277532.3030807@amd.com> Message-ID: <532B5D35.4010108@yahoo.com> Eric, I just checked support to Clumatra for running individual unit tests from the CLI - should be enough to get you set up with your debugger. All details at the bottom of the README. https://github.com/JulesGosnell/clumatra I'm afraid you will need to install maven if you don't already have it - for some reason lein does not seem to have a test-jar target. It is still a little rough around the edges, but better than nothing :-) I also just bought my HSA h/w - should be up and running next week sometime. Did you figure out how to enable native-mode Okra ? catch you later, Jules On 17/03/14 22:20, Eric Caspole wrote: > Hi everybody, > I was setting up a new HSA system today and I installed Clumatra and got > it working under the simulator. I have a real HSA system not too > different from this: > > http://code.google.com/p/aparapi/wiki/SettingUpLinuxHSAMachineForAparapi > > In the clojure/lein/maven based system there is so much harness I can't > immediately see how to switch in the real hardware version of Okra > instead of the simulator Okra that gets installed into maven and > exploded in /tmp when the tests run. > > Jules, could you show how to bypass the harness etc to switch the Okra? > Can I just run 1 test with a simple java command line? This makes it a > lot easier to use a debugger which I will definitely want to do. > > Otherwise this is a cool project and we already found 1 or 2 issues we > can fix in HSAIL Graal related to your clojure tests. > Regards, > Eric > > > > On 03/17/2014 06:43 AM, Doug Simon wrote: >> Hi Julian, >> >> In terms of what to test, I?ll leave it up to the Sumatra developers >> at AMD and Oracle to comment on what may be interesting. >> >> As far as I know, no one in the Graal team is that familiar with >> Clojure. This actually makes the value of having Clojure tests >> integrated into our gate system somewhat problematic - >> debugging/fixing failures may be difficult. I?d suggest you report >> failures your discover on the sumatra-dev and graal-dev lists and we >> can resolve them that way for now. >> >> In addition, for Graal we?re always interested in benchmark suites for >> JVM hosted languages. Can you recommend any well known and trusted >> Clojure benchmarks we should consider? >> >> -Doug >> >> On Mar 17, 2014, at 12:35 AM, Jules Gosnell >> wrote: >> >>> Doug, >>> >>> Sorry it has taken me a while to get back - I've been busy playing >>> with code. >>> >>> I currently have a small clojure testsuite up and running. I plan to >>> broaden this and then think about providing it in a junit-compatible >>> way to your project. >>> >>> I still haven't made up my mind exactly what I should be testing. It >>> seems unnecessary to duplicate all your tests in Clojure, since you >>> are already guarding against regression in these areas - I think I >>> will start out with a fairly general set of tests as I probe for >>> particular problem areas for Clojure, into which I may dive for more >>> detail - time will tell... if you have any ideas, please let me know. >>> >>> I've checked my stuff in at github, if anyone is interested - here is >>> the project: >>> >>> https://github.com/JulesGosnell/clumatra >>> >>> here is some clojure that I reverse engineered from GraalKernelTester: >>> >>> https://github.com/JulesGosnell/clumatra/blob/master/src/clumatra/core.clj >>> >>> >>> and here are the first successful tests: >>> >>> https://github.com/JulesGosnell/clumatra/blob/master/test/clumatra/core_test.clj >>> >>> >>> not very pretty yet - I am still feeling my way. >>> >>> cheers >>> >>> >>> Jules >>> >>> >>> >>> >>> On 06/03/14 10:24, Doug Simon wrote: >>>> Hi Julian, >>>> >>>> This looks very interesting and will be an good alternative testing >>>> vector for the Sumatra work as it matures. If Clojure tests can >>>> somehow be made to run from Junit, then I?m sure we can try >>>> integrating it into our testing. >>>> >>>> -Doug >>>> >>>> On Mar 6, 2014, at 12:56 AM, Julian Gosnell >>>> wrote: >>>> >>>>> Guys, >>>>> >>>>> I just built the Java8 / Graal / Okra stack and managed to run some >>>>> very simple Clojure copying the contents of one int array into >>>>> another one on Okra. >>>>> >>>>> https://groups.google.com/forum/#!topic/clojure/JpjK__NTR5Y >>>>> >>>>> >>>>> I find the ramifications of this very exciting :-) >>>>> >>>>> I understand that fn-ality is limited at the moment - but I am keen >>>>> to keep testing and to help ensure early visibility of Clojure >>>>> related issues to both communities - perhaps even the submission of >>>>> a Clojure testsuite if Graal developers thought that useful. >>>>> >>>>> I'd be very interested in your thoughts on Graal / Clojure. >>>>> >>>>> regards, >>>>> >>>>> >>>>> Jules >>>>> >>>> >>>> >>> >> >> > > From tom.deneau at amd.com Thu Mar 20 22:03:40 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 20 Mar 2014 22:03:40 +0000 Subject: java.lang.Error running build from ecj compiler In-Reply-To: <9188A9E0-B6DB-40F0-A3A2-BB892BC5D54D@oracle.com> References: <898DD1C1-4FC5-4794-9D54-B4CA11D7AEAD@oracle.com> <44EE458D-5C7E-4727-B124-22EDEC0C04DE@oracle.com> <9188A9E0-B6DB-40F0-A3A2-BB892BC5D54D@oracle.com> Message-ID: OK, anyway it is not a blocking issue for me as I can build and run with javac after finding all the warnings. -- Tom > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Thursday, March 20, 2014 4:03 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net; Gilles Duboscq > Subject: Re: java.lang.Error running build from ecj compiler > > I'm not sure what's going as I tried your steps (using ecj-4.3.2.jar) > and never got that error when running the HSAIL unit tests. > > On Mar 20, 2014, at 8:52 PM, Deneau, Tom wrote: > > > Widening beyond just Doug and Gilles... > > > > I was cleaning up warnings from a webrev using the following sequence: > > (My webrev was based off of 5f5e2711dc24 although I'm not sure that > > matters) > > > > > > mx clean > > mx eclipseinit # has a side effect of preparing the annotation > processor jars > > mx build --vm server --vmbuild product --jdt /path/to/ecj-4.3.2.jar > > --jdt-warning-as-error mx checkstyle repeat build... > > > > > > So eventually I got a build with no compiler errors or warnings. > > Then I wanted to run our junit tests, I used the ecj produced > > bytecodes and I got > > > > > > java.lang.Error: Unresolved compilation problem: > > The method getId() from the type Node is deprecated > > > > at > com.oracle.graal.phases.common.GuardLoweringPhase$LowerGuards.lowerToIf( > GuardLoweringPhase.java:153) > > at > com.oracle.graal.phases.common.GuardLoweringPhase$LowerGuards.processNod > e(GuardLoweringPhase.java:144) > > at > com.oracle.graal.phases.graph.ScheduledNodeIterator.processNodes(Schedul > edNodeIterator.java:63) > > at > com.oracle.graal.phases.common.GuardLoweringPhase.processBlock(GuardLowe > ringPhase.java:200) > > at > com.oracle.graal.phases.common.GuardLoweringPhase.run(GuardLoweringPhase > .java:188) > > at > > com.oracle.graal.phases.common.GuardLoweringPhase.run(GuardLoweringPha > > se.java:1) > > > > I went back and did a javac build using > > mx clean > > mx build --vm server --vmbuild product > > > > This javac build ran the junits fine. > > > > I can see that Node.getId() was indeed marked @Deprecated, and that > > GuardLoweringPhase had a @SuppressWarnings("deprecation") before it's > > call to getId() > > > > Is this just because --jdt-warning-as-error is fighting against > @SuppressWarnings here or it this a problem in the ecj compiler? > > > > -- Tom > From doug.simon at oracle.com Fri Mar 21 02:00:09 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 21 Mar 2014 02:00:09 +0000 Subject: hg: graal/graal: 71 new changesets Message-ID: <201403210201.s2L21INi016163@aojmv0008> Changeset: 0f82263406e0 Author: bharadwaj Date: 2014-03-20 13:39 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/0f82263406e0 Disable three PTX tests since codegen support for byte, boolean and short is not complete ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/ObjectPTXTest.java Changeset: 0111aa258537 Author: Bernhard Urban Date: 2014-03-20 19:42 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0111aa258537 changelog: use code syntax, add some points to graal section ! CHANGELOG.md Changeset: f0bb82ebe30c Author: Christian Humer Date: 2014-03-20 17:50 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f0bb82ebe30c Truffle-DSL: some fixes and optimizations to the generated code. Fixed polymorphic specialization nodes could still reference children in some cases. Removed generation of getCost methods since they were very expensive to call. Removed generation of copyPolymorphic, setNext0. Made generated executeGeneric0 and executeAndSpecialize0 final. ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/PolymorphicTest.java ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/PolymorphicTest2.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: 2a4b6003ef03 Author: Christian Humer Date: 2014-03-20 20:39 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2a4b6003ef03 Truffle-DSL: fixed formatting problem. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: ab8a5b82fe73 Author: Christian Humer Date: 2014-03-20 20:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ab8a5b82fe73 Merge. Changeset: 07ce8ff3603d Author: Christian Wimmer Date: 2014-03-20 13:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/07ce8ff3603d Reduce unncessary list allocations in register allocator ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java Changeset: 4f5a97ba0883 Author: Christian Wimmer Date: 2014-03-20 13:42 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4f5a97ba0883 Also look for private test methods ! graal/com.oracle.graal.test/src/com/oracle/graal/test/GraalTest.java Changeset: a939edbab5ee Author: Doug Simon Date: 2014-03-20 22:30 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a939edbab5ee use remote URL for java-allocation-instrumenter.jar that includes a version suffic ! mx/projects Changeset: 8f483e200405 Author: Doug Simon Date: 2014-03-20 22:30 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8f483e200405 updated CHANGELOG.md ! CHANGELOG.md Changeset: 4c76be9856fc Author: sla Date: 2014-02-26 15:47 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4c76be9856fc 8035150: ShouldNotReachHere() in ConstantPool::copy_entry_to Reviewed-by: dcubed, mgronlun ! src/share/vm/oops/constantPool.cpp + test/serviceability/jvmti/TestRedefineWithUnresolvedClass.java + test/serviceability/jvmti/UnresolvedClassAgent.java + test/serviceability/jvmti/UnresolvedClassAgent.mf ! test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java + test/testlibrary/com/oracle/java/testlibrary/Utils.java Changeset: f6301b007a16 Author: minqi Date: 2014-02-26 15:20 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/f6301b007a16 6498581: ThreadInterruptTest3 produces wrong output on Windows Summary: There is race condition between os::interrupt and os::is_interrupted on Windows. In JVM_Sleep(Thread.sleep), check if thread gets interrupted, it may see interrupted but not really interrupted so cause spurious waking up (early return from sleep). Fix by checking if interrupt event really gets set thus prevent false return. For intrinsic of _isInterrupted, on Windows, go fastpath only on bit not set. Reviewed-by: acorn, kvn Contributed-by: david.holmes at oracle.com, yumin.qi at oracle.com ! src/os/windows/vm/os_windows.cpp ! src/share/vm/opto/library_call.cpp Changeset: 047ea31fb127 Author: sla Date: 2014-02-28 14:30 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/047ea31fb127 8036010: hs: Some jtreg tests use hard coded ports Summary: bind to an ephemeral port Reviewed-by: jbachorik, sla ! test/runtime/6294277/SourceDebugExtension.java Changeset: cd30121047ac Author: igerasim Date: 2014-02-28 16:00 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/cd30121047ac 8035893: JVM_GetVersionInfo fails to zero structure Reviewed-by: sla, zgu ! src/share/vm/prims/jvm.cpp Changeset: ef7328717719 Author: dsamersoff Date: 2014-03-01 01:36 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/ef7328717719 Merge ! src/share/vm/opto/library_call.cpp Changeset: 0d8d78c0329a Author: sspitsyn Date: 2014-03-01 08:05 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/0d8d78c0329a 6471769: Error: assert(_cur_stack_depth == count_frames(),"cur_stack_depth out of sync") Summary: It is more safe to get/update data for suspended threads at a safepoint Reviewed-by: dcubed, twisti, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiEnvThreadState.cpp ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiThreadState.cpp ! src/share/vm/runtime/vm_operations.hpp Changeset: 2edca307b15a Author: dsamersoff Date: 2014-03-01 09:56 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/2edca307b15a 8036102: part of the fix for 6498581 lost in mismerge Summary: Restore code lost in mis-merge Reviewed-by: dcubed ! src/share/vm/opto/library_call.cpp Changeset: 7380034e5b31 Author: coleenp Date: 2014-03-03 13:58 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/7380034e5b31 8035735: Metaspace::contains become extremely slow in some cases Summary: Call is_metadata instead which does less work for the call in debugInfo.hpp which is called for all compiled code stack frames. Reviewed-by: jmasa, dcubed ! src/share/vm/code/debugInfo.hpp ! src/share/vm/oops/metadata.hpp Changeset: 74dd0c7b2de1 Author: amurillo Date: 2014-03-11 16:49 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/74dd0c7b2de1 Merge Changeset: 4adcdd3ccb66 Author: coleenp Date: 2014-03-04 09:57 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/4adcdd3ccb66 8036547: test/runtime/CompressedOops/CompressedClassPointers.java fails with product build since -XX:+PrintMiscellaneous is a debug only flag Summary: Use PrintCompressedOopsMode and these other flags that match printing compressed oop information Reviewed-by: ctornqvi, sla ! src/share/vm/runtime/arguments.cpp ! test/runtime/CompressedOops/CompressedClassPointers.java Changeset: d72cee0607a3 Author: goetz Date: 2014-03-03 11:54 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d72cee0607a3 8036122: Fix warning 'format not a string literal' Reviewed-by: mduigou, kvn ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/gcc.make ! src/os/linux/vm/os_linux.cpp ! src/share/vm/compiler/compilerOracle.cpp Changeset: ff056d90e349 Author: mseledtsov Date: 2014-03-05 12:31 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/ff056d90e349 8033990: Add message to verbose output to indicate when JVM was unable to use shared archive (with -Xshare:auto) Summary: Added message to indicate when sharing was attempted but failed Reviewed-by: coleenp, ctornqvi ! src/share/vm/memory/filemap.cpp Changeset: 3c6ae9109a86 Author: anoll Date: 2014-03-03 08:04 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3c6ae9109a86 8035946: Use ResourceHashtable for dependency checking Summary: Use ResourceHashtable for dependency checking and delete GenericHashtable Reviewed-by: kvn, coleenp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/dependencies.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/resourceHash.hpp Changeset: bbfe3ac1471d Author: neliasso Date: 2014-01-28 15:05 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bbfe3ac1471d 8007270: Make IsMethodCompilable test work with tiered Summary: Only c2 compiles counts toward cutoff Reviewed-by: kvn, roland ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/testlibrary/com/oracle/java/testlibrary/Platform.java Changeset: 3c3953fb3f2a Author: shade Date: 2014-03-03 15:54 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/3c3953fb3f2a 8033380: Experimental VM flag to enforce access atomicity Summary: -XX:+AlwaysAtomicAccesses to unconditionally enforce the access atomicity. Reviewed-by: roland, kvn, iveresov ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/runtime/globals.hpp Changeset: 3edd4a71588b Author: shade Date: 2014-03-03 15:31 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/3edd4a71588b 8031818: Experimental VM flag for enforcing safe object construction Summary: -XX:+AlwaysSafeConstructors to unconditionally emit the trailing constructor barrier. Reviewed-by: kvn, roland ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/runtime/globals.hpp Changeset: 1179450ad3ee Author: vlivanov Date: 2014-03-04 02:19 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/1179450ad3ee 8035887: VM crashes trying to force inlining the recursive call Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/runtime/globals.hpp Changeset: aed8e1fe80eb Author: vlivanov Date: 2014-03-04 02:20 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/aed8e1fe80eb 8035828: Turn on @Stable support in VM Reviewed-by: jrose, twisti ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/runtime/globals.hpp + test/compiler/stable/TestStableBoolean.java + test/compiler/stable/TestStableByte.java + test/compiler/stable/TestStableChar.java + test/compiler/stable/TestStableDouble.java + test/compiler/stable/TestStableFloat.java + test/compiler/stable/TestStableInt.java + test/compiler/stable/TestStableLong.java + test/compiler/stable/TestStableObject.java + test/compiler/stable/TestStableShort.java Changeset: c0774726073e Author: vlivanov Date: 2014-03-04 02:23 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/c0774726073e 8025842: Convert warning("Thread holding lock at safepoint that vm can block on") to fatal(...) Reviewed-by: iveresov, roland, coleenp ! src/share/vm/runtime/thread.cpp Changeset: e65d960c7be5 Author: vlivanov Date: 2014-03-04 02:33 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e65d960c7be5 8036100: Default method returns true for a while, and then returns false Reviewed-by: kvn, jrose ! src/share/vm/ci/ciMethod.cpp + test/compiler/inlining/InlineDefaultMethod1.java Changeset: 131c59b5e66a Author: simonis Date: 2014-03-04 17:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/131c59b5e66a 8036614: AIX: fix adjust-mflags.sh to build with GNU Make 4.0 (adapt 8028407 for AIX) Reviewed-by: kvn ! make/aix/makefiles/adjust-mflags.sh Changeset: 81ccf2c854c7 Author: neugens Date: 2014-03-04 18:52 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/81ccf2c854c7 8036619: Shark: add LLVM 3.4 support Reviewed-by: twisti ! make/linux/makefiles/zeroshark.make ! src/share/vm/shark/llvmHeaders.hpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkCompiler.hpp ! src/share/vm/shark/sharkInliner.cpp ! src/share/vm/shark/sharkMemoryManager.cpp ! src/share/vm/shark/sharkMemoryManager.hpp Changeset: 27689a7550a8 Author: anoll Date: 2014-03-05 06:08 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/27689a7550a8 8036092: [TESTBUG] compiler/uncommontrap/TestSpecTrapClassUnloading.java fails with: Unrecognized VM option 'UseTypeSpeculation' Summary: Add -XX:+IgnoreUnrecognizedVMOptions to @main/othervm to make the test pass on Client VM Reviewed-by: kvn, roland ! test/compiler/uncommontrap/TestSpecTrapClassUnloading.java Changeset: 77ca9a58fbe8 Author: anoll Date: 2014-03-04 21:15 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/77ca9a58fbe8 Merge Changeset: a5f0657a1666 Author: anoll Date: 2014-03-05 10:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a5f0657a1666 8036091: compiler/membars/DekkerTest.java fails with -XX:CICompilerCount=1 Summary: Start test with -XX:-TieredCompilation so that one compiler thread works Reviewed-by: kvn, twisti ! src/share/vm/runtime/arguments.cpp ! test/compiler/membars/DekkerTest.java Changeset: 08adf1b5f2b6 Author: anoll Date: 2014-03-05 01:26 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/08adf1b5f2b6 Merge Changeset: 53ed0f89f44e Author: roland Date: 2014-03-05 09:29 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/53ed0f89f44e 8035841: assert(dp_src->tag() == dp_dst->tag()) failed: should be same tags 1 != 0 at ciMethodData.cpp:90 Summary: concurrent update of traps with construction of ciMethodData Reviewed-by: kvn, twisti ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp Changeset: bb4db06fd36f Author: roland Date: 2014-03-05 02:41 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/bb4db06fd36f Merge Changeset: d3f14809b051 Author: roland Date: 2014-03-05 15:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d3f14809b051 8036146: make CPP interpreter build again Summary: fix build of CPP interpreter on x86 and sparc Reviewed-by: kvn ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.inline.hpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: e0365e7b7454 Author: kvn Date: 2014-03-05 16:21 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e0365e7b7454 8035983: Fix "Native frames:" in crash report (hs_err file) Summary: check fr.sender_sp() in java thread instead of os::is_first_C_frame(&fr). Reviewed-by: twisti, coleenp ! src/share/vm/utilities/vmError.cpp Changeset: d2aa3d4e98ed Author: iignatyev Date: 2014-03-06 12:45 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/d2aa3d4e98ed 8028482: [TESTBUG] tests that use JMX should be in need_compact3 test group Reviewed-by: roland, sla, dholmes ! test/TEST.groups Changeset: c0b9499e5525 Author: iignatyev Date: 2014-03-06 12:46 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/c0b9499e5525 8027257: [TESTBUG] compiler/ciReplay/TestVM.sh : Error: Could not find or load main class negative_test Reviewed-by: roland, kvn ! test/compiler/ciReplay/TestVM.sh ! test/compiler/ciReplay/common.sh Changeset: 2dfa56e10640 Author: iignatyev Date: 2014-03-06 12:47 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/2dfa56e10640 8027124: [TESTBUG] NonTieredLevelsTest: java.lang.RuntimeException: private TestCase$Helper(java.lang.Object) must be osr_compiled Reviewed-by: kvn, roland ! test/compiler/tiered/NonTieredLevelsTest.java ! test/compiler/tiered/TieredLevelsTest.java ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java Changeset: 45b0159f30f2 Author: roland Date: 2014-03-06 11:11 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/45b0159f30f2 8032633: Enable type speculation by default Summary: enable type speculation Reviewed-by: kvn ! src/share/vm/opto/c2_globals.hpp ! test/compiler/types/TestMeetTopArrayExactConstantArray.java ! test/compiler/types/TestSpeculationFailedHigherEqual.java ! test/compiler/types/TypeSpeculation.java ! test/compiler/uncommontrap/TestSpecTrapClassUnloading.java Changeset: 84eafecdb9a9 Author: roland Date: 2014-03-06 02:37 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/84eafecdb9a9 Merge Changeset: bd2220947c1e Author: vlivanov Date: 2014-03-06 09:53 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/bd2220947c1e 8036667: "assert(adr->is_AddP() && adr->in(AddPNode::Offset)->is_Con()) failed: offset is a constant" with FoldStableValues on Reviewed-by: kvn ! src/share/vm/opto/memnode.cpp Changeset: e5e8aa897002 Author: goetz Date: 2014-03-06 10:55 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e5e8aa897002 8035647: PPC64: Support for elf v2 abi. Summary: ELFv2 ABI used by the little endian PowerPC64 on Linux. Reviewed-by: kvn Contributed-by: asmundak at google.com ! src/cpu/ppc/vm/assembler_ppc.hpp ! src/cpu/ppc/vm/assembler_ppc.inline.hpp ! src/cpu/ppc/vm/cppInterpreter_ppc.cpp ! src/cpu/ppc/vm/frame_ppc.hpp ! src/cpu/ppc/vm/interpreterRT_ppc.cpp ! src/cpu/ppc/vm/interpreter_ppc.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.hpp ! src/cpu/ppc/vm/macroAssembler_ppc.inline.hpp ! src/cpu/ppc/vm/methodHandles_ppc.cpp ! src/cpu/ppc/vm/ppc.ad ! src/cpu/ppc/vm/runtime_ppc.cpp ! src/cpu/ppc/vm/sharedRuntime_ppc.cpp ! src/cpu/ppc/vm/stubGenerator_ppc.cpp ! src/cpu/ppc/vm/vm_version_ppc.cpp ! src/share/vm/utilities/elfFile.cpp Changeset: 8c24a17f0160 Author: kvn Date: 2014-03-06 11:12 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/8c24a17f0160 Merge Changeset: 97586c131ac8 Author: simonis Date: 2014-03-06 14:35 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/97586c131ac8 8036777: AIX: Adapt implementation after '6546236: Thread interrupt() of Thread.sleep() can be lost on Solaris.' Reviewed-by: kvn ! src/os/aix/vm/os_aix.cpp ! src/os/aix/vm/os_aix.inline.hpp Changeset: 480b0109db65 Author: anoll Date: 2014-03-07 07:42 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/480b0109db65 8029799: vm/mlvm/anonloader/stress/oome prints warning: CodeHeap: # of free blocks > 10000 Summary: Double CodeCacheSegmentSize from 64 byte to 128 bytes if tiered compilation is enabled Reviewed-by: kvn, twisti ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 5e2306b00977 Author: iveresov Date: 2014-03-10 11:09 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5e2306b00977 8025644: java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java fails with TestData$OfRef): failure java.lang.AssertionError: expected [true] but found [false] Summary: In GraphKit::gen_checkcast() provide only exact superklass to GraphKit::maybe_cast_profiled_receiver() Reviewed-by: kvn, roland ! src/share/vm/opto/graphKit.cpp Changeset: 3596c63bf3d6 Author: neliasso Date: 2014-03-11 11:26 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/3596c63bf3d6 Merge Changeset: de9cd35a3d1f Author: drchase Date: 2014-03-11 13:38 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/de9cd35a3d1f 8028037: [parfait] warnings from b114 for hotspot.src.share.vm Summary: Insert null check for one warning; other warning handled in parfait config Reviewed-by: kvn ! src/share/vm/opto/multnode.cpp Changeset: a23a5456416b Author: drchase Date: 2014-03-11 10:59 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a23a5456416b Merge Changeset: 8504393de66b Author: twisti Date: 2014-03-11 14:54 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8504393de66b 8037043: put Method flag bits in predictable positions Reviewed-by: kvn, coleenp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 9e9af3aa4278 Author: iveresov Date: 2014-03-12 11:24 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9e9af3aa4278 8031321: Support Intel bit manipulation instructions Summary: Add support for BMI1 instructions Reviewed-by: kvn, roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp + test/compiler/codegen/BMI1.java Changeset: 58cf34613a72 Author: goetz Date: 2014-03-10 12:58 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/58cf34613a72 8036976: PPC64: implement the template interpreter Reviewed-by: kvn, coleenp Contributed-by: axel.siebenborn at sap.com, martin.doerr at sap.com ! make/aix/Makefile ! make/linux/Makefile ! src/cpu/ppc/vm/cppInterpreter_ppc.cpp ! src/cpu/ppc/vm/frame_ppc.cpp ! src/cpu/ppc/vm/frame_ppc.hpp ! src/cpu/ppc/vm/frame_ppc.inline.hpp ! src/cpu/ppc/vm/interp_masm_ppc_64.cpp ! src/cpu/ppc/vm/interp_masm_ppc_64.hpp ! src/cpu/ppc/vm/interpreter_ppc.cpp ! src/cpu/ppc/vm/interpreter_ppc.hpp ! src/cpu/ppc/vm/javaFrameAnchor_ppc.hpp ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.hpp ! src/cpu/ppc/vm/macroAssembler_ppc.inline.hpp ! src/cpu/ppc/vm/register_ppc.hpp ! src/cpu/ppc/vm/sharedRuntime_ppc.cpp ! src/cpu/ppc/vm/stubGenerator_ppc.cpp + src/cpu/ppc/vm/templateInterpreterGenerator_ppc.hpp + src/cpu/ppc/vm/templateInterpreter_ppc.cpp + src/cpu/ppc/vm/templateInterpreter_ppc.hpp + src/cpu/ppc/vm/templateTable_ppc_64.cpp + src/cpu/ppc/vm/templateTable_ppc_64.hpp ! src/share/vm/interpreter/templateTable.hpp Changeset: 948a73c3e9ea Author: neliasso Date: 2014-03-14 09:26 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/948a73c3e9ea Merge ! src/share/vm/runtime/arguments.cpp Changeset: 9c9f4dac029b Author: jwilhelm Date: 2014-01-31 13:38 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9c9f4dac029b 8023899: Typo in TraceCPUTime message Summary: Removed the comma Reviewed-by: pliden, tschatzl ! src/share/vm/runtime/timer.cpp Changeset: bac9ef65b71d Author: sjohanss Date: 2014-02-21 09:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bac9ef65b71d 8035057: NewSize ergonomics wrong when setting small or unaligned size on command line Summary: Making sure that if NewSize is set on the command line it should be used for both min and initial size even if it is re-aligned. Reviewed-by: jwilhelm, jmasa ! src/share/vm/memory/collectorPolicy.cpp Changeset: ea104a115537 Author: ehelin Date: 2014-03-11 15:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ea104a115537 Merge Changeset: e9ca52f59632 Author: jmasa Date: 2014-03-05 07:34 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e9ca52f59632 7098155: Resize young gen at full collections for UseParallelGC Reviewed-by: tschatzl ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp Changeset: 686d782d6121 Author: ehelin Date: 2014-03-12 13:02 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/686d782d6121 Merge Changeset: d3ef21095134 Author: ehelin Date: 2014-03-14 09:18 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d3ef21095134 Merge Changeset: d4dd5204c0aa Author: ehelin Date: 2014-03-14 13:27 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d4dd5204c0aa Merge Changeset: 9486a41de3b7 Author: amurillo Date: 2014-03-14 10:31 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/9486a41de3b7 Merge Changeset: b51e29501f30 Author: twisti Date: 2014-03-18 20:19 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b51e29501f30 Merged with jdk9/dev/hotspot changeset 9486a41de3b7 ! make/bsd/makefiles/gcc.make ! make/linux/Makefile ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/dependencies.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/memory/heap.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/timer.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 7986af88b782 Author: twisti Date: 2014-03-20 12:35 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7986af88b782 set MaxRAM value to the same used by C2 ! src/cpu/sparc/vm/graalGlobals_sparc.hpp ! src/cpu/x86/vm/graalGlobals_x86.hpp Changeset: 579a2a124c95 Author: twisti Date: 2014-03-20 13:41 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/579a2a124c95 add HotSpotMethodDataAccessor.Tag enum and dummy entries to PROFILE_DATA_ACCESSORS for new profile types ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodData.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodDataAccessor.java ! src/share/vm/runtime/vmStructs.cpp Changeset: 6ce6c4ccba8f Author: Tom Rodriguez Date: 2014-03-20 15:57 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6ce6c4ccba8f initial support for memory arithmetic on x86 ! CHANGELOG.md ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Assembler.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java + graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64MemoryPeephole.java + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryArithmeticTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java + graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotMemoryPeephole.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Arithmetic.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Compare.java + graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64TestMemoryOp.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.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/BitLogicNode.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/FloatAddNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatArithmeticNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatConvertNode.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/IntegerArithmeticNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerConvertNode.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/IntegerTestNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/NarrowNode.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/ReinterpretNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/SignExtendNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/XorNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ZeroExtendNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/ArithmeticLIRGenerator.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/MemoryArithmeticLIRLowerable.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/MemoryArithmeticLIRLowerer.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/GraalOptions.java Changeset: 0f73f8b75b81 Author: Tom Rodriguez Date: 2014-03-20 16:56 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0f73f8b75b81 printing fixes ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/Interval.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopEx.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: d3225562f0d8 Author: Tom Rodriguez Date: 2014-03-20 17:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d3225562f0d8 guard implicit exception deopt ! src/share/vm/runtime/sharedRuntime.cpp From rich.and.good.looking at gmail.com Fri Mar 21 05:10:31 2014 From: rich.and.good.looking at gmail.com (Richard Anderson) Date: Thu, 20 Mar 2014 23:10:31 -0600 Subject: fix compiler / GLIBC mismatch? Message-ID: graal enabled version of "jruby-9000+graal-dev" throws following `GLIBC_2.14' not found error message when running on a Red Hat / CentOS Linux x86_64 server with 3.4.82 kernel: [~] # ruby -version "/home/someuser/.rbenv/versions/jruby-9000+graal-dev/graalvm-jdk1.8.0/bin/java: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /home/someuser/.rbenv/versions/jruby-9000+graal-dev/graalvm-jdk1.8.0/bin/../lib/amd64/jli/libjli.so)" Does anyone have any insight about how to fix this? PS: I have NO admin / superuser privileges on that server and might need to compile a graal binary somewhere else so it works, but do not know how to proceed with that, can anyone please provide me any guidance? PS 2: running gcc version: [~]# gcc --version gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4) Thanks in advance for the help. Rx.Nix From java at stefan-marr.de Fri Mar 21 16:21:25 2014 From: java at stefan-marr.de (Stefan Marr) Date: Fri, 21 Mar 2014 17:21:25 +0100 Subject: [FeatureRequest] Allow building in non-HG repositories. Message-ID: Hi: For a while, I have the work-around below in my copy of the Graal repository to enable building in a git-based environment. Would it be possible to integrate something along those lines? I guess, currently it is also not possible to build graal without errors from a simple source tarball. For me, upstreaming this would make it easier to test against the latest version of Graal. Thanks Stefan diff --git a/mx/mx_graal.py b/mx/mx_graal.py index fb258fc..73cccfd 100644 --- a/mx/mx_graal.py +++ b/mx/mx_graal.py @@ -647,7 +647,11 @@ def build(args, vm=None): env.setdefault('ALT_BOOTDIR', mx.java().jdk) # extract latest release tag for graal - tags = [x.split(' ')[0] for x in subprocess.check_output(['hg', 'tags']).split('\n') if x.startswith("graal-")] + try: + tags = [x.split(' ')[0] for x in subprocess.check_output(['hg', 'tags']).split('\n') if x.startswith("graal-")] + except (subprocess.CalledProcessError, OSError): + with open('.hgtags') as f: + tags = [x.split(' ')[0] for x in f.readlines() if x.startswith("graal-")] if tags: # extract the most recent tag tag = sorted(tags, key=lambda e: [int(x) for x in e[len(?graal-"):].split('.')], reverse=True)[0] -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From doug.simon at oracle.com Sat Mar 22 02:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 22 Mar 2014 02:00:06 +0000 Subject: hg: graal/graal: 10 new changesets Message-ID: <201403220200.s2M20KJB028861@aojmv0008> Changeset: 6fd5f25b546c Author: Lukas Stadler Date: 2014-03-21 10:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6fd5f25b546c keep the guard alive when removing ReadNodes without usages + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/except/BC_getfield1.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ReadEliminationClosure.java Changeset: ba4b79da6351 Author: Lukas Stadler Date: 2014-03-20 14:13 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ba4b79da6351 canonicalize certain shift-compare expressions + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/IntegerEqualsCanonicalizerTest.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/LeftShiftNode.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/ShiftNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/UnsignedRightShiftNode.java Changeset: 91ed2ba34b06 Author: Lukas Stadler Date: 2014-03-20 14:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/91ed2ba34b06 test case for IfNode reordering fix (a300322) + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/IfReorderTest.java Changeset: c8fb80093621 Author: Lukas Stadler Date: 2014-03-21 11:51 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c8fb80093621 metric for number of implicit null checks in GuardLoweringPhase ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java Changeset: b602356a9cfc Author: Lukas Stadler Date: 2014-03-20 17:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b602356a9cfc additional canonicalizers for accesses and value nodes (improves number of implicit null checks) ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FixedAccessNode.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/ReadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ValueAnchorNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java Changeset: 4ea4db3f23ba Author: Christian Humer Date: 2014-03-21 13:54 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4ea4db3f23ba Truffle: fixed call count profile; added leaf check for inlining; inline tracing now shows dispatched calls. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/CompilationProfile.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallNodeProfile.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java Changeset: 03704aa6e71b Author: Christian Humer Date: 2014-03-21 13:54 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/03704aa6e71b Merge. Changeset: aa1a43bfdf4e Author: twisti Date: 2014-03-21 14:26 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/aa1a43bfdf4e make HotSpotResolvedJavaMethod leaner ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalJavaAccess.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 25359cbb95e3 Author: Tom Rodriguez Date: 2014-03-21 15:28 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/25359cbb95e3 don't do subword float converts ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryArithmeticTest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatConvertNode.java Changeset: 0bdd0d157040 Author: Tom Rodriguez Date: 2014-03-21 16:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0bdd0d157040 fix vargs -> Object -> vargs logging call paths ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/IterativeInliningPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualUtil.java From D.Sturm42 at gmail.com Sun Mar 23 11:03:34 2014 From: D.Sturm42 at gmail.com (D.Sturm) Date: Sun, 23 Mar 2014 12:03:34 +0100 Subject: Enable assertions Message-ID: Is there a way to enable assertions in Graal? Running with ./mx.sh --vmbuild debug vm -ea -graal SomeFile will only enable assertions for the run files (i.e. SomeFile), but not for the Graal code itself. --Daniel From doug.simon at oracle.com Sun Mar 23 11:07:08 2014 From: doug.simon at oracle.com (Doug Simon) Date: Sun, 23 Mar 2014 12:07:08 +0100 Subject: Enable assertions In-Reply-To: References: Message-ID: <5DE197D1-309B-49E5-9831-7930EB6D89D8@oracle.com> You need to use -esa since Graal is on the boot class path. Sent from my iPhone > On Mar 23, 2014, at 12:03 PM, "D.Sturm" wrote: > > Is there a way to enable assertions in Graal? > > Running with > ./mx.sh --vmbuild debug vm -ea -graal SomeFile > will only enable assertions for the run files (i.e. SomeFile), but not for > the Graal code itself. > > --Daniel From bernhard.urban at jku.at Sun Mar 23 12:26:37 2014 From: bernhard.urban at jku.at (Bernhard Urban) Date: Sun, 23 Mar 2014 13:26:37 +0100 Subject: fix compiler / GLIBC mismatch? In-Reply-To: References: Message-ID: Hi Richard, we use Ubuntu 12.04 LTS on our build machines, which uses GLIBC_2.15. I'm afraid you have to compile graal yourself. If you have GCC & friends and python2.7 available on this machine it shouldn't be too hard though! [1, 2] You don't need root privilege for that. If you have any further questions, let me know. -Bernhard [1] https://wiki.openjdk.java.net/display/Graal/Instructions [2] https://github.com/jruby/jruby/wiki/truffle#building-graal-optional On Fri, Mar 21, 2014 at 6:10 AM, Richard Anderson < rich.and.good.looking at gmail.com> wrote: > graal enabled version of "jruby-9000+graal-dev" throws following > `GLIBC_2.14' not found error message when running on a Red Hat / CentOS > Linux x86_64 server with 3.4.82 kernel: > > [~] # ruby -version > > "/home/someuser/.rbenv/versions/jruby-9000+graal-dev/graalvm-jdk1.8.0/bin/java: > /lib64/libc.so.6: version `GLIBC_2.14' not found (required by > > /home/someuser/.rbenv/versions/jruby-9000+graal-dev/graalvm-jdk1.8.0/bin/../lib/amd64/jli/libjli.so)" > > Does anyone have any insight about how to fix this? > > PS: I have NO admin / superuser privileges on that server and might need > to compile a graal binary somewhere else so it works, but do not know how > to proceed with that, can anyone please provide me any guidance? > > PS 2: running gcc version: > > [~]# gcc --version > gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4) > > > Thanks in advance for the help. > > Rx.Nix > > From D.Sturm42 at gmail.com Sun Mar 23 22:08:49 2014 From: D.Sturm42 at gmail.com (D.Sturm) Date: Sun, 23 Mar 2014 23:08:49 +0100 Subject: firstVariableNumber initialization for LinearScan Message-ID: The constructor for LinearScan uses "this.firstVariableNumber = registers.length;" to assign the first non-register id it can use. That's a problem if the register numbering does have jumps in it, which happens to be true for the Aarch64 HotSpot runtime. Could we replace it with something like int maxRegNumber = -1; for (Register reg : this.registers) { maxRegNumber = Math.max(maxRegNumber, reg.number); } this.firstVariableNumber = maxRegNumber + 1; Otherwise I'd have to introduce a sequential numbering system for Graal and translate register numbers when transitioning from Graal to HotSpot. --Daniel From doug.simon at oracle.com Mon Mar 24 09:18:31 2014 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 24 Mar 2014 10:18:31 +0100 Subject: firstVariableNumber initialization for LinearScan In-Reply-To: References: Message-ID: Hi Daniel, On Mar 23, 2014, at 11:08 PM, D.Sturm wrote: > The constructor for LinearScan uses "this.firstVariableNumber = > registers.length;" to assign the first non-register id it can use. > > That's a problem if the register numbering does have jumps in it, which > happens to be true for the Aarch64 HotSpot runtime. Doesn?t the com.oracle.graal.api.code.Architecture.registers for Aarch64 then have to contain dummy entries for the register numbers for which there no real registers? It would need to so as to conform with the specification of Architecture.getRegisters(): /** * Gets an array of all available registers on this architecture. The index of each register in * this array is equal to its {@linkplain Register#number number}. */ public Register[] getRegisters() { return registers.clone(); } This specification is what allows "this.firstVariableNumber = registers.length;? to be correct for all architectures. I wouldn?t be surprised if this property is assumed in other places as well. So, you?d either need to use the dummy entries I mention above or use the translation table you mention below. > Could we replace it with something like > int maxRegNumber = -1; > for (Register reg : this.registers) { > maxRegNumber = Math.max(maxRegNumber, reg.number); > } > this.firstVariableNumber = maxRegNumber + 1; > > Otherwise I'd have to introduce a sequential numbering system for Graal and > translate register numbers when transitioning from Graal to HotSpot. -Doug From bernhard.urban at jku.at Mon Mar 24 09:47:44 2014 From: bernhard.urban at jku.at (Bernhard Urban) Date: Mon, 24 Mar 2014 10:47:44 +0100 Subject: [FeatureRequest] Allow building in non-HG repositories. In-Reply-To: References: Message-ID: Hi Stefan, thanks, that's a good point! However I think you should not try to read the .hgtags file manually, unless you implement the semantics of it. For example, if you delete a tag, there'll be two entries in .hgtags (one for creation and one for removal). Also, what if there is no .hgtags file? Therefore if `hg tags' fails, we should just not set USER_RELEASE_SUFFIX. I'll push a fix. Thanks, Bernhard On Fri, Mar 21, 2014 at 5:21 PM, Stefan Marr wrote: > Hi: > > For a while, I have the work-around below in my copy of the Graal > repository to enable building in a git-based environment. > > Would it be possible to integrate something along those lines? > I guess, currently it is also not possible to build graal without errors > from a simple source tarball. > For me, upstreaming this would make it easier to test against the latest > version of Graal. > > Thanks > Stefan > > > diff --git a/mx/mx_graal.py b/mx/mx_graal.py > index fb258fc..73cccfd 100644 > --- a/mx/mx_graal.py > +++ b/mx/mx_graal.py > @@ -647,7 +647,11 @@ def build(args, vm=None): > env.setdefault('ALT_BOOTDIR', mx.java().jdk) > > # extract latest release tag for graal > - tags = [x.split(' ')[0] for x in > subprocess.check_output(['hg', 'tags']).split('\n') if > x.startswith("graal-")] > + try: > + tags = [x.split(' ')[0] for x in > subprocess.check_output(['hg', 'tags']).split('\n') if > x.startswith("graal-")] > + except (subprocess.CalledProcessError, OSError): > + with open('.hgtags') as f: > + tags = [x.split(' ')[0] for x in f.readlines() if > x.startswith("graal-")] > if tags: > # extract the most recent tag > tag = sorted(tags, key=lambda e: [int(x) for x in > e[len("graal-"):].split('.')], reverse=True)[0] > > > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > From D.Sturm42 at gmail.com Mon Mar 24 10:14:04 2014 From: D.Sturm42 at gmail.com (D.Sturm) Date: Mon, 24 Mar 2014 11:14:04 +0100 Subject: firstVariableNumber initialization for LinearScan In-Reply-To: References: Message-ID: Hi, You're right, I missed that requirement - would've saved me some time debugging the register allocator. I'll use a dummy register then and assert that it's not used, should be the easiest solution. --Daniel On 24 March 2014 10:18, Doug Simon wrote: > Hi Daniel, > > On Mar 23, 2014, at 11:08 PM, D.Sturm wrote: > > > The constructor for LinearScan uses "this.firstVariableNumber = > > registers.length;" to assign the first non-register id it can use. > > > > That's a problem if the register numbering does have jumps in it, which > > happens to be true for the Aarch64 HotSpot runtime. > > Doesn?t the com.oracle.graal.api.code.Architecture.registers for Aarch64 > then have to contain dummy entries for the register numbers for which there > no real registers? It would need to so as to conform with the specification > of Architecture.getRegisters(): > > /** > * Gets an array of all available registers on this architecture. The > index of each register in > * this array is equal to its {@linkplain Register#number number}. > */ > public Register[] getRegisters() { > return registers.clone(); > } > > This specification is what allows "this.firstVariableNumber = > registers.length;? to be correct for all architectures. I wouldn?t be > surprised if this property is assumed in other places as well. > > So, you?d either need to use the dummy entries I mention above or use the > translation table you mention below. > > > Could we replace it with something like > > int maxRegNumber = -1; > > for (Register reg : this.registers) { > > maxRegNumber = Math.max(maxRegNumber, reg.number); > > } > > this.firstVariableNumber = maxRegNumber + 1; > > > > Otherwise I'd have to introduce a sequential numbering system for Graal > and > > translate register numbers when transitioning from Graal to HotSpot. > > -Doug > From doug.simon at oracle.com Mon Mar 24 11:12:46 2014 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 24 Mar 2014 12:12:46 +0100 Subject: webrev-hsail-deopt-v2 In-Reply-To: References: Message-ID: <733ABFAA-23DD-4652-8DDC-7E9154704CFC@oracle.com> Tom, Thanks for fixing the issues in the first patch. Apart from some seemingly excessive memory usage (which can hopefully be address later), the logic in this patch looks mostly correct to me. However, Gilles needs to also provide feedback before we can integrate this patch as he is more familiar with some of the details. Per-file comments below. graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java: These cannot be fields in HSAILHotSpotBackend as they are per-compilation values, not per-backend values: + private HSAILAssembler asm; + private LIRGenerator lirGen; There?s no real value in having HSAILNonNullParametersPhase extend NonNullParametersPhase since the former overrides all the logic in the latter. graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java: Please create named constants for 40 and 8 that explains what they are: 204 if (regNumber < 40) { 205 long offset = config.hsailFrameSaveAreaOffset + 4 * (regNumber - 8); src/gpu/hsail/vm/gpu_hsail.hpp: It would be nice to see the CU acronym explained somewhere. I know that you are thinking of supporting multiple frames in the future but I would not include code partially supporting that now otherwise it just adds confusion. For example, the first frame is contained in a HSAILKernelDeoptimization object, but HSAILFrame::_nextFrame is a pointer to a HSAILFrame. Who allocates/deallocates the next frame(s)? 46 HSAILFrame _first_frame; What?s the point of HSAILComputeUnitSaveState? In future will it do more than simply wrap a HSAILKernelDeoptimization? 55 class HSAILComputeUnitSaveState { 56 friend class VMStructs; 57 public: 58 HSAILKernelDeoptimization _deopt_info; 59 }; Why not make the definition extra clear by making the preprocessor do the math (i.e. "#define CU_SAVE_STATES_SIZE (8 * 36 * 64)?) 61 // 8 cus * 36 waves per cu * wavesize 64 62 #define CU_SAVE_STATES_SIZE 18432 Let?s use a longer name for clarity (e.g., _sizeof_compute_unit_save_state). This should also be reflect in HotSpotVMConfig. 69 jint _sizeof_cuss; src/gpu/hsail/vm/gpu_hsail.cpp: I was going to suggest stack allocating the HSAILDeoptimizationInfo until I realized it?s 20Mb! Is that a conservative approach we can improve upon somehow (e.g., a lazily created thread local)? In any case, shouldn?t the actual allocation be within the ?if (useDeoptInfo)? guard? 149 HSAILDeoptimizationInfo* e = new (ResourceObj::C_HEAP, mtInternal) HSAILDeoptimizationInfo(); 150 if (useDeoptInfo) { -Doug On Mar 20, 2014, at 9:57 PM, Deneau, Tom wrote: > Doug, Gilles -- > > I believe I have gotten rid of the warnings from the original hsail-deopt webrev. > I also fixed a few casts that Eric Caspole noticed were preventing the fastdebug build from building > (but did not affect product and debug builds). Please take a look at > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt-v2 > > I've included here the explanatory text from the first submission > > This consists of at least the start of support for deoptimization in HSAIL kernels. Although the list of files changed may look long, many of the files have only a few lines changed. Special thanks to Gilles Duboscq and Doug Simon who provided some of the infrastructure that this webrev uses. > > -- Tom Deneau > > > Below I have described > > * an overview of the codepaths the data structures > * java and hotspot source changes > > > Deoptimization Data Structures and Overview > =========================================== > > At kernel dispatch time, we allocate space for any workitems should want to deopt. To reduce the space requirements, space is only reserved for the maximum number of possible concurrent workitems that could be running on that hsa device. > > A deopting workitem sets a "deopt happened" flag, and future workitems that see "deopt happened" as true will just set a flag saying they never ran and exit early. Currently the never_ran array is one per workitem. We are looking at ways to make this smaller but HSA devices have a lot of freedom in how they schedule workitems (current hardware and the simulator are quite different). > > Workitems that deopt atomically bump an index saying where they should store their deopt data. The deopt data consists of > * workitemid > * deopt actionAndReason > * the first HSAILFrame > > An HSAILFrame consists of > * the deoptId or "pc" offset where the deopt occurred > * number of s registers > * number of d registers > * a bitmap indicating which d registers are oops > * space for saving the d and s registers > > Currently we always set num_s_registers to 32 and num_d_registers to > 16 but in the hsail code of the kernel we only save the union of the actual registers that are live at any of the infopoints. > > On return from the GPU, we check if there were any deopts. If not, we just return back to java. If there was at least one deopt then > > a) for the workitems that finished normally, there is nothing to do > > b) if there are any deopted workitems, we want to run each deopting > workitem thru the interpreter going first thru the special host > trampoline code infrastructure that Gilles created. The > trampoline host code takes the deoptId and a pointer to the > saved hsail frame. We currently do this sequentially although > other policies are possible. > > c) for each never ran workitem, we can just run it from the > beginning of the kernel "method", just making sure we pass the > arguments and the appropriate workitem id for each one. Again, > we currently do this sequentially although other policies are > possible. > > Because running either type b or c above can cause GCs, and because some of our saved d registers are pointers into the java heap, we take care in case any of these saved pointers are affected by GC. The current strategy of using an Object array supplied by the java side will be replaced later with an oops_do type of strategy. > > > > Description of source changes in this webrev. > ============================================= > graal source changes > ==================== > > Assembler, HSAILAssembler > minor changes for new instructions needed for saving deopt information > > GraalKernelTester.java > force simulator to run single threaded. > > KernelTester.java > minor changes to handle exceptions which escape the kernel method > > HSAILLIRGenerator.java > support switches with keys of type long > > > HSAILHotSpotBackend.java > > * compileKernel uses some new optimisticOpts which help generate > deopts when needed. Also, we dump the infopoints if Log:CodeGen > is on > > * HSAILNonNullParametersPhase stamps the appropriate parameters as > nonNull > > * installKernel uses the new trampoline infrastructure added by > Gilles do produce the host trampoline deopt method and install > it. > > * emitCode adds a little bit of code to the prologue and a lot of > code to the epilogue. See description at the bottom for the data > structures used by the never-ran path and the deopt path. > > HSAILHotSpotLIRGenerator.java > > * code added by Gilles to build the host graph for the host > trampoline deopt method. I suppose some of this would be common > to any gpu trampoline deopt and should be moved to some > hsail-independent location. > > * code to handle the creation of a DeoptimizeOp for emitting HSAIL > code for a deoptimization > > HSAILHotSpotLoweringProvider.java > > * refactored to support different strategies for different nodes. > UnwindNode strategy is to get replaced by a DeoptimizeNode. > > HotSpotVMConfig.java > > * define offets to fields in the deopt data structures > > VMErrorNode.java > > * public access to constructor (used by building of host graph for > trampoline code) > > HSAIL.java > * some new non-allocatable registers defined (used by deopt paths) > > HSAILControlFlow.java > * code to emit hsail for a deoptimizationNode > > ComputeProbabilityClosure.java > * just using a change that Gilles made in the patch he gave me. > > > mx/projects was affected by the move of ExternalCompilationResult to com.oracle.graal.gpu. In addition, several files had one line import changes from the move of ExternalCompilationResult. > > > hotspot source changes > ====================== > > gpu_hsail.cpp, hpp > > * the execute_kernel routine pushes an extra parameter where deopt info can be saved > > * while pushing kernel args, keeps track if any are null and if so > sets some new gpu_exception fields in thread structure which gets > used when thread returns to java mode > > * on return from kernel checks if any deopt occurred. If so, > > * runs any deopting workitems thru the trampoline deopt code > which ends up running the kernel method thru the interpreter > for that workitem. > > * runs any never-ran workitems using simple javaCall. > > gpu_hsail_Frame.hpp > * new structure that defines the layout of a physical HSAIL frame > > hsailArgumentsBase.*, hsailKernelArguments.hpp hsailJavaCallArguments.hpp > * refactored to share code between kernel argument setup and > javaCall argument setup > > javaClasses.cpp > > * contains logic to check the new gpu_exception fields in thread > structure and if detected, set as top frame on return > > graalCompiler.cpp, hpp > * logic added by Gilles for external_deopt_i2c > > javaCalls.cpp, hpp > * logic added by Gilles for external_deopt_i2c > > sharedRuntime.cpp > * maybe Gilles can explain why the assert was removed in the patch > he gave me (it asserts if I put it back in) > > thread.cpp, hpp > * handle new gpu_exception fields > > vmStructs.cpp > vmStructs_hsail.hpp > * handle new hsail deopt structs > > > > From Eric.Caspole at amd.com Mon Mar 24 13:01:30 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Mon, 24 Mar 2014 13:01:30 +0000 Subject: new webrev for HSAILHotSpotLIRGenerator small fixes In-Reply-To: <80EEE310-5184-4ED0-B866-D8A1DCDB832A@oracle.com> References: , <80EEE310-5184-4ED0-B866-D8A1DCDB832A@oracle.com> Message-ID: Hi Doug, I finally remembered to do this - http://cr.openjdk.java.net/~ecaspole/hsail_lir_update/ Thanks, Eric ________________________________________ From: Doug Simon [doug.simon at oracle.com] Sent: Thursday, March 20, 2014 11:17 AM To: Caspole, Eric Cc: graal-dev at openjdk.java.net Subject: Re: new webrev for HSAILHotSpotLIRGenerator small fixes Hi Eric, Since submitting this patch, the Kind.NarrowOop value was removed[1]. Can you please generate a new webrev based on the tip. -Doug [1] http://hg.openjdk.java.net/graal/graal/rev/82e4fe6fa525 On Mar 19, 2014, at 1:54 PM, Caspole, Eric wrote: > Hi everybody, > I put a new webrev here - > > http://cr.openjdk.java.net/~ecaspole/hsail_lir/webrev/ > > This fixes 2 issues I found while trying Clumatra: storing compressed constants was not implemented yet (thanks Tom D for this), and previously HSAILHotSpotLIRGenerator did not "implements HotSpotLIRGenerator" so some methods would fail to compile with ClassCastExceptions in the middle of compilation. I implemented dummy stubs for all that that throws NYI instead. > Regards, > Eric > From doug.simon at oracle.com Mon Mar 24 13:43:09 2014 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 24 Mar 2014 14:43:09 +0100 Subject: new webrev for HSAILHotSpotLIRGenerator small fixes In-Reply-To: References: , <80EEE310-5184-4ED0-B866-D8A1DCDB832A@oracle.com> Message-ID: Looks good to me. Pushing the change through now? On Mar 24, 2014, at 2:01 PM, Caspole, Eric wrote: > Hi Doug, > I finally remembered to do this - > > http://cr.openjdk.java.net/~ecaspole/hsail_lir_update/ > > Thanks, > Eric > > ________________________________________ > From: Doug Simon [doug.simon at oracle.com] > Sent: Thursday, March 20, 2014 11:17 AM > To: Caspole, Eric > Cc: graal-dev at openjdk.java.net > Subject: Re: new webrev for HSAILHotSpotLIRGenerator small fixes > > Hi Eric, > > Since submitting this patch, the Kind.NarrowOop value was removed[1]. Can you please generate a new webrev based on the tip. > > -Doug > > [1] http://hg.openjdk.java.net/graal/graal/rev/82e4fe6fa525 > > On Mar 19, 2014, at 1:54 PM, Caspole, Eric wrote: > >> Hi everybody, >> I put a new webrev here - >> >> http://cr.openjdk.java.net/~ecaspole/hsail_lir/webrev/ >> >> This fixes 2 issues I found while trying Clumatra: storing compressed constants was not implemented yet (thanks Tom D for this), and previously HSAILHotSpotLIRGenerator did not "implements HotSpotLIRGenerator" so some methods would fail to compile with ClassCastExceptions in the middle of compilation. I implemented dummy stubs for all that that throws NYI instead. >> Regards, >> Eric >> > > > From doug.simon at oracle.com Tue Mar 25 02:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 25 Mar 2014 02:00:06 +0000 Subject: hg: graal/graal: 9 new changesets Message-ID: <201403250200.s2P20Ig3020572@aojmv0008> Changeset: af7b9b9a9a28 Author: Bernhard Urban Date: 2014-03-24 09:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/af7b9b9a9a28 mx build: ignore release tag suffix if build directory is not a mercurial repository ! mx/mx_graal.py Changeset: ede5735ed267 Author: Lukas Stadler Date: 2014-03-24 10:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ede5735ed267 deal with deleted ends in ConvertDeoptimizeToGuardPhase ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConvertDeoptimizeToGuardPhase.java Changeset: 8dfd3f53ba4a Author: Gilles Duboscq Date: 2014-03-24 11:24 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8dfd3f53ba4a Update vm descriptions in readme ! README.md Changeset: 4c5ed5a670ed Author: Doug Simon Date: 2014-03-24 14:41 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4c5ed5a670ed HSAIL: implemented storing compressed constants and made HSAILHotSpotLIRGenerator implement HotSpotLIRGenerator Contributed-by: Eric Caspole ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java Changeset: c3ec1e4494b8 Author: Lukas Stadler Date: 2014-03-24 13:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c3ec1e4494b8 update BenchmarkCounters (add TimedDynamicCounters, fix -XX:+GraalCountersExcludeCompiler) + graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/CompilerThread.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/CompilerThreadFactory.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/debug/BenchmarkCounters.java ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp Changeset: ba7b08d90fde Author: Lukas Stadler Date: 2014-03-24 14:02 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ba7b08d90fde new ProfileCompiledMethods tool ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/LowTier.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ProfileCompiledMethodsPhase.java Changeset: 92aa6797d639 Author: Doug Simon Date: 2014-03-24 21:30 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/92aa6797d639 Backed out merge changeset: b51e29501f30 Backed out merge revision to its first parent (8f483e200405) ! make/aix/Makefile ! make/aix/makefiles/adjust-mflags.sh ! make/bsd/makefiles/gcc.make ! make/linux/Makefile ! make/linux/makefiles/gcc.make ! make/linux/makefiles/zeroshark.make ! make/solaris/makefiles/gcc.make ! src/cpu/ppc/vm/assembler_ppc.hpp ! src/cpu/ppc/vm/assembler_ppc.inline.hpp ! src/cpu/ppc/vm/cppInterpreter_ppc.cpp ! src/cpu/ppc/vm/frame_ppc.cpp ! src/cpu/ppc/vm/frame_ppc.hpp ! src/cpu/ppc/vm/frame_ppc.inline.hpp ! src/cpu/ppc/vm/interp_masm_ppc_64.cpp ! src/cpu/ppc/vm/interp_masm_ppc_64.hpp ! src/cpu/ppc/vm/interpreterRT_ppc.cpp ! src/cpu/ppc/vm/interpreter_ppc.cpp ! src/cpu/ppc/vm/interpreter_ppc.hpp ! src/cpu/ppc/vm/javaFrameAnchor_ppc.hpp ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.hpp ! src/cpu/ppc/vm/macroAssembler_ppc.inline.hpp ! src/cpu/ppc/vm/methodHandles_ppc.cpp ! src/cpu/ppc/vm/ppc.ad ! src/cpu/ppc/vm/register_ppc.hpp ! src/cpu/ppc/vm/runtime_ppc.cpp ! src/cpu/ppc/vm/sharedRuntime_ppc.cpp ! src/cpu/ppc/vm/stubGenerator_ppc.cpp - src/cpu/ppc/vm/templateInterpreterGenerator_ppc.hpp - src/cpu/ppc/vm/templateInterpreter_ppc.cpp - src/cpu/ppc/vm/templateInterpreter_ppc.hpp - src/cpu/ppc/vm/templateTable_ppc_64.cpp - src/cpu/ppc/vm/templateTable_ppc_64.hpp ! src/cpu/ppc/vm/vm_version_ppc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.inline.hpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os/aix/vm/os_aix.cpp ! src/os/aix/vm/os_aix.inline.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/dependencies.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/metadata.hpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiEnvThreadState.cpp ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiThreadState.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/timer.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/shark/llvmHeaders.hpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkCompiler.hpp ! src/share/vm/shark/sharkInliner.cpp ! src/share/vm/shark/sharkMemoryManager.cpp ! src/share/vm/shark/sharkMemoryManager.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/resourceHash.hpp ! src/share/vm/utilities/vmError.cpp ! test/TEST.groups ! test/compiler/ciReplay/TestVM.sh ! test/compiler/ciReplay/common.sh - test/compiler/codegen/BMI1.java - test/compiler/inlining/InlineDefaultMethod1.java ! test/compiler/membars/DekkerTest.java - test/compiler/stable/TestStableBoolean.java - test/compiler/stable/TestStableByte.java - test/compiler/stable/TestStableChar.java - test/compiler/stable/TestStableDouble.java - test/compiler/stable/TestStableFloat.java - test/compiler/stable/TestStableInt.java - test/compiler/stable/TestStableLong.java - test/compiler/stable/TestStableObject.java - test/compiler/stable/TestStableShort.java ! test/compiler/tiered/NonTieredLevelsTest.java ! test/compiler/tiered/TieredLevelsTest.java ! test/compiler/types/TestMeetTopArrayExactConstantArray.java ! test/compiler/types/TestSpeculationFailedHigherEqual.java ! test/compiler/types/TypeSpeculation.java ! test/compiler/uncommontrap/TestSpecTrapClassUnloading.java ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java ! test/runtime/6294277/SourceDebugExtension.java ! test/runtime/CompressedOops/CompressedClassPointers.java - test/serviceability/jvmti/TestRedefineWithUnresolvedClass.java - test/serviceability/jvmti/UnresolvedClassAgent.java - test/serviceability/jvmti/UnresolvedClassAgent.mf ! test/testlibrary/com/oracle/java/testlibrary/Platform.java ! test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java - test/testlibrary/com/oracle/java/testlibrary/Utils.java Changeset: 8b772174c514 Author: Doug Simon Date: 2014-03-24 23:50 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8b772174c514 Backport of 8504393de66b from jdk9 ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: d09194f75dd4 Author: Doug Simon Date: 2014-03-24 23:50 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d09194f75dd4 Merge. From tom.deneau at amd.com Tue Mar 25 17:09:34 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 25 Mar 2014 17:09:34 +0000 Subject: webrev-hsail-deopt-v2 In-Reply-To: <733ABFAA-23DD-4652-8DDC-7E9154704CFC@oracle.com> References: <733ABFAA-23DD-4652-8DDC-7E9154704CFC@oracle.com> Message-ID: Doug, Gilles -- Regarding the private LIRGenerator lirGen; in HSAILHotSpotBackend.java. I agree with your statement that lirGen should be per-compilation, not per backend. I added it only because it was needed by the code Gilles added at the end of emitCode compilationResult.setHostGraph(((HSAILHotSpotLIRGenerator) lirGen).prepareHostGraph()); I see that lirGen is passed in to newCompilationResultBuilder and used in that method but was not saved anywhere. I thought perhaps it could be saved in CompilationResultBuilder itself, but that led to the dreaded loops in the project graphs (if I made com.oracle.graal.compiler project a dependency of com.oracle.graal.lir). So what is the best way to solve this problem? -- Tom > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Monday, March 24, 2014 6:13 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev-hsail-deopt-v2 > > Tom, > > Thanks for fixing the issues in the first patch. Apart from some > seemingly excessive memory usage (which can hopefully be address later), > the logic in this patch looks mostly correct to me. However, Gilles > needs to also provide feedback before we can integrate this patch as he > is more familiar with some of the details. > > Per-file comments below. > > graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/ > HSAILHotSpotBackend.java: > > These cannot be fields in HSAILHotSpotBackend as they are per- > compilation values, not per-backend values: > > + private HSAILAssembler asm; > + private LIRGenerator lirGen; > > There's no real value in having HSAILNonNullParametersPhase extend > NonNullParametersPhase since the former overrides all the logic in the > latter. > > graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/ > HSAILHotSpotLIRGenerator.java: > > Please create named constants for 40 and 8 that explains what they are: > > 204 if (regNumber < 40) { > 205 long offset = config.hsailFrameSaveAreaOffset + 4 * > (regNumber - 8); > > src/gpu/hsail/vm/gpu_hsail.hpp: > > It would be nice to see the CU acronym explained somewhere. > > I know that you are thinking of supporting multiple frames in the future > but I would not include code partially supporting that now otherwise it > just adds confusion. For example, the first frame is contained in a > HSAILKernelDeoptimization object, but HSAILFrame::_nextFrame is a > pointer to a HSAILFrame. Who allocates/deallocates the next frame(s)? > > 46 HSAILFrame _first_frame; > > What's the point of HSAILComputeUnitSaveState? In future will it do more > than simply wrap a HSAILKernelDeoptimization? > > 55 class HSAILComputeUnitSaveState { > 56 friend class VMStructs; > 57 public: > 58 HSAILKernelDeoptimization _deopt_info; > 59 }; > > Why not make the definition extra clear by making the preprocessor do > the math (i.e. "#define CU_SAVE_STATES_SIZE (8 * 36 * 64)") > > 61 // 8 cus * 36 waves per cu * wavesize 64 > 62 #define CU_SAVE_STATES_SIZE 18432 > > Let's use a longer name for clarity (e.g., > _sizeof_compute_unit_save_state). This should also be reflect in > HotSpotVMConfig. > > 69 jint _sizeof_cuss; > > src/gpu/hsail/vm/gpu_hsail.cpp: > > I was going to suggest stack allocating the HSAILDeoptimizationInfo > until I realized it's 20Mb! Is that a conservative approach we can > improve upon somehow (e.g., a lazily created thread local)? In any case, > shouldn't the actual allocation be within the "if (useDeoptInfo)" guard? > > 149 HSAILDeoptimizationInfo* e = new (ResourceObj::C_HEAP, mtInternal) > HSAILDeoptimizationInfo(); > 150 if (useDeoptInfo) { > > -Doug > > On Mar 20, 2014, at 9:57 PM, Deneau, Tom wrote: > > > Doug, Gilles -- > > > > I believe I have gotten rid of the warnings from the original hsail- > deopt webrev. > > I also fixed a few casts that Eric Caspole noticed were preventing the > fastdebug build from building > > (but did not affect product and debug builds). Please take a look > at > > > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt- > v2 > > > > I've included here the explanatory text from the first submission > > > > This consists of at least the start of support for deoptimization in > HSAIL kernels. Although the list of files changed may look long, many > of the files have only a few lines changed. Special thanks to Gilles > Duboscq and Doug Simon who provided some of the infrastructure that this > webrev uses. > > > > -- Tom Deneau > > > > > > Below I have described > > > > * an overview of the codepaths the data structures > > * java and hotspot source changes > > > > > > Deoptimization Data Structures and Overview > > =========================================== > > > > At kernel dispatch time, we allocate space for any workitems should > want to deopt. To reduce the space requirements, space is only reserved > for the maximum number of possible concurrent workitems that could be > running on that hsa device. > > > > A deopting workitem sets a "deopt happened" flag, and future workitems > that see "deopt happened" as true will just set a flag saying they never > ran and exit early. Currently the never_ran array is one per workitem. > We are looking at ways to make this smaller but HSA devices have a lot > of freedom in how they schedule workitems (current hardware and the > simulator are quite different). > > > > Workitems that deopt atomically bump an index saying where they should > store their deopt data. The deopt data consists of > > * workitemid > > * deopt actionAndReason > > * the first HSAILFrame > > > > An HSAILFrame consists of > > * the deoptId or "pc" offset where the deopt occurred > > * number of s registers > > * number of d registers > > * a bitmap indicating which d registers are oops > > * space for saving the d and s registers > > > > Currently we always set num_s_registers to 32 and num_d_registers to > > 16 but in the hsail code of the kernel we only save the union of the > actual registers that are live at any of the infopoints. > > > > On return from the GPU, we check if there were any deopts. If not, we > just return back to java. If there was at least one deopt then > > > > a) for the workitems that finished normally, there is nothing to do > > > > b) if there are any deopted workitems, we want to run each deopting > > workitem thru the interpreter going first thru the special host > > trampoline code infrastructure that Gilles created. The > > trampoline host code takes the deoptId and a pointer to the > > saved hsail frame. We currently do this sequentially although > > other policies are possible. > > > > c) for each never ran workitem, we can just run it from the > > beginning of the kernel "method", just making sure we pass the > > arguments and the appropriate workitem id for each one. Again, > > we currently do this sequentially although other policies are > > possible. > > > > Because running either type b or c above can cause GCs, and because > some of our saved d registers are pointers into the java heap, we take > care in case any of these saved pointers are affected by GC. The > current strategy of using an Object array supplied by the java side will > be replaced later with an oops_do type of strategy. > > > > > > > > Description of source changes in this webrev. > > ============================================= > > graal source changes > > ==================== > > > > Assembler, HSAILAssembler > > minor changes for new instructions needed for saving deopt > information > > > > GraalKernelTester.java > > force simulator to run single threaded. > > > > KernelTester.java > > minor changes to handle exceptions which escape the kernel method > > > > HSAILLIRGenerator.java > > support switches with keys of type long > > > > > > HSAILHotSpotBackend.java > > > > * compileKernel uses some new optimisticOpts which help generate > > deopts when needed. Also, we dump the infopoints if Log:CodeGen > > is on > > > > * HSAILNonNullParametersPhase stamps the appropriate parameters as > > nonNull > > > > * installKernel uses the new trampoline infrastructure added by > > Gilles do produce the host trampoline deopt method and install > > it. > > > > * emitCode adds a little bit of code to the prologue and a lot of > > code to the epilogue. See description at the bottom for the data > > structures used by the never-ran path and the deopt path. > > > > HSAILHotSpotLIRGenerator.java > > > > * code added by Gilles to build the host graph for the host > > trampoline deopt method. I suppose some of this would be common > > to any gpu trampoline deopt and should be moved to some > > hsail-independent location. > > > > * code to handle the creation of a DeoptimizeOp for emitting HSAIL > > code for a deoptimization > > > > HSAILHotSpotLoweringProvider.java > > > > * refactored to support different strategies for different nodes. > > UnwindNode strategy is to get replaced by a DeoptimizeNode. > > > > HotSpotVMConfig.java > > > > * define offets to fields in the deopt data structures > > > > VMErrorNode.java > > > > * public access to constructor (used by building of host graph for > > trampoline code) > > > > HSAIL.java > > * some new non-allocatable registers defined (used by deopt paths) > > > > HSAILControlFlow.java > > * code to emit hsail for a deoptimizationNode > > > > ComputeProbabilityClosure.java > > * just using a change that Gilles made in the patch he gave me. > > > > > > mx/projects was affected by the move of ExternalCompilationResult to > com.oracle.graal.gpu. In addition, several files had one line import > changes from the move of ExternalCompilationResult. > > > > > > hotspot source changes > > ====================== > > > > gpu_hsail.cpp, hpp > > > > * the execute_kernel routine pushes an extra parameter where deopt > info can be saved > > > > * while pushing kernel args, keeps track if any are null and if so > > sets some new gpu_exception fields in thread structure which gets > > used when thread returns to java mode > > > > * on return from kernel checks if any deopt occurred. If so, > > > > * runs any deopting workitems thru the trampoline deopt code > > which ends up running the kernel method thru the interpreter > > for that workitem. > > > > * runs any never-ran workitems using simple javaCall. > > > > gpu_hsail_Frame.hpp > > * new structure that defines the layout of a physical HSAIL frame > > > > hsailArgumentsBase.*, hsailKernelArguments.hpp > hsailJavaCallArguments.hpp > > * refactored to share code between kernel argument setup and > > javaCall argument setup > > > > javaClasses.cpp > > > > * contains logic to check the new gpu_exception fields in thread > > structure and if detected, set as top frame on return > > > > graalCompiler.cpp, hpp > > * logic added by Gilles for external_deopt_i2c > > > > javaCalls.cpp, hpp > > * logic added by Gilles for external_deopt_i2c > > > > sharedRuntime.cpp > > * maybe Gilles can explain why the assert was removed in the patch > > he gave me (it asserts if I put it back in) > > > > thread.cpp, hpp > > * handle new gpu_exception fields > > > > vmStructs.cpp > > vmStructs_hsail.hpp > > * handle new hsail deopt structs > > > > > > > > > From doug.simon at oracle.com Tue Mar 25 17:45:22 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Tue, 25 Mar 2014 17:45:22 +0000 Subject: hg: graal/graal: 5 new changesets Message-ID: <201403251745.s2PHjTl5027450@aojmv0008> Changeset: 8db730993642 Author: Doug Simon Date: 2014-03-25 13:55 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8db730993642 check that data patches are of the expected type ! src/share/vm/graal/graalCodeInstaller.cpp Changeset: 209cf6959421 Author: Doug Simon Date: 2014-03-25 13:56 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/209cf6959421 added support for installing raw data with code + graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/RawDataValue.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ValueUtil.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java Changeset: 0cb5c4d276d4 Author: Doug Simon Date: 2014-03-25 13:57 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0cb5c4d276d4 use raw data support to fix incorrect use of String.intern() for embedding strings in code ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CStringNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VMErrorNode.java ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: 56621a6eed29 Author: Doug Simon Date: 2014-03-25 14:23 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/56621a6eed29 taught LIRVerifier about RawDataValue ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRVerifier.java Changeset: b10e42998d01 Author: Bernhard Urban Date: 2014-03-25 16:38 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b10e42998d01 nmethod: fix -XX:+PrintNMethodStatistics ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp From tom.deneau at amd.com Tue Mar 25 18:01:54 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 25 Mar 2014 18:01:54 +0000 Subject: webrev-hsail-deopt-v2 In-Reply-To: References: <733ABFAA-23DD-4652-8DDC-7E9154704CFC@oracle.com> Message-ID: I ended up creating (or re-creating) an HSAILCompilationResultBuilder whose only purpose is to save the lirGen. It works, but let me know if that meets the style. -- Tom > -----Original Message----- > From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of > Deneau, Tom > Sent: Tuesday, March 25, 2014 12:10 PM > To: Doug Simon; Gilles Duboscq > Cc: graal-dev at openjdk.java.net > Subject: RE: webrev-hsail-deopt-v2 > > Doug, Gilles -- > > Regarding the > private LIRGenerator lirGen; > in HSAILHotSpotBackend.java. > > I agree with your statement that lirGen should be per-compilation, not > per backend. > I added it only because it was needed by the code Gilles added at the > end of emitCode > > compilationResult.setHostGraph(((HSAILHotSpotLIRGenerator) > lirGen).prepareHostGraph()); > > I see that lirGen is passed in to newCompilationResultBuilder and used > in that method but was not saved anywhere. > > I thought perhaps it could be saved in CompilationResultBuilder itself, > but that led to the dreaded loops in the project graphs (if I made > com.oracle.graal.compiler project a dependency of com.oracle.graal.lir). > > So what is the best way to solve this problem? > > -- Tom > > > > -----Original Message----- > > From: Doug Simon [mailto:doug.simon at oracle.com] > > Sent: Monday, March 24, 2014 6:13 AM > > To: Deneau, Tom > > Cc: graal-dev at openjdk.java.net > > Subject: Re: webrev-hsail-deopt-v2 > > > > Tom, > > > > Thanks for fixing the issues in the first patch. Apart from some > > seemingly excessive memory usage (which can hopefully be address > > later), the logic in this patch looks mostly correct to me. However, > > Gilles needs to also provide feedback before we can integrate this > > patch as he is more familiar with some of the details. > > > > Per-file comments below. > > > > graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai > > l/ > > HSAILHotSpotBackend.java: > > > > These cannot be fields in HSAILHotSpotBackend as they are per- > > compilation values, not per-backend values: > > > > + private HSAILAssembler asm; > > + private LIRGenerator lirGen; > > > > There's no real value in having HSAILNonNullParametersPhase extend > > NonNullParametersPhase since the former overrides all the logic in the > > latter. > > > > graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai > > l/ > > HSAILHotSpotLIRGenerator.java: > > > > Please create named constants for 40 and 8 that explains what they > are: > > > > 204 if (regNumber < 40) { > > 205 long offset = config.hsailFrameSaveAreaOffset + 4 * > > (regNumber - 8); > > > > src/gpu/hsail/vm/gpu_hsail.hpp: > > > > It would be nice to see the CU acronym explained somewhere. > > > > I know that you are thinking of supporting multiple frames in the > > future but I would not include code partially supporting that now > > otherwise it just adds confusion. For example, the first frame is > > contained in a HSAILKernelDeoptimization object, but > > HSAILFrame::_nextFrame is a pointer to a HSAILFrame. Who > allocates/deallocates the next frame(s)? > > > > 46 HSAILFrame _first_frame; > > > > What's the point of HSAILComputeUnitSaveState? In future will it do > > more than simply wrap a HSAILKernelDeoptimization? > > > > 55 class HSAILComputeUnitSaveState { > > 56 friend class VMStructs; > > 57 public: > > 58 HSAILKernelDeoptimization _deopt_info; > > 59 }; > > > > Why not make the definition extra clear by making the preprocessor do > > the math (i.e. "#define CU_SAVE_STATES_SIZE (8 * 36 * 64)") > > > > 61 // 8 cus * 36 waves per cu * wavesize 64 > > 62 #define CU_SAVE_STATES_SIZE 18432 > > > > Let's use a longer name for clarity (e.g., > > _sizeof_compute_unit_save_state). This should also be reflect in > > HotSpotVMConfig. > > > > 69 jint _sizeof_cuss; > > > > src/gpu/hsail/vm/gpu_hsail.cpp: > > > > I was going to suggest stack allocating the HSAILDeoptimizationInfo > > until I realized it's 20Mb! Is that a conservative approach we can > > improve upon somehow (e.g., a lazily created thread local)? In any > > case, shouldn't the actual allocation be within the "if > (useDeoptInfo)" guard? > > > > 149 HSAILDeoptimizationInfo* e = new (ResourceObj::C_HEAP, > mtInternal) > > HSAILDeoptimizationInfo(); > > 150 if (useDeoptInfo) { > > > > -Doug > > > > On Mar 20, 2014, at 9:57 PM, Deneau, Tom wrote: > > > > > Doug, Gilles -- > > > > > > I believe I have gotten rid of the warnings from the original hsail- > > deopt webrev. > > > I also fixed a few casts that Eric Caspole noticed were preventing > > > the > > fastdebug build from building > > > (but did not affect product and debug builds). Please take a look > > at > > > > > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt > > > - > > v2 > > > > > > I've included here the explanatory text from the first submission > > > > > > This consists of at least the start of support for deoptimization in > > HSAIL kernels. Although the list of files changed may look long, many > > of the files have only a few lines changed. Special thanks to Gilles > > Duboscq and Doug Simon who provided some of the infrastructure that > > this webrev uses. > > > > > > -- Tom Deneau > > > > > > > > > Below I have described > > > > > > * an overview of the codepaths the data structures > > > * java and hotspot source changes > > > > > > > > > Deoptimization Data Structures and Overview > > > =========================================== > > > > > > At kernel dispatch time, we allocate space for any workitems should > > want to deopt. To reduce the space requirements, space is only > > reserved for the maximum number of possible concurrent workitems that > > could be running on that hsa device. > > > > > > A deopting workitem sets a "deopt happened" flag, and future > > > workitems > > that see "deopt happened" as true will just set a flag saying they > > never ran and exit early. Currently the never_ran array is one per > workitem. > > We are looking at ways to make this smaller but HSA devices have a lot > > of freedom in how they schedule workitems (current hardware and the > > simulator are quite different). > > > > > > Workitems that deopt atomically bump an index saying where they > > > should > > store their deopt data. The deopt data consists of > > > * workitemid > > > * deopt actionAndReason > > > * the first HSAILFrame > > > > > > An HSAILFrame consists of > > > * the deoptId or "pc" offset where the deopt occurred > > > * number of s registers > > > * number of d registers > > > * a bitmap indicating which d registers are oops > > > * space for saving the d and s registers > > > > > > Currently we always set num_s_registers to 32 and num_d_registers to > > > 16 but in the hsail code of the kernel we only save the union of the > > actual registers that are live at any of the infopoints. > > > > > > On return from the GPU, we check if there were any deopts. If not, > > > we > > just return back to java. If there was at least one deopt then > > > > > > a) for the workitems that finished normally, there is nothing to > > > do > > > > > > b) if there are any deopted workitems, we want to run each > deopting > > > workitem thru the interpreter going first thru the special host > > > trampoline code infrastructure that Gilles created. The > > > trampoline host code takes the deoptId and a pointer to the > > > saved hsail frame. We currently do this sequentially although > > > other policies are possible. > > > > > > c) for each never ran workitem, we can just run it from the > > > beginning of the kernel "method", just making sure we pass the > > > arguments and the appropriate workitem id for each one. Again, > > > we currently do this sequentially although other policies are > > > possible. > > > > > > Because running either type b or c above can cause GCs, and because > > some of our saved d registers are pointers into the java heap, we take > > care in case any of these saved pointers are affected by GC. The > > current strategy of using an Object array supplied by the java side > > will be replaced later with an oops_do type of strategy. > > > > > > > > > > > > Description of source changes in this webrev. > > > ============================================= > > > graal source changes > > > ==================== > > > > > > Assembler, HSAILAssembler > > > minor changes for new instructions needed for saving deopt > > information > > > > > > GraalKernelTester.java > > > force simulator to run single threaded. > > > > > > KernelTester.java > > > minor changes to handle exceptions which escape the kernel method > > > > > > HSAILLIRGenerator.java > > > support switches with keys of type long > > > > > > > > > HSAILHotSpotBackend.java > > > > > > * compileKernel uses some new optimisticOpts which help generate > > > deopts when needed. Also, we dump the infopoints if Log:CodeGen > > > is on > > > > > > * HSAILNonNullParametersPhase stamps the appropriate parameters as > > > nonNull > > > > > > * installKernel uses the new trampoline infrastructure added by > > > Gilles do produce the host trampoline deopt method and install > > > it. > > > > > > * emitCode adds a little bit of code to the prologue and a lot of > > > code to the epilogue. See description at the bottom for the > data > > > structures used by the never-ran path and the deopt path. > > > > > > HSAILHotSpotLIRGenerator.java > > > > > > * code added by Gilles to build the host graph for the host > > > trampoline deopt method. I suppose some of this would be common > > > to any gpu trampoline deopt and should be moved to some > > > hsail-independent location. > > > > > > * code to handle the creation of a DeoptimizeOp for emitting HSAIL > > > code for a deoptimization > > > > > > HSAILHotSpotLoweringProvider.java > > > > > > * refactored to support different strategies for different nodes. > > > UnwindNode strategy is to get replaced by a DeoptimizeNode. > > > > > > HotSpotVMConfig.java > > > > > > * define offets to fields in the deopt data structures > > > > > > VMErrorNode.java > > > > > > * public access to constructor (used by building of host graph for > > > trampoline code) > > > > > > HSAIL.java > > > * some new non-allocatable registers defined (used by deopt paths) > > > > > > HSAILControlFlow.java > > > * code to emit hsail for a deoptimizationNode > > > > > > ComputeProbabilityClosure.java > > > * just using a change that Gilles made in the patch he gave me. > > > > > > > > > mx/projects was affected by the move of ExternalCompilationResult to > > com.oracle.graal.gpu. In addition, several files had one line import > > changes from the move of ExternalCompilationResult. > > > > > > > > > hotspot source changes > > > ====================== > > > > > > gpu_hsail.cpp, hpp > > > > > > * the execute_kernel routine pushes an extra parameter where deopt > > info can be saved > > > > > > * while pushing kernel args, keeps track if any are null and if so > > > sets some new gpu_exception fields in thread structure which > gets > > > used when thread returns to java mode > > > > > > * on return from kernel checks if any deopt occurred. If so, > > > > > > * runs any deopting workitems thru the trampoline deopt code > > > which ends up running the kernel method thru the interpreter > > > for that workitem. > > > > > > * runs any never-ran workitems using simple javaCall. > > > > > > gpu_hsail_Frame.hpp > > > * new structure that defines the layout of a physical HSAIL frame > > > > > > hsailArgumentsBase.*, hsailKernelArguments.hpp > > hsailJavaCallArguments.hpp > > > * refactored to share code between kernel argument setup and > > > javaCall argument setup > > > > > > javaClasses.cpp > > > > > > * contains logic to check the new gpu_exception fields in thread > > > structure and if detected, set as top frame on return > > > > > > graalCompiler.cpp, hpp > > > * logic added by Gilles for external_deopt_i2c > > > > > > javaCalls.cpp, hpp > > > * logic added by Gilles for external_deopt_i2c > > > > > > sharedRuntime.cpp > > > * maybe Gilles can explain why the assert was removed in the patch > > > he gave me (it asserts if I put it back in) > > > > > > thread.cpp, hpp > > > * handle new gpu_exception fields > > > > > > vmStructs.cpp > > > vmStructs_hsail.hpp > > > * handle new hsail deopt structs > > > > > > > > > > > > > > > > From doug.simon at oracle.com Tue Mar 25 19:14:01 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 25 Mar 2014 20:14:01 +0100 Subject: webrev-hsail-deopt-v2 In-Reply-To: References: <733ABFAA-23DD-4652-8DDC-7E9154704CFC@oracle.com> Message-ID: Sounds like a reasonable workaround to me. On Mar 25, 2014, at 7:01 PM, Deneau, Tom wrote: > I ended up creating (or re-creating) an HSAILCompilationResultBuilder whose only purpose is to save the lirGen. > It works, but let me know if that meets the style. > > -- Tom > >> -----Original Message----- >> From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of >> Deneau, Tom >> Sent: Tuesday, March 25, 2014 12:10 PM >> To: Doug Simon; Gilles Duboscq >> Cc: graal-dev at openjdk.java.net >> Subject: RE: webrev-hsail-deopt-v2 >> >> Doug, Gilles -- >> >> Regarding the >> private LIRGenerator lirGen; >> in HSAILHotSpotBackend.java. >> >> I agree with your statement that lirGen should be per-compilation, not >> per backend. >> I added it only because it was needed by the code Gilles added at the >> end of emitCode >> >> compilationResult.setHostGraph(((HSAILHotSpotLIRGenerator) >> lirGen).prepareHostGraph()); >> >> I see that lirGen is passed in to newCompilationResultBuilder and used >> in that method but was not saved anywhere. >> >> I thought perhaps it could be saved in CompilationResultBuilder itself, >> but that led to the dreaded loops in the project graphs (if I made >> com.oracle.graal.compiler project a dependency of com.oracle.graal.lir). >> >> So what is the best way to solve this problem? >> >> -- Tom >> >> >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Monday, March 24, 2014 6:13 AM >>> To: Deneau, Tom >>> Cc: graal-dev at openjdk.java.net >>> Subject: Re: webrev-hsail-deopt-v2 >>> >>> Tom, >>> >>> Thanks for fixing the issues in the first patch. Apart from some >>> seemingly excessive memory usage (which can hopefully be address >>> later), the logic in this patch looks mostly correct to me. However, >>> Gilles needs to also provide feedback before we can integrate this >>> patch as he is more familiar with some of the details. >>> >>> Per-file comments below. >>> >>> graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai >>> l/ >>> HSAILHotSpotBackend.java: >>> >>> These cannot be fields in HSAILHotSpotBackend as they are per- >>> compilation values, not per-backend values: >>> >>> + private HSAILAssembler asm; >>> + private LIRGenerator lirGen; >>> >>> There's no real value in having HSAILNonNullParametersPhase extend >>> NonNullParametersPhase since the former overrides all the logic in the >>> latter. >>> >>> graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai >>> l/ >>> HSAILHotSpotLIRGenerator.java: >>> >>> Please create named constants for 40 and 8 that explains what they >> are: >>> >>> 204 if (regNumber < 40) { >>> 205 long offset = config.hsailFrameSaveAreaOffset + 4 * >>> (regNumber - 8); >>> >>> src/gpu/hsail/vm/gpu_hsail.hpp: >>> >>> It would be nice to see the CU acronym explained somewhere. >>> >>> I know that you are thinking of supporting multiple frames in the >>> future but I would not include code partially supporting that now >>> otherwise it just adds confusion. For example, the first frame is >>> contained in a HSAILKernelDeoptimization object, but >>> HSAILFrame::_nextFrame is a pointer to a HSAILFrame. Who >> allocates/deallocates the next frame(s)? >>> >>> 46 HSAILFrame _first_frame; >>> >>> What's the point of HSAILComputeUnitSaveState? In future will it do >>> more than simply wrap a HSAILKernelDeoptimization? >>> >>> 55 class HSAILComputeUnitSaveState { >>> 56 friend class VMStructs; >>> 57 public: >>> 58 HSAILKernelDeoptimization _deopt_info; >>> 59 }; >>> >>> Why not make the definition extra clear by making the preprocessor do >>> the math (i.e. "#define CU_SAVE_STATES_SIZE (8 * 36 * 64)") >>> >>> 61 // 8 cus * 36 waves per cu * wavesize 64 >>> 62 #define CU_SAVE_STATES_SIZE 18432 >>> >>> Let's use a longer name for clarity (e.g., >>> _sizeof_compute_unit_save_state). This should also be reflect in >>> HotSpotVMConfig. >>> >>> 69 jint _sizeof_cuss; >>> >>> src/gpu/hsail/vm/gpu_hsail.cpp: >>> >>> I was going to suggest stack allocating the HSAILDeoptimizationInfo >>> until I realized it's 20Mb! Is that a conservative approach we can >>> improve upon somehow (e.g., a lazily created thread local)? In any >>> case, shouldn't the actual allocation be within the "if >> (useDeoptInfo)" guard? >>> >>> 149 HSAILDeoptimizationInfo* e = new (ResourceObj::C_HEAP, >> mtInternal) >>> HSAILDeoptimizationInfo(); >>> 150 if (useDeoptInfo) { >>> >>> -Doug >>> >>> On Mar 20, 2014, at 9:57 PM, Deneau, Tom wrote: >>> >>>> Doug, Gilles -- >>>> >>>> I believe I have gotten rid of the warnings from the original hsail- >>> deopt webrev. >>>> I also fixed a few casts that Eric Caspole noticed were preventing >>>> the >>> fastdebug build from building >>>> (but did not affect product and debug builds). Please take a look >>> at >>>> >>>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt >>>> - >>> v2 >>>> >>>> I've included here the explanatory text from the first submission >>>> >>>> This consists of at least the start of support for deoptimization in >>> HSAIL kernels. Although the list of files changed may look long, many >>> of the files have only a few lines changed. Special thanks to Gilles >>> Duboscq and Doug Simon who provided some of the infrastructure that >>> this webrev uses. >>>> >>>> -- Tom Deneau >>>> >>>> >>>> Below I have described >>>> >>>> * an overview of the codepaths the data structures >>>> * java and hotspot source changes >>>> >>>> >>>> Deoptimization Data Structures and Overview >>>> =========================================== >>>> >>>> At kernel dispatch time, we allocate space for any workitems should >>> want to deopt. To reduce the space requirements, space is only >>> reserved for the maximum number of possible concurrent workitems that >>> could be running on that hsa device. >>>> >>>> A deopting workitem sets a "deopt happened" flag, and future >>>> workitems >>> that see "deopt happened" as true will just set a flag saying they >>> never ran and exit early. Currently the never_ran array is one per >> workitem. >>> We are looking at ways to make this smaller but HSA devices have a lot >>> of freedom in how they schedule workitems (current hardware and the >>> simulator are quite different). >>>> >>>> Workitems that deopt atomically bump an index saying where they >>>> should >>> store their deopt data. The deopt data consists of >>>> * workitemid >>>> * deopt actionAndReason >>>> * the first HSAILFrame >>>> >>>> An HSAILFrame consists of >>>> * the deoptId or "pc" offset where the deopt occurred >>>> * number of s registers >>>> * number of d registers >>>> * a bitmap indicating which d registers are oops >>>> * space for saving the d and s registers >>>> >>>> Currently we always set num_s_registers to 32 and num_d_registers to >>>> 16 but in the hsail code of the kernel we only save the union of the >>> actual registers that are live at any of the infopoints. >>>> >>>> On return from the GPU, we check if there were any deopts. If not, >>>> we >>> just return back to java. If there was at least one deopt then >>>> >>>> a) for the workitems that finished normally, there is nothing to >>>> do >>>> >>>> b) if there are any deopted workitems, we want to run each >> deopting >>>> workitem thru the interpreter going first thru the special host >>>> trampoline code infrastructure that Gilles created. The >>>> trampoline host code takes the deoptId and a pointer to the >>>> saved hsail frame. We currently do this sequentially although >>>> other policies are possible. >>>> >>>> c) for each never ran workitem, we can just run it from the >>>> beginning of the kernel "method", just making sure we pass the >>>> arguments and the appropriate workitem id for each one. Again, >>>> we currently do this sequentially although other policies are >>>> possible. >>>> >>>> Because running either type b or c above can cause GCs, and because >>> some of our saved d registers are pointers into the java heap, we take >>> care in case any of these saved pointers are affected by GC. The >>> current strategy of using an Object array supplied by the java side >>> will be replaced later with an oops_do type of strategy. >>>> >>>> >>>> >>>> Description of source changes in this webrev. >>>> ============================================= >>>> graal source changes >>>> ==================== >>>> >>>> Assembler, HSAILAssembler >>>> minor changes for new instructions needed for saving deopt >>> information >>>> >>>> GraalKernelTester.java >>>> force simulator to run single threaded. >>>> >>>> KernelTester.java >>>> minor changes to handle exceptions which escape the kernel method >>>> >>>> HSAILLIRGenerator.java >>>> support switches with keys of type long >>>> >>>> >>>> HSAILHotSpotBackend.java >>>> >>>> * compileKernel uses some new optimisticOpts which help generate >>>> deopts when needed. Also, we dump the infopoints if Log:CodeGen >>>> is on >>>> >>>> * HSAILNonNullParametersPhase stamps the appropriate parameters as >>>> nonNull >>>> >>>> * installKernel uses the new trampoline infrastructure added by >>>> Gilles do produce the host trampoline deopt method and install >>>> it. >>>> >>>> * emitCode adds a little bit of code to the prologue and a lot of >>>> code to the epilogue. See description at the bottom for the >> data >>>> structures used by the never-ran path and the deopt path. >>>> >>>> HSAILHotSpotLIRGenerator.java >>>> >>>> * code added by Gilles to build the host graph for the host >>>> trampoline deopt method. I suppose some of this would be common >>>> to any gpu trampoline deopt and should be moved to some >>>> hsail-independent location. >>>> >>>> * code to handle the creation of a DeoptimizeOp for emitting HSAIL >>>> code for a deoptimization >>>> >>>> HSAILHotSpotLoweringProvider.java >>>> >>>> * refactored to support different strategies for different nodes. >>>> UnwindNode strategy is to get replaced by a DeoptimizeNode. >>>> >>>> HotSpotVMConfig.java >>>> >>>> * define offets to fields in the deopt data structures >>>> >>>> VMErrorNode.java >>>> >>>> * public access to constructor (used by building of host graph for >>>> trampoline code) >>>> >>>> HSAIL.java >>>> * some new non-allocatable registers defined (used by deopt paths) >>>> >>>> HSAILControlFlow.java >>>> * code to emit hsail for a deoptimizationNode >>>> >>>> ComputeProbabilityClosure.java >>>> * just using a change that Gilles made in the patch he gave me. >>>> >>>> >>>> mx/projects was affected by the move of ExternalCompilationResult to >>> com.oracle.graal.gpu. In addition, several files had one line import >>> changes from the move of ExternalCompilationResult. >>>> >>>> >>>> hotspot source changes >>>> ====================== >>>> >>>> gpu_hsail.cpp, hpp >>>> >>>> * the execute_kernel routine pushes an extra parameter where deopt >>> info can be saved >>>> >>>> * while pushing kernel args, keeps track if any are null and if so >>>> sets some new gpu_exception fields in thread structure which >> gets >>>> used when thread returns to java mode >>>> >>>> * on return from kernel checks if any deopt occurred. If so, >>>> >>>> * runs any deopting workitems thru the trampoline deopt code >>>> which ends up running the kernel method thru the interpreter >>>> for that workitem. >>>> >>>> * runs any never-ran workitems using simple javaCall. >>>> >>>> gpu_hsail_Frame.hpp >>>> * new structure that defines the layout of a physical HSAIL frame >>>> >>>> hsailArgumentsBase.*, hsailKernelArguments.hpp >>> hsailJavaCallArguments.hpp >>>> * refactored to share code between kernel argument setup and >>>> javaCall argument setup >>>> >>>> javaClasses.cpp >>>> >>>> * contains logic to check the new gpu_exception fields in thread >>>> structure and if detected, set as top frame on return >>>> >>>> graalCompiler.cpp, hpp >>>> * logic added by Gilles for external_deopt_i2c >>>> >>>> javaCalls.cpp, hpp >>>> * logic added by Gilles for external_deopt_i2c >>>> >>>> sharedRuntime.cpp >>>> * maybe Gilles can explain why the assert was removed in the patch >>>> he gave me (it asserts if I put it back in) >>>> >>>> thread.cpp, hpp >>>> * handle new gpu_exception fields >>>> >>>> vmStructs.cpp >>>> vmStructs_hsail.hpp >>>> * handle new hsail deopt structs >>>> >>>> >>>> >>>> >>> >> >> > > From tom.deneau at amd.com Tue Mar 25 20:17:04 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 25 Mar 2014 20:17:04 +0000 Subject: webrev-hsail-deopt-v2 In-Reply-To: References: <733ABFAA-23DD-4652-8DDC-7E9154704CFC@oracle.com> Message-ID: Doug -- Do you want the next webrev merged with the tip of trunk or is it OK to leave it as is branching off trunk from last week? -- Tom > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, March 25, 2014 2:14 PM > To: Deneau, Tom > Cc: Gilles Duboscq; graal-dev at openjdk.java.net > Subject: Re: webrev-hsail-deopt-v2 > > Sounds like a reasonable workaround to me. > > On Mar 25, 2014, at 7:01 PM, Deneau, Tom wrote: > > > I ended up creating (or re-creating) an HSAILCompilationResultBuilder > whose only purpose is to save the lirGen. > > It works, but let me know if that meets the style. > > > > -- Tom > > > >> -----Original Message----- > >> From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf > Of > >> Deneau, Tom > >> Sent: Tuesday, March 25, 2014 12:10 PM > >> To: Doug Simon; Gilles Duboscq > >> Cc: graal-dev at openjdk.java.net > >> Subject: RE: webrev-hsail-deopt-v2 > >> > >> Doug, Gilles -- > >> > >> Regarding the > >> private LIRGenerator lirGen; > >> in HSAILHotSpotBackend.java. > >> > >> I agree with your statement that lirGen should be per-compilation, > not > >> per backend. > >> I added it only because it was needed by the code Gilles added at the > >> end of emitCode > >> > >> compilationResult.setHostGraph(((HSAILHotSpotLIRGenerator) > >> lirGen).prepareHostGraph()); > >> > >> I see that lirGen is passed in to newCompilationResultBuilder and > used > >> in that method but was not saved anywhere. > >> > >> I thought perhaps it could be saved in CompilationResultBuilder > itself, > >> but that led to the dreaded loops in the project graphs (if I made > >> com.oracle.graal.compiler project a dependency of > com.oracle.graal.lir). > >> > >> So what is the best way to solve this problem? > >> > >> -- Tom > >> > >> > >>> -----Original Message----- > >>> From: Doug Simon [mailto:doug.simon at oracle.com] > >>> Sent: Monday, March 24, 2014 6:13 AM > >>> To: Deneau, Tom > >>> Cc: graal-dev at openjdk.java.net > >>> Subject: Re: webrev-hsail-deopt-v2 > >>> > >>> Tom, > >>> > >>> Thanks for fixing the issues in the first patch. Apart from some > >>> seemingly excessive memory usage (which can hopefully be address > >>> later), the logic in this patch looks mostly correct to me. However, > >>> Gilles needs to also provide feedback before we can integrate this > >>> patch as he is more familiar with some of the details. > >>> > >>> Per-file comments below. > >>> > >>> > graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai > >>> l/ > >>> HSAILHotSpotBackend.java: > >>> > >>> These cannot be fields in HSAILHotSpotBackend as they are per- > >>> compilation values, not per-backend values: > >>> > >>> + private HSAILAssembler asm; > >>> + private LIRGenerator lirGen; > >>> > >>> There's no real value in having HSAILNonNullParametersPhase extend > >>> NonNullParametersPhase since the former overrides all the logic in > the > >>> latter. > >>> > >>> > graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai > >>> l/ > >>> HSAILHotSpotLIRGenerator.java: > >>> > >>> Please create named constants for 40 and 8 that explains what they > >> are: > >>> > >>> 204 if (regNumber < 40) { > >>> 205 long offset = config.hsailFrameSaveAreaOffset + 4 * > >>> (regNumber - 8); > >>> > >>> src/gpu/hsail/vm/gpu_hsail.hpp: > >>> > >>> It would be nice to see the CU acronym explained somewhere. > >>> > >>> I know that you are thinking of supporting multiple frames in the > >>> future but I would not include code partially supporting that now > >>> otherwise it just adds confusion. For example, the first frame is > >>> contained in a HSAILKernelDeoptimization object, but > >>> HSAILFrame::_nextFrame is a pointer to a HSAILFrame. Who > >> allocates/deallocates the next frame(s)? > >>> > >>> 46 HSAILFrame _first_frame; > >>> > >>> What's the point of HSAILComputeUnitSaveState? In future will it do > >>> more than simply wrap a HSAILKernelDeoptimization? > >>> > >>> 55 class HSAILComputeUnitSaveState { > >>> 56 friend class VMStructs; > >>> 57 public: > >>> 58 HSAILKernelDeoptimization _deopt_info; > >>> 59 }; > >>> > >>> Why not make the definition extra clear by making the preprocessor > do > >>> the math (i.e. "#define CU_SAVE_STATES_SIZE (8 * 36 * 64)") > >>> > >>> 61 // 8 cus * 36 waves per cu * wavesize 64 > >>> 62 #define CU_SAVE_STATES_SIZE 18432 > >>> > >>> Let's use a longer name for clarity (e.g., > >>> _sizeof_compute_unit_save_state). This should also be reflect in > >>> HotSpotVMConfig. > >>> > >>> 69 jint _sizeof_cuss; > >>> > >>> src/gpu/hsail/vm/gpu_hsail.cpp: > >>> > >>> I was going to suggest stack allocating the HSAILDeoptimizationInfo > >>> until I realized it's 20Mb! Is that a conservative approach we can > >>> improve upon somehow (e.g., a lazily created thread local)? In any > >>> case, shouldn't the actual allocation be within the "if > >> (useDeoptInfo)" guard? > >>> > >>> 149 HSAILDeoptimizationInfo* e = new (ResourceObj::C_HEAP, > >> mtInternal) > >>> HSAILDeoptimizationInfo(); > >>> 150 if (useDeoptInfo) { > >>> > >>> -Doug > >>> > >>> On Mar 20, 2014, at 9:57 PM, Deneau, Tom wrote: > >>> > >>>> Doug, Gilles -- > >>>> > >>>> I believe I have gotten rid of the warnings from the original > hsail- > >>> deopt webrev. > >>>> I also fixed a few casts that Eric Caspole noticed were preventing > >>>> the > >>> fastdebug build from building > >>>> (but did not affect product and debug builds). Please take a > look > >>> at > >>>> > >>>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail- > deopt > >>>> - > >>> v2 > >>>> > >>>> I've included here the explanatory text from the first submission > >>>> > >>>> This consists of at least the start of support for deoptimization > in > >>> HSAIL kernels. Although the list of files changed may look long, > many > >>> of the files have only a few lines changed. Special thanks to > Gilles > >>> Duboscq and Doug Simon who provided some of the infrastructure that > >>> this webrev uses. > >>>> > >>>> -- Tom Deneau > >>>> > >>>> > >>>> Below I have described > >>>> > >>>> * an overview of the codepaths the data structures > >>>> * java and hotspot source changes > >>>> > >>>> > >>>> Deoptimization Data Structures and Overview > >>>> =========================================== > >>>> > >>>> At kernel dispatch time, we allocate space for any workitems should > >>> want to deopt. To reduce the space requirements, space is only > >>> reserved for the maximum number of possible concurrent workitems > that > >>> could be running on that hsa device. > >>>> > >>>> A deopting workitem sets a "deopt happened" flag, and future > >>>> workitems > >>> that see "deopt happened" as true will just set a flag saying they > >>> never ran and exit early. Currently the never_ran array is one per > >> workitem. > >>> We are looking at ways to make this smaller but HSA devices have a > lot > >>> of freedom in how they schedule workitems (current hardware and the > >>> simulator are quite different). > >>>> > >>>> Workitems that deopt atomically bump an index saying where they > >>>> should > >>> store their deopt data. The deopt data consists of > >>>> * workitemid > >>>> * deopt actionAndReason > >>>> * the first HSAILFrame > >>>> > >>>> An HSAILFrame consists of > >>>> * the deoptId or "pc" offset where the deopt occurred > >>>> * number of s registers > >>>> * number of d registers > >>>> * a bitmap indicating which d registers are oops > >>>> * space for saving the d and s registers > >>>> > >>>> Currently we always set num_s_registers to 32 and num_d_registers > to > >>>> 16 but in the hsail code of the kernel we only save the union of > the > >>> actual registers that are live at any of the infopoints. > >>>> > >>>> On return from the GPU, we check if there were any deopts. If not, > >>>> we > >>> just return back to java. If there was at least one deopt then > >>>> > >>>> a) for the workitems that finished normally, there is nothing to > >>>> do > >>>> > >>>> b) if there are any deopted workitems, we want to run each > >> deopting > >>>> workitem thru the interpreter going first thru the special host > >>>> trampoline code infrastructure that Gilles created. The > >>>> trampoline host code takes the deoptId and a pointer to the > >>>> saved hsail frame. We currently do this sequentially although > >>>> other policies are possible. > >>>> > >>>> c) for each never ran workitem, we can just run it from the > >>>> beginning of the kernel "method", just making sure we pass the > >>>> arguments and the appropriate workitem id for each one. Again, > >>>> we currently do this sequentially although other policies are > >>>> possible. > >>>> > >>>> Because running either type b or c above can cause GCs, and because > >>> some of our saved d registers are pointers into the java heap, we > take > >>> care in case any of these saved pointers are affected by GC. The > >>> current strategy of using an Object array supplied by the java side > >>> will be replaced later with an oops_do type of strategy. > >>>> > >>>> > >>>> > >>>> Description of source changes in this webrev. > >>>> ============================================= > >>>> graal source changes > >>>> ==================== > >>>> > >>>> Assembler, HSAILAssembler > >>>> minor changes for new instructions needed for saving deopt > >>> information > >>>> > >>>> GraalKernelTester.java > >>>> force simulator to run single threaded. > >>>> > >>>> KernelTester.java > >>>> minor changes to handle exceptions which escape the kernel method > >>>> > >>>> HSAILLIRGenerator.java > >>>> support switches with keys of type long > >>>> > >>>> > >>>> HSAILHotSpotBackend.java > >>>> > >>>> * compileKernel uses some new optimisticOpts which help generate > >>>> deopts when needed. Also, we dump the infopoints if Log:CodeGen > >>>> is on > >>>> > >>>> * HSAILNonNullParametersPhase stamps the appropriate parameters as > >>>> nonNull > >>>> > >>>> * installKernel uses the new trampoline infrastructure added by > >>>> Gilles do produce the host trampoline deopt method and install > >>>> it. > >>>> > >>>> * emitCode adds a little bit of code to the prologue and a lot of > >>>> code to the epilogue. See description at the bottom for the > >> data > >>>> structures used by the never-ran path and the deopt path. > >>>> > >>>> HSAILHotSpotLIRGenerator.java > >>>> > >>>> * code added by Gilles to build the host graph for the host > >>>> trampoline deopt method. I suppose some of this would be common > >>>> to any gpu trampoline deopt and should be moved to some > >>>> hsail-independent location. > >>>> > >>>> * code to handle the creation of a DeoptimizeOp for emitting HSAIL > >>>> code for a deoptimization > >>>> > >>>> HSAILHotSpotLoweringProvider.java > >>>> > >>>> * refactored to support different strategies for different nodes. > >>>> UnwindNode strategy is to get replaced by a DeoptimizeNode. > >>>> > >>>> HotSpotVMConfig.java > >>>> > >>>> * define offets to fields in the deopt data structures > >>>> > >>>> VMErrorNode.java > >>>> > >>>> * public access to constructor (used by building of host graph for > >>>> trampoline code) > >>>> > >>>> HSAIL.java > >>>> * some new non-allocatable registers defined (used by deopt paths) > >>>> > >>>> HSAILControlFlow.java > >>>> * code to emit hsail for a deoptimizationNode > >>>> > >>>> ComputeProbabilityClosure.java > >>>> * just using a change that Gilles made in the patch he gave me. > >>>> > >>>> > >>>> mx/projects was affected by the move of ExternalCompilationResult > to > >>> com.oracle.graal.gpu. In addition, several files had one line > import > >>> changes from the move of ExternalCompilationResult. > >>>> > >>>> > >>>> hotspot source changes > >>>> ====================== > >>>> > >>>> gpu_hsail.cpp, hpp > >>>> > >>>> * the execute_kernel routine pushes an extra parameter where deopt > >>> info can be saved > >>>> > >>>> * while pushing kernel args, keeps track if any are null and if so > >>>> sets some new gpu_exception fields in thread structure which > >> gets > >>>> used when thread returns to java mode > >>>> > >>>> * on return from kernel checks if any deopt occurred. If so, > >>>> > >>>> * runs any deopting workitems thru the trampoline deopt code > >>>> which ends up running the kernel method thru the interpreter > >>>> for that workitem. > >>>> > >>>> * runs any never-ran workitems using simple javaCall. > >>>> > >>>> gpu_hsail_Frame.hpp > >>>> * new structure that defines the layout of a physical HSAIL frame > >>>> > >>>> hsailArgumentsBase.*, hsailKernelArguments.hpp > >>> hsailJavaCallArguments.hpp > >>>> * refactored to share code between kernel argument setup and > >>>> javaCall argument setup > >>>> > >>>> javaClasses.cpp > >>>> > >>>> * contains logic to check the new gpu_exception fields in thread > >>>> structure and if detected, set as top frame on return > >>>> > >>>> graalCompiler.cpp, hpp > >>>> * logic added by Gilles for external_deopt_i2c > >>>> > >>>> javaCalls.cpp, hpp > >>>> * logic added by Gilles for external_deopt_i2c > >>>> > >>>> sharedRuntime.cpp > >>>> * maybe Gilles can explain why the assert was removed in the patch > >>>> he gave me (it asserts if I put it back in) > >>>> > >>>> thread.cpp, hpp > >>>> * handle new gpu_exception fields > >>>> > >>>> vmStructs.cpp > >>>> vmStructs_hsail.hpp > >>>> * handle new hsail deopt structs > >>>> > >>>> > >>>> > >>>> > >>> > >> > >> > > > > > From doug.simon at oracle.com Tue Mar 25 21:09:34 2014 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 25 Mar 2014 22:09:34 +0100 Subject: webrev-hsail-deopt-v2 In-Reply-To: References: <733ABFAA-23DD-4652-8DDC-7E9154704CFC@oracle.com> Message-ID: Before anything else, I want to give Gilles a chance to comment on the latest webrev. -Doug On Mar 25, 2014, at 9:17 PM, Deneau, Tom wrote: > Doug -- > > Do you want the next webrev merged with the tip of trunk or is it OK to leave it as is branching off trunk from last week? > > -- Tom > > >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Tuesday, March 25, 2014 2:14 PM >> To: Deneau, Tom >> Cc: Gilles Duboscq; graal-dev at openjdk.java.net >> Subject: Re: webrev-hsail-deopt-v2 >> >> Sounds like a reasonable workaround to me. >> >> On Mar 25, 2014, at 7:01 PM, Deneau, Tom wrote: >> >>> I ended up creating (or re-creating) an HSAILCompilationResultBuilder >> whose only purpose is to save the lirGen. >>> It works, but let me know if that meets the style. >>> >>> -- Tom >>> >>>> -----Original Message----- >>>> From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf >> Of >>>> Deneau, Tom >>>> Sent: Tuesday, March 25, 2014 12:10 PM >>>> To: Doug Simon; Gilles Duboscq >>>> Cc: graal-dev at openjdk.java.net >>>> Subject: RE: webrev-hsail-deopt-v2 >>>> >>>> Doug, Gilles -- >>>> >>>> Regarding the >>>> private LIRGenerator lirGen; >>>> in HSAILHotSpotBackend.java. >>>> >>>> I agree with your statement that lirGen should be per-compilation, >> not >>>> per backend. >>>> I added it only because it was needed by the code Gilles added at the >>>> end of emitCode >>>> >>>> compilationResult.setHostGraph(((HSAILHotSpotLIRGenerator) >>>> lirGen).prepareHostGraph()); >>>> >>>> I see that lirGen is passed in to newCompilationResultBuilder and >> used >>>> in that method but was not saved anywhere. >>>> >>>> I thought perhaps it could be saved in CompilationResultBuilder >> itself, >>>> but that led to the dreaded loops in the project graphs (if I made >>>> com.oracle.graal.compiler project a dependency of >> com.oracle.graal.lir). >>>> >>>> So what is the best way to solve this problem? >>>> >>>> -- Tom >>>> >>>> >>>>> -----Original Message----- >>>>> From: Doug Simon [mailto:doug.simon at oracle.com] >>>>> Sent: Monday, March 24, 2014 6:13 AM >>>>> To: Deneau, Tom >>>>> Cc: graal-dev at openjdk.java.net >>>>> Subject: Re: webrev-hsail-deopt-v2 >>>>> >>>>> Tom, >>>>> >>>>> Thanks for fixing the issues in the first patch. Apart from some >>>>> seemingly excessive memory usage (which can hopefully be address >>>>> later), the logic in this patch looks mostly correct to me. However, >>>>> Gilles needs to also provide feedback before we can integrate this >>>>> patch as he is more familiar with some of the details. >>>>> >>>>> Per-file comments below. >>>>> >>>>> >> graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai >>>>> l/ >>>>> HSAILHotSpotBackend.java: >>>>> >>>>> These cannot be fields in HSAILHotSpotBackend as they are per- >>>>> compilation values, not per-backend values: >>>>> >>>>> + private HSAILAssembler asm; >>>>> + private LIRGenerator lirGen; >>>>> >>>>> There's no real value in having HSAILNonNullParametersPhase extend >>>>> NonNullParametersPhase since the former overrides all the logic in >> the >>>>> latter. >>>>> >>>>> >> graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai >>>>> l/ >>>>> HSAILHotSpotLIRGenerator.java: >>>>> >>>>> Please create named constants for 40 and 8 that explains what they >>>> are: >>>>> >>>>> 204 if (regNumber < 40) { >>>>> 205 long offset = config.hsailFrameSaveAreaOffset + 4 * >>>>> (regNumber - 8); >>>>> >>>>> src/gpu/hsail/vm/gpu_hsail.hpp: >>>>> >>>>> It would be nice to see the CU acronym explained somewhere. >>>>> >>>>> I know that you are thinking of supporting multiple frames in the >>>>> future but I would not include code partially supporting that now >>>>> otherwise it just adds confusion. For example, the first frame is >>>>> contained in a HSAILKernelDeoptimization object, but >>>>> HSAILFrame::_nextFrame is a pointer to a HSAILFrame. Who >>>> allocates/deallocates the next frame(s)? >>>>> >>>>> 46 HSAILFrame _first_frame; >>>>> >>>>> What's the point of HSAILComputeUnitSaveState? In future will it do >>>>> more than simply wrap a HSAILKernelDeoptimization? >>>>> >>>>> 55 class HSAILComputeUnitSaveState { >>>>> 56 friend class VMStructs; >>>>> 57 public: >>>>> 58 HSAILKernelDeoptimization _deopt_info; >>>>> 59 }; >>>>> >>>>> Why not make the definition extra clear by making the preprocessor >> do >>>>> the math (i.e. "#define CU_SAVE_STATES_SIZE (8 * 36 * 64)") >>>>> >>>>> 61 // 8 cus * 36 waves per cu * wavesize 64 >>>>> 62 #define CU_SAVE_STATES_SIZE 18432 >>>>> >>>>> Let's use a longer name for clarity (e.g., >>>>> _sizeof_compute_unit_save_state). This should also be reflect in >>>>> HotSpotVMConfig. >>>>> >>>>> 69 jint _sizeof_cuss; >>>>> >>>>> src/gpu/hsail/vm/gpu_hsail.cpp: >>>>> >>>>> I was going to suggest stack allocating the HSAILDeoptimizationInfo >>>>> until I realized it's 20Mb! Is that a conservative approach we can >>>>> improve upon somehow (e.g., a lazily created thread local)? In any >>>>> case, shouldn't the actual allocation be within the "if >>>> (useDeoptInfo)" guard? >>>>> >>>>> 149 HSAILDeoptimizationInfo* e = new (ResourceObj::C_HEAP, >>>> mtInternal) >>>>> HSAILDeoptimizationInfo(); >>>>> 150 if (useDeoptInfo) { >>>>> >>>>> -Doug >>>>> >>>>> On Mar 20, 2014, at 9:57 PM, Deneau, Tom wrote: >>>>> >>>>>> Doug, Gilles -- >>>>>> >>>>>> I believe I have gotten rid of the warnings from the original >> hsail- >>>>> deopt webrev. >>>>>> I also fixed a few casts that Eric Caspole noticed were preventing >>>>>> the >>>>> fastdebug build from building >>>>>> (but did not affect product and debug builds). Please take a >> look >>>>> at >>>>>> >>>>>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail- >> deopt >>>>>> - >>>>> v2 >>>>>> >>>>>> I've included here the explanatory text from the first submission >>>>>> >>>>>> This consists of at least the start of support for deoptimization >> in >>>>> HSAIL kernels. Although the list of files changed may look long, >> many >>>>> of the files have only a few lines changed. Special thanks to >> Gilles >>>>> Duboscq and Doug Simon who provided some of the infrastructure that >>>>> this webrev uses. >>>>>> >>>>>> -- Tom Deneau >>>>>> >>>>>> >>>>>> Below I have described >>>>>> >>>>>> * an overview of the codepaths the data structures >>>>>> * java and hotspot source changes >>>>>> >>>>>> >>>>>> Deoptimization Data Structures and Overview >>>>>> =========================================== >>>>>> >>>>>> At kernel dispatch time, we allocate space for any workitems should >>>>> want to deopt. To reduce the space requirements, space is only >>>>> reserved for the maximum number of possible concurrent workitems >> that >>>>> could be running on that hsa device. >>>>>> >>>>>> A deopting workitem sets a "deopt happened" flag, and future >>>>>> workitems >>>>> that see "deopt happened" as true will just set a flag saying they >>>>> never ran and exit early. Currently the never_ran array is one per >>>> workitem. >>>>> We are looking at ways to make this smaller but HSA devices have a >> lot >>>>> of freedom in how they schedule workitems (current hardware and the >>>>> simulator are quite different). >>>>>> >>>>>> Workitems that deopt atomically bump an index saying where they >>>>>> should >>>>> store their deopt data. The deopt data consists of >>>>>> * workitemid >>>>>> * deopt actionAndReason >>>>>> * the first HSAILFrame >>>>>> >>>>>> An HSAILFrame consists of >>>>>> * the deoptId or "pc" offset where the deopt occurred >>>>>> * number of s registers >>>>>> * number of d registers >>>>>> * a bitmap indicating which d registers are oops >>>>>> * space for saving the d and s registers >>>>>> >>>>>> Currently we always set num_s_registers to 32 and num_d_registers >> to >>>>>> 16 but in the hsail code of the kernel we only save the union of >> the >>>>> actual registers that are live at any of the infopoints. >>>>>> >>>>>> On return from the GPU, we check if there were any deopts. If not, >>>>>> we >>>>> just return back to java. If there was at least one deopt then >>>>>> >>>>>> a) for the workitems that finished normally, there is nothing to >>>>>> do >>>>>> >>>>>> b) if there are any deopted workitems, we want to run each >>>> deopting >>>>>> workitem thru the interpreter going first thru the special host >>>>>> trampoline code infrastructure that Gilles created. The >>>>>> trampoline host code takes the deoptId and a pointer to the >>>>>> saved hsail frame. We currently do this sequentially although >>>>>> other policies are possible. >>>>>> >>>>>> c) for each never ran workitem, we can just run it from the >>>>>> beginning of the kernel "method", just making sure we pass the >>>>>> arguments and the appropriate workitem id for each one. Again, >>>>>> we currently do this sequentially although other policies are >>>>>> possible. >>>>>> >>>>>> Because running either type b or c above can cause GCs, and because >>>>> some of our saved d registers are pointers into the java heap, we >> take >>>>> care in case any of these saved pointers are affected by GC. The >>>>> current strategy of using an Object array supplied by the java side >>>>> will be replaced later with an oops_do type of strategy. >>>>>> >>>>>> >>>>>> >>>>>> Description of source changes in this webrev. >>>>>> ============================================= >>>>>> graal source changes >>>>>> ==================== >>>>>> >>>>>> Assembler, HSAILAssembler >>>>>> minor changes for new instructions needed for saving deopt >>>>> information >>>>>> >>>>>> GraalKernelTester.java >>>>>> force simulator to run single threaded. >>>>>> >>>>>> KernelTester.java >>>>>> minor changes to handle exceptions which escape the kernel method >>>>>> >>>>>> HSAILLIRGenerator.java >>>>>> support switches with keys of type long >>>>>> >>>>>> >>>>>> HSAILHotSpotBackend.java >>>>>> >>>>>> * compileKernel uses some new optimisticOpts which help generate >>>>>> deopts when needed. Also, we dump the infopoints if Log:CodeGen >>>>>> is on >>>>>> >>>>>> * HSAILNonNullParametersPhase stamps the appropriate parameters as >>>>>> nonNull >>>>>> >>>>>> * installKernel uses the new trampoline infrastructure added by >>>>>> Gilles do produce the host trampoline deopt method and install >>>>>> it. >>>>>> >>>>>> * emitCode adds a little bit of code to the prologue and a lot of >>>>>> code to the epilogue. See description at the bottom for the >>>> data >>>>>> structures used by the never-ran path and the deopt path. >>>>>> >>>>>> HSAILHotSpotLIRGenerator.java >>>>>> >>>>>> * code added by Gilles to build the host graph for the host >>>>>> trampoline deopt method. I suppose some of this would be common >>>>>> to any gpu trampoline deopt and should be moved to some >>>>>> hsail-independent location. >>>>>> >>>>>> * code to handle the creation of a DeoptimizeOp for emitting HSAIL >>>>>> code for a deoptimization >>>>>> >>>>>> HSAILHotSpotLoweringProvider.java >>>>>> >>>>>> * refactored to support different strategies for different nodes. >>>>>> UnwindNode strategy is to get replaced by a DeoptimizeNode. >>>>>> >>>>>> HotSpotVMConfig.java >>>>>> >>>>>> * define offets to fields in the deopt data structures >>>>>> >>>>>> VMErrorNode.java >>>>>> >>>>>> * public access to constructor (used by building of host graph for >>>>>> trampoline code) >>>>>> >>>>>> HSAIL.java >>>>>> * some new non-allocatable registers defined (used by deopt paths) >>>>>> >>>>>> HSAILControlFlow.java >>>>>> * code to emit hsail for a deoptimizationNode >>>>>> >>>>>> ComputeProbabilityClosure.java >>>>>> * just using a change that Gilles made in the patch he gave me. >>>>>> >>>>>> >>>>>> mx/projects was affected by the move of ExternalCompilationResult >> to >>>>> com.oracle.graal.gpu. In addition, several files had one line >> import >>>>> changes from the move of ExternalCompilationResult. >>>>>> >>>>>> >>>>>> hotspot source changes >>>>>> ====================== >>>>>> >>>>>> gpu_hsail.cpp, hpp >>>>>> >>>>>> * the execute_kernel routine pushes an extra parameter where deopt >>>>> info can be saved >>>>>> >>>>>> * while pushing kernel args, keeps track if any are null and if so >>>>>> sets some new gpu_exception fields in thread structure which >>>> gets >>>>>> used when thread returns to java mode >>>>>> >>>>>> * on return from kernel checks if any deopt occurred. If so, >>>>>> >>>>>> * runs any deopting workitems thru the trampoline deopt code >>>>>> which ends up running the kernel method thru the interpreter >>>>>> for that workitem. >>>>>> >>>>>> * runs any never-ran workitems using simple javaCall. >>>>>> >>>>>> gpu_hsail_Frame.hpp >>>>>> * new structure that defines the layout of a physical HSAIL frame >>>>>> >>>>>> hsailArgumentsBase.*, hsailKernelArguments.hpp >>>>> hsailJavaCallArguments.hpp >>>>>> * refactored to share code between kernel argument setup and >>>>>> javaCall argument setup >>>>>> >>>>>> javaClasses.cpp >>>>>> >>>>>> * contains logic to check the new gpu_exception fields in thread >>>>>> structure and if detected, set as top frame on return >>>>>> >>>>>> graalCompiler.cpp, hpp >>>>>> * logic added by Gilles for external_deopt_i2c >>>>>> >>>>>> javaCalls.cpp, hpp >>>>>> * logic added by Gilles for external_deopt_i2c >>>>>> >>>>>> sharedRuntime.cpp >>>>>> * maybe Gilles can explain why the assert was removed in the patch >>>>>> he gave me (it asserts if I put it back in) >>>>>> >>>>>> thread.cpp, hpp >>>>>> * handle new gpu_exception fields >>>>>> >>>>>> vmStructs.cpp >>>>>> vmStructs_hsail.hpp >>>>>> * handle new hsail deopt structs >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> > > From tom.deneau at amd.com Tue Mar 25 22:52:21 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 25 Mar 2014 22:52:21 +0000 Subject: webrev-hsail-deopt-v2 In-Reply-To: <733ABFAA-23DD-4652-8DDC-7E9154704CFC@oracle.com> References: <733ABFAA-23DD-4652-8DDC-7E9154704CFC@oracle.com> Message-ID: Doug -- I think I have addressed most of your comments. See http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt-v3 One comment I did not address head-on is the memory usage issue. We do plan to address this but I would prefer we do that after this first version gets into the trunk. Related to memory usage for the deoptimization info, I have since learned that our max of 8 * 36 * 64 save slots should really be 8 * 40 * 64 for current hardware. I made this change but we realize a more robust solution would be to get this maximum from the okra layer and plan to do that in the near future. On the memory-saving side, I noticed that the size of the area to save registers for each deoptimizing workitem was about 4 times bigger than it needed to be. So with the above two modifications, the save area is now "only" about 5.6Mb -- Tom > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Monday, March 24, 2014 6:13 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: webrev-hsail-deopt-v2 > > Tom, > > Thanks for fixing the issues in the first patch. Apart from some > seemingly excessive memory usage (which can hopefully be address later), > the logic in this patch looks mostly correct to me. However, Gilles > needs to also provide feedback before we can integrate this patch as he > is more familiar with some of the details. > > Per-file comments below. > > graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/ > HSAILHotSpotBackend.java: > > These cannot be fields in HSAILHotSpotBackend as they are per- > compilation values, not per-backend values: > > + private HSAILAssembler asm; > + private LIRGenerator lirGen; > > There's no real value in having HSAILNonNullParametersPhase extend > NonNullParametersPhase since the former overrides all the logic in the > latter. > > graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/ > HSAILHotSpotLIRGenerator.java: > > Please create named constants for 40 and 8 that explains what they are: > > 204 if (regNumber < 40) { > 205 long offset = config.hsailFrameSaveAreaOffset + 4 * > (regNumber - 8); > > src/gpu/hsail/vm/gpu_hsail.hpp: > > It would be nice to see the CU acronym explained somewhere. > > I know that you are thinking of supporting multiple frames in the future > but I would not include code partially supporting that now otherwise it > just adds confusion. For example, the first frame is contained in a > HSAILKernelDeoptimization object, but HSAILFrame::_nextFrame is a > pointer to a HSAILFrame. Who allocates/deallocates the next frame(s)? > > 46 HSAILFrame _first_frame; > > What's the point of HSAILComputeUnitSaveState? In future will it do more > than simply wrap a HSAILKernelDeoptimization? > > 55 class HSAILComputeUnitSaveState { > 56 friend class VMStructs; > 57 public: > 58 HSAILKernelDeoptimization _deopt_info; > 59 }; > > Why not make the definition extra clear by making the preprocessor do > the math (i.e. "#define CU_SAVE_STATES_SIZE (8 * 36 * 64)") > > 61 // 8 cus * 36 waves per cu * wavesize 64 > 62 #define CU_SAVE_STATES_SIZE 18432 > > Let's use a longer name for clarity (e.g., > _sizeof_compute_unit_save_state). This should also be reflect in > HotSpotVMConfig. > > 69 jint _sizeof_cuss; > > src/gpu/hsail/vm/gpu_hsail.cpp: > > I was going to suggest stack allocating the HSAILDeoptimizationInfo > until I realized it's 20Mb! Is that a conservative approach we can > improve upon somehow (e.g., a lazily created thread local)? In any case, > shouldn't the actual allocation be within the "if (useDeoptInfo)" guard? > > 149 HSAILDeoptimizationInfo* e = new (ResourceObj::C_HEAP, mtInternal) > HSAILDeoptimizationInfo(); > 150 if (useDeoptInfo) { > > -Doug > > On Mar 20, 2014, at 9:57 PM, Deneau, Tom wrote: > > > Doug, Gilles -- > > > > I believe I have gotten rid of the warnings from the original hsail- > deopt webrev. > > I also fixed a few casts that Eric Caspole noticed were preventing the > fastdebug build from building > > (but did not affect product and debug builds). Please take a look > at > > > > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt- > v2 > > > > I've included here the explanatory text from the first submission > > > > This consists of at least the start of support for deoptimization in > HSAIL kernels. Although the list of files changed may look long, many > of the files have only a few lines changed. Special thanks to Gilles > Duboscq and Doug Simon who provided some of the infrastructure that this > webrev uses. > > > > -- Tom Deneau > > > > > > Below I have described > > > > * an overview of the codepaths the data structures > > * java and hotspot source changes > > > > > > Deoptimization Data Structures and Overview > > =========================================== > > > > At kernel dispatch time, we allocate space for any workitems should > want to deopt. To reduce the space requirements, space is only reserved > for the maximum number of possible concurrent workitems that could be > running on that hsa device. > > > > A deopting workitem sets a "deopt happened" flag, and future workitems > that see "deopt happened" as true will just set a flag saying they never > ran and exit early. Currently the never_ran array is one per workitem. > We are looking at ways to make this smaller but HSA devices have a lot > of freedom in how they schedule workitems (current hardware and the > simulator are quite different). > > > > Workitems that deopt atomically bump an index saying where they should > store their deopt data. The deopt data consists of > > * workitemid > > * deopt actionAndReason > > * the first HSAILFrame > > > > An HSAILFrame consists of > > * the deoptId or "pc" offset where the deopt occurred > > * number of s registers > > * number of d registers > > * a bitmap indicating which d registers are oops > > * space for saving the d and s registers > > > > Currently we always set num_s_registers to 32 and num_d_registers to > > 16 but in the hsail code of the kernel we only save the union of the > actual registers that are live at any of the infopoints. > > > > On return from the GPU, we check if there were any deopts. If not, we > just return back to java. If there was at least one deopt then > > > > a) for the workitems that finished normally, there is nothing to do > > > > b) if there are any deopted workitems, we want to run each deopting > > workitem thru the interpreter going first thru the special host > > trampoline code infrastructure that Gilles created. The > > trampoline host code takes the deoptId and a pointer to the > > saved hsail frame. We currently do this sequentially although > > other policies are possible. > > > > c) for each never ran workitem, we can just run it from the > > beginning of the kernel "method", just making sure we pass the > > arguments and the appropriate workitem id for each one. Again, > > we currently do this sequentially although other policies are > > possible. > > > > Because running either type b or c above can cause GCs, and because > some of our saved d registers are pointers into the java heap, we take > care in case any of these saved pointers are affected by GC. The > current strategy of using an Object array supplied by the java side will > be replaced later with an oops_do type of strategy. > > > > > > > > Description of source changes in this webrev. > > ============================================= > > graal source changes > > ==================== > > > > Assembler, HSAILAssembler > > minor changes for new instructions needed for saving deopt > information > > > > GraalKernelTester.java > > force simulator to run single threaded. > > > > KernelTester.java > > minor changes to handle exceptions which escape the kernel method > > > > HSAILLIRGenerator.java > > support switches with keys of type long > > > > > > HSAILHotSpotBackend.java > > > > * compileKernel uses some new optimisticOpts which help generate > > deopts when needed. Also, we dump the infopoints if Log:CodeGen > > is on > > > > * HSAILNonNullParametersPhase stamps the appropriate parameters as > > nonNull > > > > * installKernel uses the new trampoline infrastructure added by > > Gilles do produce the host trampoline deopt method and install > > it. > > > > * emitCode adds a little bit of code to the prologue and a lot of > > code to the epilogue. See description at the bottom for the data > > structures used by the never-ran path and the deopt path. > > > > HSAILHotSpotLIRGenerator.java > > > > * code added by Gilles to build the host graph for the host > > trampoline deopt method. I suppose some of this would be common > > to any gpu trampoline deopt and should be moved to some > > hsail-independent location. > > > > * code to handle the creation of a DeoptimizeOp for emitting HSAIL > > code for a deoptimization > > > > HSAILHotSpotLoweringProvider.java > > > > * refactored to support different strategies for different nodes. > > UnwindNode strategy is to get replaced by a DeoptimizeNode. > > > > HotSpotVMConfig.java > > > > * define offets to fields in the deopt data structures > > > > VMErrorNode.java > > > > * public access to constructor (used by building of host graph for > > trampoline code) > > > > HSAIL.java > > * some new non-allocatable registers defined (used by deopt paths) > > > > HSAILControlFlow.java > > * code to emit hsail for a deoptimizationNode > > > > ComputeProbabilityClosure.java > > * just using a change that Gilles made in the patch he gave me. > > > > > > mx/projects was affected by the move of ExternalCompilationResult to > com.oracle.graal.gpu. In addition, several files had one line import > changes from the move of ExternalCompilationResult. > > > > > > hotspot source changes > > ====================== > > > > gpu_hsail.cpp, hpp > > > > * the execute_kernel routine pushes an extra parameter where deopt > info can be saved > > > > * while pushing kernel args, keeps track if any are null and if so > > sets some new gpu_exception fields in thread structure which gets > > used when thread returns to java mode > > > > * on return from kernel checks if any deopt occurred. If so, > > > > * runs any deopting workitems thru the trampoline deopt code > > which ends up running the kernel method thru the interpreter > > for that workitem. > > > > * runs any never-ran workitems using simple javaCall. > > > > gpu_hsail_Frame.hpp > > * new structure that defines the layout of a physical HSAIL frame > > > > hsailArgumentsBase.*, hsailKernelArguments.hpp > hsailJavaCallArguments.hpp > > * refactored to share code between kernel argument setup and > > javaCall argument setup > > > > javaClasses.cpp > > > > * contains logic to check the new gpu_exception fields in thread > > structure and if detected, set as top frame on return > > > > graalCompiler.cpp, hpp > > * logic added by Gilles for external_deopt_i2c > > > > javaCalls.cpp, hpp > > * logic added by Gilles for external_deopt_i2c > > > > sharedRuntime.cpp > > * maybe Gilles can explain why the assert was removed in the patch > > he gave me (it asserts if I put it back in) > > > > thread.cpp, hpp > > * handle new gpu_exception fields > > > > vmStructs.cpp > > vmStructs_hsail.hpp > > * handle new hsail deopt structs > > > > > > > > > From doug.simon at oracle.com Wed Mar 26 02:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 26 Mar 2014 02:00:07 +0000 Subject: hg: graal/graal: 20 new changesets Message-ID: <201403260200.s2Q20Y0l014170@aojmv0008> Changeset: 6ae9af961b7c Author: Roland Schatz Date: 2014-03-25 18:53 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6ae9af961b7c Introduce separate interfaces for deoptimizing nodes that deopt to a state before, during or after their execution. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXWrapperBuilder.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1PreWriteBarrier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VMErrorNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractDeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractFixedGuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractStateSplit.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizingFixedWithNextNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizingNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DynamicDeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InfopointNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/Invoke.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/extended/ForeignCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AccessMonitorNode.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/NodeWithState.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/FrameStateAssignmentPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/UseTrappingNullChecksPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/CollapseFrameForSingleSideEffectPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleExpansionLogger.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java Changeset: c5ee41cf9823 Author: Doug Simon Date: 2014-03-25 21:02 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c5ee41cf9823 replaced RawDataValue with LIRGeneratorTool.emitData(); accept only ASCII strings in log and VM error messages - graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/RawDataValue.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ValueUtil.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.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/src/com/oracle/graal/hotspot/nodes/CStringNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VMErrorNode.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.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/LIRVerifier.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LIRGeneratorTool.java Changeset: 5ba874df3b2b Author: Christian Wimmer Date: 2014-03-25 11:07 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5ba874df3b2b Introduce base class ConstantData ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CompilationResult.java Changeset: c4903a8f6ef4 Author: Christian Wimmer Date: 2014-03-25 11:15 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c4903a8f6ef4 Support zero-extend-load for all data sizes ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java Changeset: 8fa7da4a2c43 Author: Christian Wimmer Date: 2014-03-25 11:26 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8fa7da4a2c43 Add verification code ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/CompareNode.java Changeset: 553527010fc4 Author: Christian Wimmer Date: 2014-03-25 11:47 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/553527010fc4 Allow subclasses to provide their own graph builder ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java Changeset: 470e1e6664e2 Author: Christian Wimmer Date: 2014-03-25 11:47 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/470e1e6664e2 Fix format string ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 8c0e5b7d5af9 Author: Christian Wimmer Date: 2014-03-25 11:48 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8c0e5b7d5af9 Do not call @NodeIntrinsic method from within Graal ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MathIntrinsicNode.java Changeset: ed8533832ea4 Author: Christian Wimmer Date: 2014-03-25 11:49 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ed8533832ea4 Use Stamp instead of Kind for method parameter ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: 762c9aceb7d8 Author: Christian Wimmer Date: 2014-03-25 11:50 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/762c9aceb7d8 Add equals/hashCode methods ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: bf51a92a1bdd Author: Christian Wimmer Date: 2014-03-25 11:50 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/bf51a92a1bdd Add new optional method parameter ! mx/mx_graal.py Changeset: 65b005b58825 Author: Christian Wimmer Date: 2014-03-25 11:50 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/65b005b58825 Allow project-specific overrides of Eclipse configuration files ! mxtool/mx.py Changeset: 7544068e1a91 Author: Christian Wimmer Date: 2014-03-25 13:32 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7544068e1a91 Perform de-virtualization of calls only in canonicalizer and not in graph builder ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/BoxingEliminationTest.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MethodCallTargetNode.java Changeset: a836fed0e270 Author: Christian Wimmer Date: 2014-03-25 13:50 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/a836fed0e270 Merge - graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/RawDataValue.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 483d05bf77a7 Author: Bernhard Urban Date: 2014-03-25 22:37 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/483d05bf77a7 changelog: graal-0.2 ! CHANGELOG.md Changeset: 0b6ec715a291 Author: Bernhard Urban Date: 2014-03-25 22:38 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0b6ec715a291 Added tag graal-0.2 for changeset 483d05bf77a7 ! .hgtags Changeset: 7b3ee54233ea Author: Doug Simon Date: 2014-03-25 23:52 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7b3ee54233ea fixed findbugs issue ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java Changeset: 015f84f0b375 Author: Doug Simon Date: 2014-03-25 23:53 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/015f84f0b375 added findbugs to the gate ! mx/mx_graal.py Changeset: 311bf6c7488b Author: twisti Date: 2014-03-25 16:25 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/311bf6c7488b revert some changes to match upstream files ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/runtime.cpp Changeset: b5cdbf6d793a Author: twisti Date: 2014-03-25 16:37 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b5cdbf6d793a print total allocated bytes for compilations ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java From bernhard.urban at jku.at Wed Mar 26 08:55:29 2014 From: bernhard.urban at jku.at (Bernhard Urban) Date: Wed, 26 Mar 2014 09:55:29 +0100 Subject: Graal/Truffle Release 0.2 Message-ID: Hi all, in order to make the life easier for external Truffle implementations, we introduced a release model for Graal and Truffle some weeks ago. The idea is to release a truffle.jar which is in sync with a Graal enabled VM in terms of API. Yesterday we made version 0.2: http://lafo.ssw.uni-linz.ac.at/builds/ JRuby for example is one such external user: They specify the Truffle API as dependency in Maven [1, 2]. In order to get high performance you also need to run it with a Graal enabled JVM [3]. Although those images are primarily intended for Truffle development, one can also use them to run normal Java applications with Graal. However, keep in mind that Graal is still experimental, i.e. don't use it for production mode. Have fun, Bernhard [1] https://github.com/jruby/jruby/blob/master/pom.xml#L30 [2] https://github.com/jruby/jruby/blob/master/core/pom.xml#L204 [3] https://github.com/jruby/jruby/wiki/Truffle#running-with-graal From bernhard.urban at jku.at Wed Mar 26 09:02:18 2014 From: bernhard.urban at jku.at (Bernhard Urban) Date: Wed, 26 Mar 2014 10:02:18 +0100 Subject: Permissions still screwy in Graal OpenJDK builds In-Reply-To: References: Message-ID: Hi Charles, can you try 0.2 from http://lafo.ssw.uni-linz.ac.at/builds/ ? We fixed some stuff around permissions in our build process since 0.1. Thanks, Bernhard On Fri, Feb 7, 2014 at 5:01 PM, Charles Oliver Nutter wrote: > I'm using builds from here: http://lafo.ssw.uni-linz.ac.at/builds/ > > And I'm seeing lots of files and dirs with messed up permissions like this: > > system ~/projects/jruby $ ls -l > /Library/Java/JavaVirtualMachines/graal/Contents/Home/jre/lib/ > total 173824 > -rwxr-xr-x@ 1 504 staff 2666876 Jan 8 07:29 JObjC.jar > drwxr-xr-x@ 2 504 staff 68 Jan 8 07:29 applet > -rwxr-xr-x@ 1 504 staff 2375 Jan 8 07:29 calendars.properties > -rwxr-xr-x@ 1 504 staff 3131343 Jan 8 07:29 charsets.jar > -rwxr-xr-x@ 1 504 staff 72450 Jan 8 07:29 classlist > drwxr-xr-x@ 2 504 staff 238 Jan 8 07:29 cmm > -rwxr-xr-x@ 1 504 staff 5916 Jan 8 07:29 content-types.properties > -rwxr-xr-x@ 1 504 staff 4028 Jan 8 07:29 currency.data > drwxr-xr-x@ 2 504 staff 374 Jan 8 07:29 ext > -rwxr-xr-x@ 1 504 staff 4026 Jan 8 07:29 flavormap.properties > -rwxr-xr-x@ 1 504 staff 3058 Jan 8 07:29 fontconfig.bfc > -rwxr-xr-x@ 1 504 staff 9084 Jan 8 07:29 fontconfig.properties.src > drwx------ 2 504 staff 136 Feb 5 08:50 graal > -rw------- 1 504 staff 7395607 Feb 5 08:50 graal.jar > -rwxr-xr-x@ 1 504 staff 14959 Jan 8 07:29 > hijrah-config-umalqura.properties > -rwxr-xr-x@ 1 504 staff 1192520 Feb 5 08:47 hsdis-amd64.dylib > drwxr-xr-x@ 3 504 staff 102 Jan 8 07:29 images > -rwxr-xr-x@ 1 504 staff 92835 Jan 8 07:29 jce.jar > drwxr-xr-x@ 2 504 staff 102 Jan 8 07:29 jli > -rwxr-xr-x@ 1 504 staff 15128 Jan 8 07:29 jspawnhelper > -rwxr-xr-x@ 1 504 staff 618596 Jan 8 07:29 jsse.jar > -rw------- 1 504 staff 1701 Feb 5 08:50 jvm.cfg > > This makes it impossible to install Graal alongside my other > system-level JVMs without having to monkey with permissions > throughout. I'm not sure how these builds are being created, but > perhaps this can be fixed? > > - Charlie > > From duboscq at ssw.jku.at Wed Mar 26 09:52:41 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Wed, 26 Mar 2014 10:52:41 +0100 Subject: webrev-hsail-deopt-v2 In-Reply-To: References: <733ABFAA-23DD-4652-8DDC-7E9154704CFC@oracle.com> Message-ID: Hello, No need to make a new webrev for that but we can remove the block comments in HSAILHotSpotLIRGenerator.prepareHostGraph before making the commit. The removal of the receiver in JavaCallWrapper is a risk since it doesn't seem to be used in any way but there may be some hidden subtlety... Let's keep an eye open for any problems around this. There are probably a few things that could be cleaned up but theis has waited long enough. I think we should push it as-is. -Gilles On Tue, Mar 25, 2014 at 11:52 PM, Tom Deneau wrote: > Doug -- > > I think I have addressed most of your comments. See > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt-v3 > > One comment I did not address head-on is the memory usage issue. > We do plan to address this but I would prefer we do that after > this first version gets into the trunk. > > Related to memory usage for the deoptimization info, I have since > learned that our max of 8 * 36 * 64 save slots should really be > 8 * 40 * 64 for current hardware. I made this change but we realize > a more robust solution would be to get this maximum from the okra layer > and plan to do that in the near future. > > On the memory-saving side, I noticed that the size of the area to save > registers for each deoptimizing workitem was about 4 times bigger than > it needed to be. So with the above two modifications, the save area is > now "only" about 5.6Mb > > -- Tom > > > > >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Monday, March 24, 2014 6:13 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: webrev-hsail-deopt-v2 >> >> Tom, >> >> Thanks for fixing the issues in the first patch. Apart from some >> seemingly excessive memory usage (which can hopefully be address later), >> the logic in this patch looks mostly correct to me. However, Gilles >> needs to also provide feedback before we can integrate this patch as he >> is more familiar with some of the details. >> >> Per-file comments below. >> >> graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/ >> HSAILHotSpotBackend.java: >> >> These cannot be fields in HSAILHotSpotBackend as they are per- >> compilation values, not per-backend values: >> >> + private HSAILAssembler asm; >> + private LIRGenerator lirGen; >> >> There's no real value in having HSAILNonNullParametersPhase extend >> NonNullParametersPhase since the former overrides all the logic in the >> latter. >> >> graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/ >> HSAILHotSpotLIRGenerator.java: >> >> Please create named constants for 40 and 8 that explains what they are: >> >> 204 if (regNumber < 40) { >> 205 long offset = config.hsailFrameSaveAreaOffset + 4 * >> (regNumber - 8); >> >> src/gpu/hsail/vm/gpu_hsail.hpp: >> >> It would be nice to see the CU acronym explained somewhere. >> >> I know that you are thinking of supporting multiple frames in the future >> but I would not include code partially supporting that now otherwise it >> just adds confusion. For example, the first frame is contained in a >> HSAILKernelDeoptimization object, but HSAILFrame::_nextFrame is a >> pointer to a HSAILFrame. Who allocates/deallocates the next frame(s)? >> >> 46 HSAILFrame _first_frame; >> >> What's the point of HSAILComputeUnitSaveState? In future will it do more >> than simply wrap a HSAILKernelDeoptimization? >> >> 55 class HSAILComputeUnitSaveState { >> 56 friend class VMStructs; >> 57 public: >> 58 HSAILKernelDeoptimization _deopt_info; >> 59 }; >> >> Why not make the definition extra clear by making the preprocessor do >> the math (i.e. "#define CU_SAVE_STATES_SIZE (8 * 36 * 64)") >> >> 61 // 8 cus * 36 waves per cu * wavesize 64 >> 62 #define CU_SAVE_STATES_SIZE 18432 >> >> Let's use a longer name for clarity (e.g., >> _sizeof_compute_unit_save_state). This should also be reflect in >> HotSpotVMConfig. >> >> 69 jint _sizeof_cuss; >> >> src/gpu/hsail/vm/gpu_hsail.cpp: >> >> I was going to suggest stack allocating the HSAILDeoptimizationInfo >> until I realized it's 20Mb! Is that a conservative approach we can >> improve upon somehow (e.g., a lazily created thread local)? In any case, >> shouldn't the actual allocation be within the "if (useDeoptInfo)" guard? >> >> 149 HSAILDeoptimizationInfo* e = new (ResourceObj::C_HEAP, mtInternal) >> HSAILDeoptimizationInfo(); >> 150 if (useDeoptInfo) { >> >> -Doug >> >> On Mar 20, 2014, at 9:57 PM, Deneau, Tom wrote: >> >> > Doug, Gilles -- >> > >> > I believe I have gotten rid of the warnings from the original hsail- >> deopt webrev. >> > I also fixed a few casts that Eric Caspole noticed were preventing the >> fastdebug build from building >> > (but did not affect product and debug builds). Please take a look >> at >> > >> > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-deopt- >> v2 >> > >> > I've included here the explanatory text from the first submission >> > >> > This consists of at least the start of support for deoptimization in >> HSAIL kernels. Although the list of files changed may look long, many >> of the files have only a few lines changed. Special thanks to Gilles >> Duboscq and Doug Simon who provided some of the infrastructure that this >> webrev uses. >> > >> > -- Tom Deneau >> > >> > >> > Below I have described >> > >> > * an overview of the codepaths the data structures >> > * java and hotspot source changes >> > >> > >> > Deoptimization Data Structures and Overview >> > =========================================== >> > >> > At kernel dispatch time, we allocate space for any workitems should >> want to deopt. To reduce the space requirements, space is only reserved >> for the maximum number of possible concurrent workitems that could be >> running on that hsa device. >> > >> > A deopting workitem sets a "deopt happened" flag, and future workitems >> that see "deopt happened" as true will just set a flag saying they never >> ran and exit early. Currently the never_ran array is one per workitem. >> We are looking at ways to make this smaller but HSA devices have a lot >> of freedom in how they schedule workitems (current hardware and the >> simulator are quite different). >> > >> > Workitems that deopt atomically bump an index saying where they should >> store their deopt data. The deopt data consists of >> > * workitemid >> > * deopt actionAndReason >> > * the first HSAILFrame >> > >> > An HSAILFrame consists of >> > * the deoptId or "pc" offset where the deopt occurred >> > * number of s registers >> > * number of d registers >> > * a bitmap indicating which d registers are oops >> > * space for saving the d and s registers >> > >> > Currently we always set num_s_registers to 32 and num_d_registers to >> > 16 but in the hsail code of the kernel we only save the union of the >> actual registers that are live at any of the infopoints. >> > >> > On return from the GPU, we check if there were any deopts. If not, we >> just return back to java. If there was at least one deopt then >> > >> > a) for the workitems that finished normally, there is nothing to do >> > >> > b) if there are any deopted workitems, we want to run each deopting >> > workitem thru the interpreter going first thru the special host >> > trampoline code infrastructure that Gilles created. The >> > trampoline host code takes the deoptId and a pointer to the >> > saved hsail frame. We currently do this sequentially although >> > other policies are possible. >> > >> > c) for each never ran workitem, we can just run it from the >> > beginning of the kernel "method", just making sure we pass the >> > arguments and the appropriate workitem id for each one. Again, >> > we currently do this sequentially although other policies are >> > possible. >> > >> > Because running either type b or c above can cause GCs, and because >> some of our saved d registers are pointers into the java heap, we take >> care in case any of these saved pointers are affected by GC. The >> current strategy of using an Object array supplied by the java side will >> be replaced later with an oops_do type of strategy. >> > >> > >> > >> > Description of source changes in this webrev. >> > ============================================= >> > graal source changes >> > ==================== >> > >> > Assembler, HSAILAssembler >> > minor changes for new instructions needed for saving deopt >> information >> > >> > GraalKernelTester.java >> > force simulator to run single threaded. >> > >> > KernelTester.java >> > minor changes to handle exceptions which escape the kernel method >> > >> > HSAILLIRGenerator.java >> > support switches with keys of type long >> > >> > >> > HSAILHotSpotBackend.java >> > >> > * compileKernel uses some new optimisticOpts which help generate >> > deopts when needed. Also, we dump the infopoints if Log:CodeGen >> > is on >> > >> > * HSAILNonNullParametersPhase stamps the appropriate parameters as >> > nonNull >> > >> > * installKernel uses the new trampoline infrastructure added by >> > Gilles do produce the host trampoline deopt method and install >> > it. >> > >> > * emitCode adds a little bit of code to the prologue and a lot of >> > code to the epilogue. See description at the bottom for the data >> > structures used by the never-ran path and the deopt path. >> > >> > HSAILHotSpotLIRGenerator.java >> > >> > * code added by Gilles to build the host graph for the host >> > trampoline deopt method. I suppose some of this would be common >> > to any gpu trampoline deopt and should be moved to some >> > hsail-independent location. >> > >> > * code to handle the creation of a DeoptimizeOp for emitting HSAIL >> > code for a deoptimization >> > >> > HSAILHotSpotLoweringProvider.java >> > >> > * refactored to support different strategies for different nodes. >> > UnwindNode strategy is to get replaced by a DeoptimizeNode. >> > >> > HotSpotVMConfig.java >> > >> > * define offets to fields in the deopt data structures >> > >> > VMErrorNode.java >> > >> > * public access to constructor (used by building of host graph for >> > trampoline code) >> > >> > HSAIL.java >> > * some new non-allocatable registers defined (used by deopt paths) >> > >> > HSAILControlFlow.java >> > * code to emit hsail for a deoptimizationNode >> > >> > ComputeProbabilityClosure.java >> > * just using a change that Gilles made in the patch he gave me. >> > >> > >> > mx/projects was affected by the move of ExternalCompilationResult to >> com.oracle.graal.gpu. In addition, several files had one line import >> changes from the move of ExternalCompilationResult. >> > >> > >> > hotspot source changes >> > ====================== >> > >> > gpu_hsail.cpp, hpp >> > >> > * the execute_kernel routine pushes an extra parameter where deopt >> info can be saved >> > >> > * while pushing kernel args, keeps track if any are null and if so >> > sets some new gpu_exception fields in thread structure which gets >> > used when thread returns to java mode >> > >> > * on return from kernel checks if any deopt occurred. If so, >> > >> > * runs any deopting workitems thru the trampoline deopt code >> > which ends up running the kernel method thru the interpreter >> > for that workitem. >> > >> > * runs any never-ran workitems using simple javaCall. >> > >> > gpu_hsail_Frame.hpp >> > * new structure that defines the layout of a physical HSAIL frame >> > >> > hsailArgumentsBase.*, hsailKernelArguments.hpp >> hsailJavaCallArguments.hpp >> > * refactored to share code between kernel argument setup and >> > javaCall argument setup >> > >> > javaClasses.cpp >> > >> > * contains logic to check the new gpu_exception fields in thread >> > structure and if detected, set as top frame on return >> > >> > graalCompiler.cpp, hpp >> > * logic added by Gilles for external_deopt_i2c >> > >> > javaCalls.cpp, hpp >> > * logic added by Gilles for external_deopt_i2c >> > >> > sharedRuntime.cpp >> > * maybe Gilles can explain why the assert was removed in the patch >> > he gave me (it asserts if I put it back in) >> > >> > thread.cpp, hpp >> > * handle new gpu_exception fields >> > >> > vmStructs.cpp >> > vmStructs_hsail.hpp >> > * handle new hsail deopt structs >> > >> > >> > >> > >> > > From D.Sturm42 at gmail.com Wed Mar 26 11:58:55 2014 From: D.Sturm42 at gmail.com (D.Sturm) Date: Wed, 26 Mar 2014 12:58:55 +0100 Subject: Use snippets in LIRGenerator Message-ID: Hi, Division under aarch64 does not generate an implicit exception in case of division by 0, therefore I have to generate code along the lines of: if (divisor == 0) throw new ArithmethicException("Division by 0"); result = dividend / divisor; for emitDiv, etc. Now I could implement that all as low-level code in the LIR, but on the other hand we already know how to create new objects and throw exceptions, so I was wondering if there's a way to use Snippets to avoid doing this manually? -- Daniel From andreas.woess at jku.at Wed Mar 26 12:23:31 2014 From: andreas.woess at jku.at (Andreas Woess) Date: Wed, 26 Mar 2014 13:23:31 +0100 Subject: Graal/Truffle Release 0.2 In-Reply-To: References: Message-ID: <5332C6C3.3010904@jku.at> While we're at it, let me also remind you about a Truffle API change in 0.2: If you haven't already migrated, the adoptChild and adoptChildren methods have been deprecated (soon to be removed now). You can use Eclipse's Inline Method feature to remove all usages at once: Select adoptChild in Node, then Refactor - Inline (shortcut: Alt+Shift+I). Calls to adoptChild after node creation, i.e. outside the node constructor need to use the new 'insert' method instead. Note that adoption now happens not until a call target is created. If you have any problems migrating, feel free to contact me off list. - andreas On 26.03.2014 09:55, Bernhard Urban wrote: > Hi all, > > in order to make the life easier for external Truffle implementations, we > introduced a release model for Graal and Truffle some weeks ago. The idea > is to release a truffle.jar which is in sync with a Graal enabled VM in > terms of API. Yesterday we made version 0.2: > http://lafo.ssw.uni-linz.ac.at/builds/ > > JRuby for example is one such external user: They specify the Truffle API > as dependency in Maven [1, 2]. In order to get high performance you also > need to run it with a Graal enabled JVM [3]. > > Although those images are primarily intended for Truffle development, one > can also use them to run normal Java applications with Graal. However, > keep in mind that Graal is still experimental, i.e. don't use it for > production mode. > > Have fun, > Bernhard > > [1] https://github.com/jruby/jruby/blob/master/pom.xml#L30 > [2] https://github.com/jruby/jruby/blob/master/core/pom.xml#L204 > [3] https://github.com/jruby/jruby/wiki/Truffle#running-with-graal > From roland.schatz at oracle.com Wed Mar 26 14:23:57 2014 From: roland.schatz at oracle.com (Roland Schatz) Date: Wed, 26 Mar 2014 15:23:57 +0100 Subject: Use snippets in LIRGenerator In-Reply-To: References: Message-ID: <5332E2FD.8070504@oracle.com> Hi Daniel, You shouldn't create new control flow in the LIR. A better way to do this in the high level graph, then you can still profit from subsequent optimizations on the control flow. We have a similar use case already in the AMD64 backend: The AMD64 floating point convert semantics differs from the Java semantics. What we do there is, we replace the FloatConvertNode with an AMD64FloatConvertNode + some other code from a snippet that fixes up the difference. Then the AMD64FloatConvertNode can be lowered directly to a LIR instruction that results in a single assembler instruction. You can look at AMD64HotSpotLoweringProvider and AMD64ConvertSnippets for how this is done. -Roland On 03/26/2014 12:58 PM, D.Sturm wrote: > Hi, > Division under aarch64 does not generate an implicit exception in case of > division by 0, therefore I have to generate code along the lines of: > > if (divisor == 0) throw new ArithmethicException("Division by 0"); > result = dividend / divisor; > > for emitDiv, etc. Now I could implement that all as low-level code in the > LIR, but on the other hand we already know how to create new objects and > throw exceptions, so I was wondering if there's a way to use Snippets to > avoid doing this manually? > > -- Daniel From christian.wimmer at oracle.com Wed Mar 26 15:08:45 2014 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Wed, 26 Mar 2014 08:08:45 -0700 Subject: Use snippets in LIRGenerator In-Reply-To: References: Message-ID: <5332ED7D.7080400@oracle.com> I already have code that introduces the explicit division-by-zero checks using Snippets. I'll send it to you later in a direct email. -Christian On 3/26/2014 4:58 AM, D.Sturm wrote: > Hi, > Division under aarch64 does not generate an implicit exception in case of > division by 0, therefore I have to generate code along the lines of: > > if (divisor == 0) throw new ArithmethicException("Division by 0"); > result = dividend / divisor; > > for emitDiv, etc. Now I could implement that all as low-level code in the > LIR, but on the other hand we already know how to create new objects and > throw exceptions, so I was wondering if there's a way to use Snippets to > avoid doing this manually? > > -- Daniel > From ingo.korb at tu-dortmund.de Wed Mar 26 15:58:38 2014 From: ingo.korb at tu-dortmund.de (Ingo Korb) Date: Wed, 26 Mar 2014 16:58:38 +0100 Subject: Solaris compilation troubles Message-ID: <6c4321a06b5c0e1d96f89670c0d2f2da.squirrel@webmail.tu-dortmund.de> Hi! I'm trying to compile graal on Solaris 11, but things don't seem to work that well for me. After finally discovering the USE_GCC variable in the makefile snippets (and adding it to mx/env) compilation fails with a missing rule: === cut here === gmake[5]: Entering directory `/home/korb/graaltest/graal/build/solaris/solaris_amd64_compiler2/product' Making ../generated/sa-jdi.jar warning: [options] bootstrap class path not set in conjunction with -source 1.6 Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 1 warning gmake[5]: Leaving directory `/home/korb/graaltest/graal/build/solaris/solaris_amd64_compiler2/product' gmake[4]: Leaving directory `/home/korb/graaltest/graal/build/solaris/solaris_amd64_compiler2/product' gmake[4]: Entering directory `/home/korb/graaltest/graal/build/solaris/solaris_amd64_compiler2/product' gmake[4]: Leaving directory `/home/korb/graaltest/graal/build/solaris/solaris_amd64_compiler2/product' gmake[4]: *** No rule to make target `dtrace_gen_headers'. Stop. === cut here === A bit before that there is a syntax error message in the output: === cut here === Creating dtrace.make ... gmake[4]: Leaving directory `/home/korb/graaltest/graal/build/solaris/solaris_amd64_compiler2/product' gmake[3]: Leaving directory `/home/korb/graaltest/graal/build/solaris' cd solaris_amd64_compiler2/product && gmake -w gmake[3]: Entering directory `/home/korb/graaltest/graal/build/solaris/solaris_amd64_compiler2/product' cd ../generated; cp /home/korb/graaltest/graal/make/solaris/platform_amd64.gcc ../generated/platform.current >expr: syntax error gmake[4]: Entering directory `/home/korb/graaltest/graal/build/solaris/solaris_amd64_compiler2/product' Compiling /home/korb/graaltest/graal/src/share/vm/adlc/adlparse.cpp === cut here === Any advice? gcc on that system is version 4.5.2 installed via pkg (4.5.2-0.175.1.0.0.24.0), jdk version is 1.7.0_51. -ik From tom.rodriguez at oracle.com Wed Mar 26 16:08:50 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 26 Mar 2014 09:08:50 -0700 Subject: Solaris compilation troubles In-Reply-To: <6c4321a06b5c0e1d96f89670c0d2f2da.squirrel@webmail.tu-dortmund.de> References: <6c4321a06b5c0e1d96f89670c0d2f2da.squirrel@webmail.tu-dortmund.de> Message-ID: <393B519F-824D-46A1-8024-65017797695F@oracle.com> The expr message is probably your problem and those are mostly for figuring out compiler versions. Do you have g++ installed? tom On Mar 26, 2014, at 8:58 AM, Ingo Korb wrote: > Hi! > > I'm trying to compile graal on Solaris 11, but things don't seem to work > that well for me. After finally discovering the USE_GCC variable in the > makefile snippets (and adding it to mx/env) compilation fails with a > missing rule: > > === cut here === > gmake[5]: Entering directory > `/home/korb/graaltest/graal/build/solaris/solaris_amd64_compiler2/product' > Making ../generated/sa-jdi.jar > warning: [options] bootstrap class path not set in conjunction with > -source 1.6 > > Note: Some input files use unchecked or unsafe operations. > > Note: Recompile with -Xlint:unchecked for details. > > 1 warning > > gmake[5]: Leaving directory > `/home/korb/graaltest/graal/build/solaris/solaris_amd64_compiler2/product' > gmake[4]: Leaving directory > `/home/korb/graaltest/graal/build/solaris/solaris_amd64_compiler2/product' > gmake[4]: Entering directory > `/home/korb/graaltest/graal/build/solaris/solaris_amd64_compiler2/product' > gmake[4]: Leaving directory > `/home/korb/graaltest/graal/build/solaris/solaris_amd64_compiler2/product' > gmake[4]: *** No rule to make target `dtrace_gen_headers'. Stop. > === cut here === > > A bit before that there is a syntax error message in the output: > > === cut here === > Creating dtrace.make ... > gmake[4]: Leaving directory > `/home/korb/graaltest/graal/build/solaris/solaris_amd64_compiler2/product' > gmake[3]: Leaving directory `/home/korb/graaltest/graal/build/solaris' > cd solaris_amd64_compiler2/product && gmake -w > gmake[3]: Entering directory > `/home/korb/graaltest/graal/build/solaris/solaris_amd64_compiler2/product' > cd ../generated; cp > /home/korb/graaltest/graal/make/solaris/platform_amd64.gcc > ../generated/platform.current >> expr: syntax error > > gmake[4]: Entering directory > `/home/korb/graaltest/graal/build/solaris/solaris_amd64_compiler2/product' > Compiling /home/korb/graaltest/graal/src/share/vm/adlc/adlparse.cpp > === cut here === > > Any advice? > > gcc on that system is version 4.5.2 installed via pkg > (4.5.2-0.175.1.0.0.24.0), jdk version is 1.7.0_51. > > -ik > > From ingo.korb at tu-dortmund.de Wed Mar 26 16:52:42 2014 From: ingo.korb at tu-dortmund.de (Ingo Korb) Date: Wed, 26 Mar 2014 17:52:42 +0100 Subject: Solaris compilation troubles In-Reply-To: <393B519F-824D-46A1-8024-65017797695F@oracle.com> References: <6c4321a06b5c0e1d96f89670c0d2f2da.squirrel@webmail.tu-dortmund.de> <393B519F-824D-46A1-8024-65017797695F@oracle.com> Message-ID: <6218b21d489ccdb4f3e7ecfeb3b85ca9.squirrel@webmail.tu-dortmund.de> > The expr message is probably your problem and those are mostly for > figuring out compiler versions. Do you have g++ installed? Sure: === cut here === korb at ls12pc22:~/graaltest/graal$ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/gcc/4.5/lib/gcc/i386-pc-solaris2.11/4.5.2/lto-wrapper Target: i386-pc-solaris2.11 Configured with: /builds/hudson/workspace/nightly-update/build/i386/components/gcc45/gcc-4.5.2/configure CC=/ws/on11update-tools/SUNWspro/sunstudio12.1/bin/cc CXX=/ws/on11update-tools/SUNWspro/sunstudio12.1/bin/CC --prefix=/usr/gcc/4.5 --mandir=/usr/gcc/4.5/share/man --bindir=/usr/gcc/4.5/bin --libdir=/usr/gcc/4.5/lib --sbindir=/usr/gcc/4.5/sbin --infodir=/usr/gcc/4.5/share/info --libexecdir=/usr/gcc/4.5/lib --enable-languages=c,c++,fortran,objc --enable-shared --with-gmp-include=/usr/include/gmp --with-mpfr-include=/usr/include/mpfr --without-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as --with-as=/usr/gnu/bin/as CFLAGS='-g -O2 ' Thread model: posix gcc version 4.5.2 (GCC) === cut here === The expr appears to be a false lead though, it is caused by a check of $(COMPILER_REV_NUMERIC) in make/solaris/makefiles/adlc.make which is executed even though the selected compiler isn't sparcWorks, so that variable is not defined. -ik From D.Sturm42 at gmail.com Wed Mar 26 17:55:40 2014 From: D.Sturm42 at gmail.com (D.Sturm) Date: Wed, 26 Mar 2014 18:55:40 +0100 Subject: Use snippets in LIRGenerator In-Reply-To: <5332E2FD.8070504@oracle.com> References: <5332E2FD.8070504@oracle.com> Message-ID: > > You shouldn't create new control flow in the LIR. A better way to do this > in the high level graph, then you can still profit from subsequent > optimizations on the control flow. > Something like this was what I was hoping for, great. > I already have code that introduces the explicit division-by-zero checks > using Snippets. I'll send it to you later in a direct email. > You can look at AMD64HotSpotLoweringProvider and AMD64ConvertSnippets for > how this is done. Got the code and am already looking at integrating it. Looks straightforward to adapt to my code. thanks to both of you, -- Daniel From tom.rodriguez at oracle.com Wed Mar 26 18:40:27 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 26 Mar 2014 11:40:27 -0700 Subject: Solaris compilation troubles In-Reply-To: <6218b21d489ccdb4f3e7ecfeb3b85ca9.squirrel@webmail.tu-dortmund.de> References: <6c4321a06b5c0e1d96f89670c0d2f2da.squirrel@webmail.tu-dortmund.de> <393B519F-824D-46A1-8024-65017797695F@oracle.com> <6218b21d489ccdb4f3e7ecfeb3b85ca9.squirrel@webmail.tu-dortmund.de> Message-ID: It looks like the solaris build just isn?t tested with USE_GCC. The problem is probably this bit in dtrace.make: ifdef USE_GCC dtraceCheck: $(QUIETLY) echo "**NOTICE** Dtrace support disabled for gcc builds" else Given how dtrace.make is used it needs to have an empty dtrace_gen_headers rules so it doesn?t barf. The TYPE=CORE part is probably broken too for the same reason but I don?t know if CORE is dead yet or not. If you get it working you might send mail to the hotspot-dev alias in case they want to fix it. tom On Mar 26, 2014, at 9:52 AM, Ingo Korb wrote: >> The expr message is probably your problem and those are mostly for >> figuring out compiler versions. Do you have g++ installed? > > Sure: > > === cut here === > korb at ls12pc22:~/graaltest/graal$ g++ -v > Using built-in specs. > COLLECT_GCC=g++ > COLLECT_LTO_WRAPPER=/usr/gcc/4.5/lib/gcc/i386-pc-solaris2.11/4.5.2/lto-wrapper > Target: i386-pc-solaris2.11 > Configured with: > /builds/hudson/workspace/nightly-update/build/i386/components/gcc45/gcc-4.5.2/configure > CC=/ws/on11update-tools/SUNWspro/sunstudio12.1/bin/cc > CXX=/ws/on11update-tools/SUNWspro/sunstudio12.1/bin/CC > --prefix=/usr/gcc/4.5 --mandir=/usr/gcc/4.5/share/man > --bindir=/usr/gcc/4.5/bin --libdir=/usr/gcc/4.5/lib > --sbindir=/usr/gcc/4.5/sbin --infodir=/usr/gcc/4.5/share/info > --libexecdir=/usr/gcc/4.5/lib --enable-languages=c,c++,fortran,objc > --enable-shared --with-gmp-include=/usr/include/gmp > --with-mpfr-include=/usr/include/mpfr --without-gnu-ld > --with-ld=/usr/bin/ld --with-gnu-as --with-as=/usr/gnu/bin/as CFLAGS='-g > -O2 ' > Thread model: posix > gcc version 4.5.2 (GCC) > === cut here === > > The expr appears to be a false lead though, it is caused by a check of > $(COMPILER_REV_NUMERIC) in make/solaris/makefiles/adlc.make which is > executed even though the selected compiler isn't sparcWorks, so that > variable is not defined. > > -ik > > From tom.deneau at amd.com Wed Mar 26 19:27:19 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 26 Mar 2014 19:27:19 +0000 Subject: checkSnippetKills Message-ID: I have a snippet for NewInstance that works but I wanted to increment a snippet counter on one of the paths thru the snippet. After doing that and using -G:+SnippetCounters, I get the following error: java.lang.AssertionError: snippet graph contains a kill to ANY_LOCATION, but replacee (333|NewInstance) doesn't kill ANY_LOCATION. kills: [ANY_LOCATION, Initialization] at com.oracle.graal.replacements.SnippetTemplate.checkSnippetKills(SnippetTemplate.java:946) How should this be corrected? -- Tom From tom.deneau at amd.com Wed Mar 26 19:36:07 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 26 Mar 2014 19:36:07 +0000 Subject: checkSnippetKills Message-ID: I just tried this with the amd64 backend and got similar results I compiled: MyObj[] escapingObject; public void newObjTest(int gid) { escapingObject[gid] = new MyObj(); } and using -G:+SnippetCounters The log showed Lowering allocateInstance in StructuredGraph:18{HotSpotMethod}: node=159|NewInstance, template=StructuredGraph:39{HotSpotMethod}( [0], long [1], [2], [3], [4], [5], [6]), arguments=Parameters WARNING: 159|NewInstance is not a MemoryCheckpoint, but the snippet graph contains kills ([ANY_LOCATION]). You might want 159|NewInstance to be a MemoryCheckpoint [thread:1] scope: BasicTest2.Compiling.GraalCompiler.FrontEnd.LowTier.Lowering.IncrementalCanonicalizer.LoweringIteration0.InterceptException Exception occurred in scope: BasicTest2.Compiling.GraalCompiler.FrontEnd.LowTier.Lowering.IncrementalCanonicalizer.LoweringIteration0.InterceptException Context obj java.lang.AssertionError: snippet graph contains a kill to ANY_LOCATION, but replacee (159|NewInstance) doesn't kill ANY_LOCATION. kills: [ANY_LOCATION] > -----Original Message----- > From: Deneau, Tom > Sent: Wednesday, March 26, 2014 2:27 PM > To: graal-dev at openjdk.java.net > Subject: checkSnippetKills > > I have a snippet for NewInstance that works but I wanted to increment a > snippet counter on one of the paths thru the snippet. After doing that > and using -G:+SnippetCounters, I get the following error: > > java.lang.AssertionError: snippet graph contains a kill to ANY_LOCATION, > but replacee (333|NewInstance) doesn't kill ANY_LOCATION. kills: > [ANY_LOCATION, Initialization] > at > com.oracle.graal.replacements.SnippetTemplate.checkSnippetKills(SnippetT > emplate.java:946) > > How should this be corrected? > > -- Tom From java at stefan-marr.de Wed Mar 26 19:52:09 2014 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 26 Mar 2014 20:52:09 +0100 Subject: Graal/Truffle Release 0.2 In-Reply-To: References: Message-ID: <51C62C57-6DFF-4E41-8084-0C8E8A1B05F4@stefan-marr.de> Hi: On 26 Mar 2014, at 09:55, Bernhard Urban wrote: > in order to make the life easier for external Truffle implementations, we > introduced a release model for Graal and Truffle some weeks ago. The idea > is to release a truffle.jar which is in sync with a Graal enabled VM in > terms of API. Yesterday we made version 0.2: > http://lafo.ssw.uni-linz.ac.at/builds/ I already reported to Andreas an issue I am seeing with the latest changes for thread safe ASTs. I was suspecting that something on the benchmarking machine is wrong in terms of compilers. But, I just downloaded your precompiled binary onto this 8 core machine, and keep seeing the ThreadSafetyTest test failure below. Unrelated, I was trying to run the tests based on the truffle.jar you provide, but it doesn?t contain the unit tests. Might be useful to also provide a jar with the unit tests. That could help with running such tests easily. I have still no idea what is going on here. But since very recently, I have severe issues with the correctness of TruffleSOM executions. And, I suspect there is something funky going on with the background compilation. But, wasn?t able to confirm that yet. Best regards Stefan smarr at Infinity:~/tmp/test/graalvm-jdk1.8.0$ bin/java -server -cp ../graal/lib/junit-4.8.jar:truffle-0.2.jar:../graal/graal/com.oracle.truffle.api.test/bin/ org.junit.runner.JUnitCore com.oracle.truffle.api.test.ThreadSafetyTest JUnit version 4.8 .E Time: 39.163 There was 1 failure: 1) test(com.oracle.truffle.api.test.ThreadSafetyTest) java.lang.AssertionError: expected:<1000000> but was:<766512> at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.failNotEquals(Assert.java:645) at org.junit.Assert.assertEquals(Assert.java:126) at org.junit.Assert.assertEquals(Assert.java:470) at org.junit.Assert.assertEquals(Assert.java:454) at com.oracle.truffle.api.test.ThreadSafetyTest.testTarget(ThreadSafetyTest.java:79) at com.oracle.truffle.api.test.ThreadSafetyTest.test(ThreadSafetyTest.java:57) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) 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) FAILURES!!! Tests run: 1, Failures: 1 -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/ From bernhard.urban at jku.at Wed Mar 26 21:29:48 2014 From: bernhard.urban at jku.at (Bernhard Urban) Date: Wed, 26 Mar 2014 22:29:48 +0100 Subject: checkSnippetKills In-Reply-To: References: Message-ID: Hi Tom, thanks, there's indeed a problem around SnippetCounters. First, as a comment in the snippet counter implementation already suggest, it should not use ANY_LOCATION but a separate location designated to snippet counters. After doing that, it exposes another problem around HotSpot stubs. Stubs are not allowed to embed oops in their code. Thus my fix excludes snippet counters in snippets designed for stubs. Apparently we don't use snippet counters that much lately ;-) I'm pushing it through the gate now, in the meanwhile you can fetch the patch from here: http://lafo.ssw.uni-linz.ac.at/lewurm/snippetcounters.patch -Bernhard On Wed, Mar 26, 2014 at 8:36 PM, Deneau, Tom wrote: > I just tried this with the amd64 backend and got similar results > I compiled: > MyObj[] escapingObject; > > public void newObjTest(int gid) { > escapingObject[gid] = new MyObj(); > } > > and using -G:+SnippetCounters > > The log showed > > Lowering allocateInstance in > StructuredGraph:18{HotSpotMethod}: > node=159|NewInstance, > template=StructuredGraph:39{HotSpotMethod Word, Word, boolean, Register, boolean, String)>}( [0], long [1], > [2], [3], [4], [5], > [6]), arguments=Parameters 16, hub = 124|Const(4296021216), prototypeMarkWord = 5, const fillContents > = true, const threadRegister = r15, const constantSize = true, const > typeContext = > > WARNING: 159|NewInstance is not a MemoryCheckpoint, but > the snippet graph contains kills ([ANY_LOCATION]). You might want > 159|NewInstance to be a MemoryCheckpoint > [thread:1] scope: > BasicTest2.Compiling.GraalCompiler.FrontEnd.LowTier.Lowering.IncrementalCanonicalizer.LoweringIteration0.InterceptException > Exception occurred in scope: > BasicTest2.Compiling.GraalCompiler.FrontEnd.LowTier.Lowering.IncrementalCanonicalizer.LoweringIteration0.InterceptException > Context obj java.lang.AssertionError: snippet graph > contains a kill to ANY_LOCATION, but replacee (159|NewInstance) doesn't > kill ANY_LOCATION. kills: [ANY_LOCATION] > > > > > -----Original Message----- > > From: Deneau, Tom > > Sent: Wednesday, March 26, 2014 2:27 PM > > To: graal-dev at openjdk.java.net > > Subject: checkSnippetKills > > > > I have a snippet for NewInstance that works but I wanted to increment a > > snippet counter on one of the paths thru the snippet. After doing that > > and using -G:+SnippetCounters, I get the following error: > > > > java.lang.AssertionError: snippet graph contains a kill to ANY_LOCATION, > > but replacee (333|NewInstance) doesn't kill ANY_LOCATION. kills: > > [ANY_LOCATION, Initialization] > > at > > com.oracle.graal.replacements.SnippetTemplate.checkSnippetKills(SnippetT > > emplate.java:946) > > > > How should this be corrected? > > > > -- Tom > > From tom.deneau at amd.com Wed Mar 26 22:35:16 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 26 Mar 2014 22:35:16 +0000 Subject: checkSnippetKills In-Reply-To: References: Message-ID: Bernhard -- OK, so if in my own snippets I only plan to use snippet counters outside of stubs, I only need the change to SnippetCounter.java itself, is that correct? Were the NewObjectSnippets the only ones where snippets could be used inside of stubs? -- Tom From: lewurm at gmail.com [mailto:lewurm at gmail.com] On Behalf Of Bernhard Urban Sent: Wednesday, March 26, 2014 4:30 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: checkSnippetKills Hi Tom, thanks, there's indeed a problem around SnippetCounters. First, as a comment in the snippet counter implementation already suggest, it should not use ANY_LOCATION but a separate location designated to snippet counters. After doing that, it exposes another problem around HotSpot stubs. Stubs are not allowed to embed oops in their code. Thus my fix excludes snippet counters in snippets designed for stubs. Apparently we don't use snippet counters that much lately ;-) I'm pushing it through the gate now, in the meanwhile you can fetch the patch from here: http://lafo.ssw.uni-linz.ac.at/lewurm/snippetcounters.patch -Bernhard On Wed, Mar 26, 2014 at 8:36 PM, Deneau, Tom > wrote: I just tried this with the amd64 backend and got similar results I compiled: MyObj[] escapingObject; public void newObjTest(int gid) { escapingObject[gid] = new MyObj(); } and using -G:+SnippetCounters The log showed Lowering allocateInstance in StructuredGraph:18{HotSpotMethod}: node=159|NewInstance, template=StructuredGraph:39{HotSpotMethod}( [0], long [1], [2], [3], [4], [5], [6]), arguments=Parameters WARNING: 159|NewInstance is not a MemoryCheckpoint, but the snippet graph contains kills ([ANY_LOCATION]). You might want 159|NewInstance to be a MemoryCheckpoint [thread:1] scope: BasicTest2.Compiling.GraalCompiler.FrontEnd.LowTier.Lowering.IncrementalCanonicalizer.LoweringIteration0.InterceptException Exception occurred in scope: BasicTest2.Compiling.GraalCompiler.FrontEnd.LowTier.Lowering.IncrementalCanonicalizer.LoweringIteration0.InterceptException Context obj java.lang.AssertionError: snippet graph contains a kill to ANY_LOCATION, but replacee (159|NewInstance) doesn't kill ANY_LOCATION. kills: [ANY_LOCATION] > -----Original Message----- > From: Deneau, Tom > Sent: Wednesday, March 26, 2014 2:27 PM > To: graal-dev at openjdk.java.net > Subject: checkSnippetKills > > I have a snippet for NewInstance that works but I wanted to increment a > snippet counter on one of the paths thru the snippet. After doing that > and using -G:+SnippetCounters, I get the following error: > > java.lang.AssertionError: snippet graph contains a kill to ANY_LOCATION, > but replacee (333|NewInstance) doesn't kill ANY_LOCATION. kills: > [ANY_LOCATION, Initialization] > at > com.oracle.graal.replacements.SnippetTemplate.checkSnippetKills(SnippetT > emplate.java:946) > > How should this be corrected? > > -- Tom From doug.simon at oracle.com Wed Mar 26 22:51:58 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Wed, 26 Mar 2014 22:51:58 +0000 Subject: hg: graal/graal: 25 new changesets Message-ID: <201403262252.s2QMqXEP022161@aojmv0008> Changeset: 164903a50a9a Author: Erik Eckstein Date: 2014-03-26 10:04 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/164903a50a9a make ensureUniquePC an abstract method of the base Assembler class ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Assembler.java ! graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.java ! graal/com.oracle.graal.asm.ptx/src/com/oracle/graal/asm/ptx/PTXAssembler.java ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCMacroAssembler.java ! graal/com.oracle.graal.asm/src/com/oracle/graal/asm/Assembler.java Changeset: 3128becfec95 Author: Erik Eckstein Date: 2014-03-26 10:06 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3128becfec95 add Debug.logAndIndent with enabled-flag ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java Changeset: 3e1e83287128 Author: Erik Eckstein Date: 2014-03-26 10:08 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3e1e83287128 add assertion to detect infinite recursion in snippet inlining ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java Changeset: 91c88fc2157c Author: Erik Eckstein Date: 2014-03-26 10:10 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/91c88fc2157c make scheduling in IdealGraphPrinter optional ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/IdealGraphPrinter.java Changeset: c612c2742a4f Author: Erik Eckstein Date: 2014-03-26 10:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c612c2742a4f extend graph builder and CompilationResult for substrateVM ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CompilationResult.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/FrameStateBuilder.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: 56721cd3f8ba Author: Erik Eckstein Date: 2014-03-26 10:16 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/56721cd3f8ba remove a GraphOrder assertion which does not hold in substrate VM ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/util/GraphOrder.java Changeset: c59eaa8d6632 Author: Erik Eckstein Date: 2014-03-26 10:26 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c59eaa8d6632 fix ecliipseformat error ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/util/GraphOrder.java Changeset: 7608c74e14b6 Author: Bernhard Urban Date: 2014-03-26 10:52 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7608c74e14b6 changelog: repo links should point to tagname ! CHANGELOG.md Changeset: c6f4b780fa88 Author: Bernhard Urban Date: 2014-03-26 14:32 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c6f4b780fa88 mx: increase minimum required jdk version ! mx/mx_graal.py Changeset: a6c1c3eb20c4 Author: Doug Simon Date: 2014-03-26 14:34 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a6c1c3eb20c4 transition to JDK8 - introduce support for more than one JDK in mx - update version in annotiationprocessors - update project definitions (truffle api is not part of the transition) - fix style errors ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/InductionVariables.java ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionProcessor.java ! graal/com.oracle.graal.options/src/com/oracle/graal/options/OptionValue.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.replacements.verifier/src/com/oracle/graal/replacements/verifier/VerifierAnnotationProcessor.java ! graal/com.oracle.graal.service.processor/src/com/oracle/graal/service/processor/ServiceProviderProcessor.java ! mx/projects ! mxtool/mx.py Changeset: 5823c399e28f Author: Bernhard Urban Date: 2014-03-26 14:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5823c399e28f pylint fixes ! mxtool/mx.py Changeset: 365800f2a7aa Author: Bernhard Urban Date: 2014-03-26 21:52 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/365800f2a7aa SnippetCounter: use own location for counter ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetCounter.java Changeset: 390d72c7cc04 Author: Bernhard Urban Date: 2014-03-26 22:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/390d72c7cc04 SnippetCounters: HotSpot stubs are not allowed to embed oops, thus exclude them in stubs ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.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 Changeset: ded08e344e4a Author: Doug Simon Date: 2014-03-26 17:30 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ded08e344e4a findbugs will also use any findbugsExcludeFilter.xml it finds in a suite's root ! mx/mx_graal.py Changeset: 3e9a960f0da1 Author: Doug Simon Date: 2014-03-26 17:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3e9a960f0da1 HSAIL: preliminary deopt support Contributed-by: Tom Deneau - graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ExternalCompilationResult.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ReferenceMap.java ! graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/AbstractHSAILAssembler.java ! graal/com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail/HSAILAssembler.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.infra/src/com/oracle/graal/compiler/hsail/test/infra/KernelTester.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BasicHSAILTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCatchBase.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCatchMany16384Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCatchMany20000Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCatchMany5000Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCatchMany8192Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCatchMany987654HighTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCatchMany987654Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCatchMany99999Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCatchManyBase.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCatchMost1000Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCatchMost20000Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCatchSingle16384Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCatchSingle20000Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCatchSingle5000Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCatchSingle8192Test.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCatchSingleBase.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCheckDoubleNonZeroBciTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCheckFailsInMiddleTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCheckFloatNonZeroBciTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCheckInlineTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCheckLongNonZeroBciTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCheckNonZeroBciInstanceTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCheckNonZeroBciTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/BoundsCheckTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ClassCastNonZeroBciTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/ClassCastTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntStreamNullCatchNonZeroBciTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntStreamNullCheckNonZeroBciTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntStreamNullCheckTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntStreamNullNonArrayParamCheckTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntStreamNullParamCheckTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/SingleExceptionTestBase.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/StaticMandelBoundsCheckTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Vec3ObjStreamClassCastNonZeroBciTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Vec3ObjStreamClassCastTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Vec3ObjStreamNullCheckNonZeroBciTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Vec3ObjStreamNullCheckTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/Vec3ObjStreamNullParamCheckTest.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/PTXMethodInvalidation1Test.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/PTXTest.java + graal/com.oracle.graal.gpu/src/com/oracle/graal/gpu/ExternalCompilationResult.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/HSAILHotSpotBackend.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/src/com/oracle/graal/hotspot/HotSpotReferenceMap.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VMErrorNode.java ! graal/com.oracle.graal.hsail/src/com/oracle/graal/hsail/HSAIL.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java ! mx/projects ! src/gpu/hsail/vm/gpu_hsail.cpp ! src/gpu/hsail/vm/gpu_hsail.hpp + src/gpu/hsail/vm/gpu_hsail_Frame.hpp + src/gpu/hsail/vm/hsailArgumentsBase.cpp + src/gpu/hsail/vm/hsailArgumentsBase.hpp + src/gpu/hsail/vm/hsailJavaCallArguments.hpp - src/gpu/hsail/vm/hsailKernelArguments.cpp ! src/gpu/hsail/vm/hsailKernelArguments.hpp + src/gpu/hsail/vm/vmStructs_hsail.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalCompiler.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 141d570b397c Author: Doug Simon Date: 2014-03-26 17:36 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/141d570b397c fixed pylint errors ! mx/mx_graal.py Changeset: beea13269eab Author: Doug Simon Date: 2014-03-26 20:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/beea13269eab removed GraalDeoptLeafGraphIds_lock ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: f87c23fd304d Author: Doug Simon Date: 2014-03-26 21:07 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f87c23fd304d canonicalized projects ! mx/projects Changeset: c929a4a3b6c5 Author: Doug Simon Date: 2014-03-26 21:08 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c929a4a3b6c5 added checkheaders command for checking Java source headers without relying on Checkstyle ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLAddNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLBigIntegerLiteralNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLDivNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLFunctionLiteralNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLLongLiteralNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLMulNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLStringLiteralNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/expression/SLSubNode.java ! mx/mx_graal.py Changeset: 78343531acc7 Author: Doug Simon Date: 2014-03-26 21:10 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/78343531acc7 added checkheaders to the gate ! mx/mx_graal.py Changeset: 8594b26fc5d8 Author: Doug Simon Date: 2014-03-26 22:17 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8594b26fc5d8 fixed incorrect uses of Debug.log API ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java Changeset: 40aa1eb176db Author: Doug Simon Date: 2014-03-26 22:18 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/40aa1eb176db mx: added support for excluding dependencies from distributions ! mxtool/mx.py Changeset: 07dd21c7d533 Author: Doug Simon Date: 2014-03-26 22:19 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/07dd21c7d533 revived use of FindBugs annotations ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/debug/BenchmarkCounters.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/AheadOfTimeVerificationPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/StringSubstitutions.java ! mx/projects Changeset: 10c6700908ef Author: Doug Simon Date: 2014-03-26 22:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/10c6700908ef mx: removed use of exclusion filter files from findbugs command - graal/findbugsExcludeFilter.xml ! mx/mx_graal.py Changeset: 5720104b54ba Author: Doug Simon Date: 2014-03-26 22:38 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5720104b54ba Merge. From doug.simon at oracle.com Wed Mar 26 22:53:07 2014 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 26 Mar 2014 23:53:07 +0100 Subject: Transition Graal to Java 8 Message-ID: <343DA700-3CAD-44B0-87E5-C4A708EA7FC2@oracle.com> The changeset[1] has just gone through that transitions the non-pure-Truffle projects in the Graal repository to Java 1.8. The recommended steps for transitioning a local workspace are: 1. Ensure Eclipse is running on a 1.8 VM by editing eclipse.ini in the Eclipse installation directory (Eclipse.app/Contents/MacOS/eclipse.ini on Mac) to include these lines: -vm /path/to/jdk1.8.0/bin/java or on a Mac: -vm /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/server/libjvm.dylib 2. Ensure you are using an Eclipse that has 1.8 support. This is one of the following: - Luna (4.4), version I20140318-0830 or later - Kepler (4.3.2) with the patch at http://download.eclipse.org/eclipse/updates/4.3-P-builds installed. Only select "Eclipse JDT (Java Development Tools) Patch with Java 8 support (for Kepler SR2)? unless you already have PDE installed. 3. Configure the JavaSE-1.7 and JavaSE-1.8 Execution Environments appropriately in Eclipse (Preferences -> Java -> Installed JREs -> Execution Environments) 4. If you want to build with ECJ, then download it[2] to mx/ecj.jar 5. Update mx/env so that JAVA_HOME points to the 1.8 JDK and add a property EXTRA_JAVA_HOMES to point to a 1.7 JDK. For example: JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home EXTRA_JAVA_HOMES=/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home 6. Do a complete clean (just to be sure): mx clean mx ideclean mx eclipseinit 6. Remove and re-add all projects in Eclipse. Note that it is not yet quite open season on using Java 8 language features as Checkstyle does not yet support Java 8. In all likelihood we will replace Checkstyle with error-prone[3]. Either way, Checkstyle will be pulled out soon which removes the last road block to adopting all of Java 8. -Doug [1] http://hg.openjdk.java.net/graal/graal/rev/a6c1c3eb20c4 [2] http://download.eclipse.org/eclipse/downloads/drops4/P20140317-1600/download.php?dropFile=ecj-P20140317-1600.jar [3] https://code.google.com/p/error-prone/ From bernhard.urban at jku.at Thu Mar 27 10:23:19 2014 From: bernhard.urban at jku.at (Bernhard Urban) Date: Thu, 27 Mar 2014 11:23:19 +0100 Subject: checkSnippetKills In-Reply-To: References: Message-ID: On Wed, Mar 26, 2014 at 11:35 PM, Deneau, Tom wrote: > Bernhard -- > > > > OK, so if in my own snippets I only plan to use snippet counters outside > of stubs, I only need the change to SnippetCounter.java itself, is that > correct? > Yes. > Were the NewObjectSnippets the only ones where snippets could be used > inside of stubs? > Every snippet code can be used inside a snippet stub, but I think it was the only case where we had this problem of dragging in snippet counters on amd64hotspot. -Bernhard > > > -- Tom > > > > *From:* lewurm at gmail.com [mailto:lewurm at gmail.com] *On Behalf Of *Bernhard > Urban > *Sent:* Wednesday, March 26, 2014 4:30 PM > *To:* Deneau, Tom > *Cc:* graal-dev at openjdk.java.net > *Subject:* Re: checkSnippetKills > > > > Hi Tom, > > > > thanks, there's indeed a problem around SnippetCounters. First, as a > comment in the snippet counter implementation already suggest, it should > not use ANY_LOCATION but a separate location designated to snippet > counters. After doing that, it exposes another problem around HotSpot > stubs. Stubs are not allowed to embed oops in their code. Thus my fix > excludes snippet counters in snippets designed for stubs. > > > > Apparently we don't use snippet counters that much lately ;-) I'm pushing > it through the gate now, in the meanwhile you can fetch the patch from > here: http://lafo.ssw.uni-linz.ac.at/lewurm/snippetcounters.patch > > > > -Bernhard > > > > On Wed, Mar 26, 2014 at 8:36 PM, Deneau, Tom wrote: > > I just tried this with the amd64 backend and got similar results > I compiled: > MyObj[] escapingObject; > > public void newObjTest(int gid) { > escapingObject[gid] = new MyObj(); > } > > and using -G:+SnippetCounters > > The log showed > > Lowering allocateInstance in > StructuredGraph:18{HotSpotMethod}: > node=159|NewInstance, > template=StructuredGraph:39{HotSpotMethod Word, Word, boolean, Register, boolean, String)>}( [0], long [1], > [2], [3], [4], [5], > [6]), arguments=Parameters 16, hub = 124|Const(4296021216), prototypeMarkWord = 5, const fillContents > = true, const threadRegister = r15, const constantSize = true, const > typeContext = > > WARNING: 159|NewInstance is not a MemoryCheckpoint, but > the snippet graph contains kills ([ANY_LOCATION]). You might want > 159|NewInstance to be a MemoryCheckpoint > [thread:1] scope: > BasicTest2.Compiling.GraalCompiler.FrontEnd.LowTier.Lowering.IncrementalCanonicalizer.LoweringIteration0.InterceptException > Exception occurred in scope: > BasicTest2.Compiling.GraalCompiler.FrontEnd.LowTier.Lowering.IncrementalCanonicalizer.LoweringIteration0.InterceptException > Context obj java.lang.AssertionError: snippet graph > contains a kill to ANY_LOCATION, but replacee (159|NewInstance) doesn't > kill ANY_LOCATION. kills: [ANY_LOCATION] > > > > > > -----Original Message----- > > From: Deneau, Tom > > Sent: Wednesday, March 26, 2014 2:27 PM > > To: graal-dev at openjdk.java.net > > Subject: checkSnippetKills > > > > I have a snippet for NewInstance that works but I wanted to increment a > > snippet counter on one of the paths thru the snippet. After doing that > > and using -G:+SnippetCounters, I get the following error: > > > > java.lang.AssertionError: snippet graph contains a kill to ANY_LOCATION, > > but replacee (333|NewInstance) doesn't kill ANY_LOCATION. kills: > > [ANY_LOCATION, Initialization] > > at > > com.oracle.graal.replacements.SnippetTemplate.checkSnippetKills(SnippetT > > emplate.java:946) > > > > How should this be corrected? > > > > -- Tom > > > From tom.deneau at amd.com Thu Mar 27 13:17:55 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 27 Mar 2014 13:17:55 +0000 Subject: code movement from slow path into fast path Message-ID: question about code movement and fast_path_probability: My snippet looks like this... Word thread = thread(); Word top = atomicGetAndAddTlabTop(thread, size); Word end = readTlabEnd(thread); Word newTop = top.add(size); if (useTLAB() && probability(FAST_PATH_PROBABILITY, newTop.belowOrEqual(end))) { // writeTlabTop(thread, newTop) was done by the atomicGetAndAdd result = formatObject(hub, size, top, prototypeMarkWord, fillContents); } else { // slow path requiring eden access, etc. } The generated hsail is shown below. Why would the moves to $d8 and $d9 registers which are used only on the slow path be moved before the compare instruction? atomic_add_global_u64 $d4, [$d20 + 136], 24; // $d20 = thread register ld_global_s64 $d5, [$d20 + 152]; // readTlabEnd add_s64 $d6, $d4, 0x18; // newTop = top + size mov_b64 $d7, 0x100102d58; // class info for the class being allocated mov_b64 $d8, 0x7f001c0223b0; // eden-related pointer used only on the slow path mov_b64 $d9, 0x7f001c022388; // ditto cmp_lt_b1_u64 $c0, $d5, $d6; // newTop.belowOrEqual(end) cbr $c0, @L10; // @L10 = slow path @L26: ld_global_s64 $d5, [$d7 + 176]; // fast path object format, etc. st_global_s64 $d5, [$d4 + 0]; st_global_s32 537003435, [$d4 + 8]; st_global_s32 0, [$d4 + 12]; st_global_s64 0, [$d4 + 16]; [...] -- Tom From tom.rodriguez at oracle.com Thu Mar 27 17:58:02 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 27 Mar 2014 10:58:02 -0700 Subject: code movement from slow path into fast path In-Reply-To: References: Message-ID: <8CBF8EBE-670B-406B-A073-996B5EA55C5E@oracle.com> Constant placement is somewhat suboptimal currently. We?re trying to share them when we can so initially they are place at a point that dominates it?s usages. There are probably later uses though we probably don?t end up sharing them because of spilling. I?ve seen some much worse cases and I?ve looked at it a bit, but I think we need to revisit how we handle them both during LIR generation and in the register allocator. It?s definitely wrong for your example. tom On Mar 27, 2014, at 6:17 AM, Deneau, Tom wrote: > question about code movement and fast_path_probability: > > My snippet looks like this... > > Word thread = thread(); > Word top = atomicGetAndAddTlabTop(thread, size); > Word end = readTlabEnd(thread); > Word newTop = top.add(size); > if (useTLAB() && probability(FAST_PATH_PROBABILITY, newTop.belowOrEqual(end))) { > // writeTlabTop(thread, newTop) was done by the atomicGetAndAdd > result = formatObject(hub, size, top, prototypeMarkWord, fillContents); > } else { > // slow path requiring eden access, etc. > } > > The generated hsail is shown below. Why would the moves to $d8 and $d9 registers which are used only on the slow path be moved before the compare instruction? > > atomic_add_global_u64 $d4, [$d20 + 136], 24; // $d20 = thread register > ld_global_s64 $d5, [$d20 + 152]; // readTlabEnd > add_s64 $d6, $d4, 0x18; // newTop = top + size > mov_b64 $d7, 0x100102d58; // class info for the class being allocated > mov_b64 $d8, 0x7f001c0223b0; // eden-related pointer used only on the slow path > mov_b64 $d9, 0x7f001c022388; // ditto > cmp_lt_b1_u64 $c0, $d5, $d6; // newTop.belowOrEqual(end) > cbr $c0, @L10; // @L10 = slow path > @L26: > ld_global_s64 $d5, [$d7 + 176]; // fast path object format, etc. > st_global_s64 $d5, [$d4 + 0]; > st_global_s32 537003435, [$d4 + 8]; > st_global_s32 0, [$d4 + 12]; > st_global_s64 0, [$d4 + 16]; > [...] > > -- Tom > From rednaxelafx at gmail.com Thu Mar 27 18:24:08 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 27 Mar 2014 11:24:08 -0700 Subject: code movement from slow path into fast path In-Reply-To: <8CBF8EBE-670B-406B-A073-996B5EA55C5E@oracle.com> References: <8CBF8EBE-670B-406B-A073-996B5EA55C5E@oracle.com> Message-ID: Hi Tom, Just curious, is that behavior related to the (disabled) rematerialization of constants in LinearScan? Thanks, Kris On Thu, Mar 27, 2014 at 10:58 AM, Tom Rodriguez wrote: > Constant placement is somewhat suboptimal currently. We're trying to > share them when we can so initially they are place at a point that > dominates it's usages. There are probably later uses though we probably > don't end up sharing them because of spilling. I've seen some much worse > cases and I've looked at it a bit, but I think we need to revisit how we > handle them both during LIR generation and in the register allocator. It's > definitely wrong for your example. > > tom > > On Mar 27, 2014, at 6:17 AM, Deneau, Tom wrote: > > > question about code movement and fast_path_probability: > > > > My snippet looks like this... > > > > Word thread = thread(); > > Word top = atomicGetAndAddTlabTop(thread, size); > > Word end = readTlabEnd(thread); > > Word newTop = top.add(size); > > if (useTLAB() && probability(FAST_PATH_PROBABILITY, > newTop.belowOrEqual(end))) { > > // writeTlabTop(thread, newTop) was done by the > atomicGetAndAdd > > result = formatObject(hub, size, top, prototypeMarkWord, > fillContents); > > } else { > > // slow path requiring eden access, etc. > > } > > > > The generated hsail is shown below. Why would the moves to $d8 and $d9 > registers which are used only on the slow path be moved before the compare > instruction? > > > > atomic_add_global_u64 $d4, [$d20 + 136], 24; // $d20 = > thread register > > ld_global_s64 $d5, [$d20 + 152]; // readTlabEnd > > add_s64 $d6, $d4, 0x18; // newTop = top > + size > > mov_b64 $d7, 0x100102d58; // class info > for the class being allocated > > mov_b64 $d8, 0x7f001c0223b0; // eden-related > pointer used only on the slow path > > mov_b64 $d9, 0x7f001c022388; // ditto > > cmp_lt_b1_u64 $c0, $d5, $d6; // > newTop.belowOrEqual(end) > > cbr $c0, @L10; // @L10 = slow > path > > @L26: > > ld_global_s64 $d5, [$d7 + 176]; // fast path > object format, etc. > > st_global_s64 $d5, [$d4 + 0]; > > st_global_s32 537003435, [$d4 + 8]; > > st_global_s32 0, [$d4 + 12]; > > st_global_s64 0, [$d4 + 16]; > > [...] > > > > -- Tom > > > > From tom.rodriguez at oracle.com Thu Mar 27 18:40:06 2014 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 27 Mar 2014 11:40:06 -0700 Subject: code movement from slow path into fast path In-Reply-To: References: <8CBF8EBE-670B-406B-A073-996B5EA55C5E@oracle.com> Message-ID: <83AA4772-9AA0-4E3C-A62A-2ACC4D413FCB@oracle.com> The initial dominating placement is due to commoning of constants. Rematerialization isn?t disabled as far as I can see. The implementation has a few problems though since there?s no def-use info in linear scan. For instance the initial materialization can hang around even if all the uses have picked up other materialized copies. That should be fixable and is the source of some ugly looking generated code. When last this was being worked on we were also switching back and forth between ConstantNodeRecordsUsages which behaves differently as well and may have lead to our current state. When ConstantNodeRecordsUsages is false it enable a sort of lazy commoning of constants which I think is probably a better initial cut. It might work best if it could ensure that it doesn?t share uncommon constants and force their materialization in a common path as in Tom?s example. So I think smarter sharing logic in LIRGenerator along with some rematerialization fixes should get us where we want to be. tom On Mar 27, 2014, at 11:24 AM, Krystal Mok wrote: > Hi Tom, > > Just curious, is that behavior related to the (disabled) rematerialization of constants in LinearScan? > > Thanks, > Kris > > > On Thu, Mar 27, 2014 at 10:58 AM, Tom Rodriguez wrote: > Constant placement is somewhat suboptimal currently. We?re trying to share them when we can so initially they are place at a point that dominates it?s usages. There are probably later uses though we probably don?t end up sharing them because of spilling. I?ve seen some much worse cases and I?ve looked at it a bit, but I think we need to revisit how we handle them both during LIR generation and in the register allocator. It?s definitely wrong for your example. > > tom > > On Mar 27, 2014, at 6:17 AM, Deneau, Tom wrote: > > > question about code movement and fast_path_probability: > > > > My snippet looks like this... > > > > Word thread = thread(); > > Word top = atomicGetAndAddTlabTop(thread, size); > > Word end = readTlabEnd(thread); > > Word newTop = top.add(size); > > if (useTLAB() && probability(FAST_PATH_PROBABILITY, newTop.belowOrEqual(end))) { > > // writeTlabTop(thread, newTop) was done by the atomicGetAndAdd > > result = formatObject(hub, size, top, prototypeMarkWord, fillContents); > > } else { > > // slow path requiring eden access, etc. > > } > > > > The generated hsail is shown below. Why would the moves to $d8 and $d9 registers which are used only on the slow path be moved before the compare instruction? > > > > atomic_add_global_u64 $d4, [$d20 + 136], 24; // $d20 = thread register > > ld_global_s64 $d5, [$d20 + 152]; // readTlabEnd > > add_s64 $d6, $d4, 0x18; // newTop = top + size > > mov_b64 $d7, 0x100102d58; // class info for the class being allocated > > mov_b64 $d8, 0x7f001c0223b0; // eden-related pointer used only on the slow path > > mov_b64 $d9, 0x7f001c022388; // ditto > > cmp_lt_b1_u64 $c0, $d5, $d6; // newTop.belowOrEqual(end) > > cbr $c0, @L10; // @L10 = slow path > > @L26: > > ld_global_s64 $d5, [$d7 + 176]; // fast path object format, etc. > > st_global_s64 $d5, [$d4 + 0]; > > st_global_s32 537003435, [$d4 + 8]; > > st_global_s32 0, [$d4 + 12]; > > st_global_s64 0, [$d4 + 16]; > > [...] > > > > -- Tom > > > > From tom.deneau at amd.com Thu Mar 27 20:03:58 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 27 Mar 2014 20:03:58 +0000 Subject: code movement from slow path into fast path In-Reply-To: <83AA4772-9AA0-4E3C-A62A-2ACC4D413FCB@oracle.com> References: <8CBF8EBE-670B-406B-A073-996B5EA55C5E@oracle.com> <83AA4772-9AA0-4E3C-A62A-2ACC4D413FCB@oracle.com> Message-ID: I noticed the same constant movement happens in the case of snippet counters. Even though the counters are only incremented on the slow path, the counter references are moved to registers up on the fast path. -- Tom From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] Sent: Thursday, March 27, 2014 1:40 PM To: Krystal Mok Cc: Deneau, Tom; graal-dev at openjdk.java.net Subject: Re: code movement from slow path into fast path The initial dominating placement is due to commoning of constants. Rematerialization isn't disabled as far as I can see. The implementation has a few problems though since there's no def-use info in linear scan. For instance the initial materialization can hang around even if all the uses have picked up other materialized copies. That should be fixable and is the source of some ugly looking generated code. When last this was being worked on we were also switching back and forth between ConstantNodeRecordsUsages which behaves differently as well and may have lead to our current state. When ConstantNodeRecordsUsages is false it enable a sort of lazy commoning of constants which I think is probably a better initial cut. It might work best if it could ensure that it doesn't share uncommon constants and force their materialization in a common path as in Tom's example. So I think smarter sharing logic in LIRGenerator along with some rematerialization fixes should get us where we want to be. tom On Mar 27, 2014, at 11:24 AM, Krystal Mok > wrote: Hi Tom, Just curious, is that behavior related to the (disabled) rematerialization of constants in LinearScan? Thanks, Kris On Thu, Mar 27, 2014 at 10:58 AM, Tom Rodriguez > wrote: Constant placement is somewhat suboptimal currently. We're trying to share them when we can so initially they are place at a point that dominates it's usages. There are probably later uses though we probably don't end up sharing them because of spilling. I've seen some much worse cases and I've looked at it a bit, but I think we need to revisit how we handle them both during LIR generation and in the register allocator. It's definitely wrong for your example. tom On Mar 27, 2014, at 6:17 AM, Deneau, Tom > wrote: > question about code movement and fast_path_probability: > > My snippet looks like this... > > Word thread = thread(); > Word top = atomicGetAndAddTlabTop(thread, size); > Word end = readTlabEnd(thread); > Word newTop = top.add(size); > if (useTLAB() && probability(FAST_PATH_PROBABILITY, newTop.belowOrEqual(end))) { > // writeTlabTop(thread, newTop) was done by the atomicGetAndAdd > result = formatObject(hub, size, top, prototypeMarkWord, fillContents); > } else { > // slow path requiring eden access, etc. > } > > The generated hsail is shown below. Why would the moves to $d8 and $d9 registers which are used only on the slow path be moved before the compare instruction? > > atomic_add_global_u64 $d4, [$d20 + 136], 24; // $d20 = thread register > ld_global_s64 $d5, [$d20 + 152]; // readTlabEnd > add_s64 $d6, $d4, 0x18; // newTop = top + size > mov_b64 $d7, 0x100102d58; // class info for the class being allocated > mov_b64 $d8, 0x7f001c0223b0; // eden-related pointer used only on the slow path > mov_b64 $d9, 0x7f001c022388; // ditto > cmp_lt_b1_u64 $c0, $d5, $d6; // newTop.belowOrEqual(end) > cbr $c0, @L10; // @L10 = slow path > @L26: > ld_global_s64 $d5, [$d7 + 176]; // fast path object format, etc. > st_global_s64 $d5, [$d4 + 0]; > st_global_s32 537003435, [$d4 + 8]; > st_global_s32 0, [$d4 + 12]; > st_global_s64 0, [$d4 + 16]; > [...] > > -- Tom > From doug.simon at oracle.com Fri Mar 28 02:00:09 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 28 Mar 2014 02:00:09 +0000 Subject: hg: graal/graal: 84 new changesets Message-ID: <201403280202.s2S222HQ008625@aojmv0008> Changeset: 0a2c211e9cd1 Author: Doug Simon Date: 2014-03-27 09:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0a2c211e9cd1 reverted 3128becfec95 ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java Changeset: aaecb0ca0c7d Author: Doug Simon Date: 2014-03-27 09:46 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/aaecb0ca0c7d fixed hard coded reference to JDK7 ! mx/mx_graal.py Changeset: d2038d372cd2 Author: Doug Simon Date: 2014-03-27 12:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d2038d372cd2 changed distribution dependency exclusion mechanism to be only for library dependencies ! mx/projects ! mxtool/mx.py Changeset: 145949aeeccb Author: Roland Schatz Date: 2014-03-27 13:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/145949aeeccb Regression test for issue fixed in 6ae9af961b7c. + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/deopt/MonitorDeoptTest.java Changeset: 01786db19f7d Author: Roland Schatz Date: 2014-03-27 13:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/01786db19f7d Rename deoptState fields to reflect whether they refer to a state before or during. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/G1PreWriteBarrier.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractDeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizingFixedWithNextNode.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/extended/ForeignCallNode.java Changeset: 4ab660bf17df Author: Roland Schatz Date: 2014-03-27 13:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4ab660bf17df Add assertions to ensure that the deoptimizing FrameState is unique in LIR generation. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java Changeset: 66ac13a2c7a1 Author: Lukas Stadler Date: 2014-03-27 16:54 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/66ac13a2c7a1 pass EXTRA_JAVA_HOMES to eclipse builders ! mxtool/mx.py Changeset: a6595f1b55b0 Author: Josef Eisl Date: 2014-03-12 12:09 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a6595f1b55b0 Make LIR use AbstractBlock. (errors) ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/backend/AllocatorTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/ControlFlowOptimizer.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/EdgeMoveOptimizer.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIR.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRVerifier.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/NullCheckOptimizer.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/RedundantMoveElimination.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/CompilationResultBuilder.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/AbstractBlock.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinterObserver.java Changeset: 6ce74db1c9fb Author: Josef Eisl Date: 2014-03-12 13:38 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6ce74db1c9fb Use List instead of Iterable in AbstractBlock to (temporary) allow editing. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/ControlFlowOptimizer.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/AbstractBlock.java Changeset: f0da23ee8315 Author: Josef Eisl Date: 2014-03-12 16:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f0da23ee8315 Work around printCFG / AbstractBlock issue. ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinterObserver.java Changeset: 1596a21c4194 Author: Josef Eisl Date: 2014-03-12 19:32 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1596a21c4194 Move remaining Block references in LinearScan to AbstractBlock. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: 3518daf2f9bc Author: Josef Eisl Date: 2014-03-12 20:32 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3518daf2f9bc Add call to GraalCompiler.emitCode() from BaselineCompiler. ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineCompiler.java + graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/LIRBlock.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! mx/projects Changeset: be2be30c653d Author: Josef Eisl Date: 2014-03-12 20:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/be2be30c653d Introduce AbstractControlFlowGraph. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIR.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/AbstractControlFlowGraph.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/BlockMap.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/ControlFlowGraph.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinterObserver.java Changeset: b9805a622546 Author: Niclas Adlertz Date: 2014-03-14 13:57 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/b9805a622546 Created abstract class FrameStateBuilder ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXWrapperBuilder.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/HotSpotSignature.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/TailcallNode.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/GraphKit.java Changeset: c4e65d48887c Author: Niclas Adlertz Date: 2014-03-14 13:59 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/c4e65d48887c Added the HIRAbstractFrameStateBuilder + graal/com.oracle.graal.java/src/com/oracle/graal/java/HIRFrameStateBuilder.java Changeset: 63b0a6af67b7 Author: Niclas Adlertz Date: 2014-03-14 16:12 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/63b0a6af67b7 added abstract base class + graal/com.oracle.graal.java/src/com/oracle/graal/java/AbstractFrameStateBuilder.java Changeset: 9f8b3c49fb42 Author: Josef Eisl Date: 2014-03-13 11:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9f8b3c49fb42 merge ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java ! mx/projects Changeset: f5b3292b4ded Author: Josef Eisl Date: 2014-03-13 13:28 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f5b3292b4ded Restrict access to members of LIRGenerator. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/backend/AllocatorTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.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/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/AllocaNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/DimensionsNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorCounterNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/TailcallNode.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java Changeset: 18d5ffb7ac38 Author: Josef Eisl Date: 2014-03-13 17:11 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/18d5ffb7ac38 Create AbstractBlockBase. + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/AbstractBlockBase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/Block.java Changeset: cc2f1661f473 Author: Josef Eisl Date: 2014-03-13 17:16 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/cc2f1661f473 Create BlocksToDoubles and use it in the backend. ! graal/com.oracle.graal.alloc/src/com/oracle/graal/alloc/ComputeBlockOrder.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/BlocksToDoubles.java Changeset: 01afd501f127 Author: Josef Eisl Date: 2014-03-13 17:18 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/01afd501f127 Updated getStartBlock() in AbstractControlFlowGraph. ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/AbstractControlFlowGraph.java Changeset: f19d64d2cf69 Author: Josef Eisl Date: 2014-03-13 17:19 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f19d64d2cf69 Add LIRControlFlowGraph. + graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/LIRControlFlowGraph.java Changeset: 66d3397c2c0d Author: Josef Eisl Date: 2014-03-13 18:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/66d3397c2c0d Change to AbstractBlock in LIR.setLir(). ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIR.java Changeset: 10dde0063f5a Author: Josef Eisl Date: 2014-03-13 18:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/10dde0063f5a BaselineCompiler: update LIRBlock. ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineCompiler.java ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/LIRBlock.java Changeset: c4219e527b83 Author: Josef Eisl Date: 2014-03-14 17:19 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c4219e527b83 Merge. - agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotGraphCache.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/HIRFrameStateBuilder.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/GraphCache.java ! mx/projects - src/os/bsd/dtrace/hotspot.d - src/os/bsd/dtrace/hotspot_jni.d - src/os/bsd/dtrace/hs_private.d - src/os/solaris/dtrace/hotspot.d - src/os/solaris/dtrace/hotspot_jni.d - src/os/solaris/dtrace/hs_private.d - src/share/vm/utilities/dtrace_usdt2_disabled.hpp Changeset: 056357ac3efb Author: Josef Eisl Date: 2014-03-17 18:36 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/056357ac3efb Introduce LIRGenerationResult interface. + graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerationResult.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.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java Changeset: 9334612dd438 Author: Josef Eisl Date: 2014-03-17 19:11 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9334612dd438 Introduce LIRGenerationResultBase. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerationResult.java + graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerationResultBase.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java Changeset: a8723f1ff542 Author: Josef Eisl Date: 2014-03-17 19:18 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a8723f1ff542 LIR renamed setter and getter functions. ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineCompiler.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/backend/AllocatorTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/RegisterVerifier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/ControlFlowOptimizer.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/EdgeMoveOptimizer.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIR.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRVerifier.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LabelRef.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/NullCheckOptimizer.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/RedundantMoveElimination.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/StandardOp.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/CompilationResultBuilder.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java Changeset: c3242028cc44 Author: Josef Eisl Date: 2014-03-17 20:05 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c3242028cc44 Introduce specialized LIRGenerationResults for Targets if needed. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerationResult.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/AMD64HotSpotLIRGenerationResult.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.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerationResult.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java Changeset: 6352a2b94ca7 Author: Josef Eisl Date: 2014-03-18 10:28 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6352a2b94ca7 LIRGenerator: add getter for DebugInfoBuilder and CallingConvention. ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java Changeset: 73774616a6b3 Author: Josef Eisl Date: 2014-03-18 13:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/73774616a6b3 Decoupled LIRGenerator and LIRGenerationResult. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/backend/AllocatorTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerationResult.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerationResultBase.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java + graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRGenerator.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/AMD64HotSpotLIRGenerationResult.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.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/PTXHotSpotLIRGenerator.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/SPARCHotSpotLIRGenerator.java Changeset: eab93bf521d7 Author: Josef Eisl Date: 2014-03-18 14:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/eab93bf521d7 Introduce LIRGenResLowerable. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java + graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/LIRGenResLowerable.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/AllocaNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/DimensionsNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorCounterNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/TailcallNode.java Changeset: 73a77e65c805 Author: Josef Eisl Date: 2014-03-18 14:50 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/73a77e65c805 Resolve BaselineCompiler LIRGenerationResult issues. ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineCompiler.java Changeset: 20dcae7f93eb Author: Josef Eisl Date: 2014-03-19 13:35 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/20dcae7f93eb Introduce LIRGeneratorCommon and NodeBasedLIRGenerator interfaces. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java + graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGeneratorCommon.java + graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeBasedLIRGenerator.java Changeset: fafbff0eeebf Author: Josef Eisl Date: 2014-03-19 13:50 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/fafbff0eeebf Removed NodeLIRGenerator again. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java - graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRGenerator.java Changeset: f200eb890729 Author: Josef Eisl Date: 2014-03-19 15:10 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f200eb890729 Handle AbstractBlock in CFGPrinter. ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinterObserver.java Changeset: 61821c3e9235 Author: Josef Eisl Date: 2014-03-19 15:13 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/61821c3e9235 Track AbstractBlock in LIRGenerator. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java Changeset: 836d558c3a5f Author: Josef Eisl Date: 2014-03-19 15:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/836d558c3a5f Create Baseline version of doBlock in LIRGenerator. ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineCompiler.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/gen/LIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGeneratorCommon.java Changeset: 80147dac0d6e Author: Niclas Adlertz Date: 2014-03-18 09:56 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/80147dac0d6e LIRFrameStateBuilder added + graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/LIRFrameStateBuilder.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/deopt/CompiledMethodTest.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.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64RawNativeCallNode.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXWrapperBuilder.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/meta/HotSpotLoweringProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nfi/NativeCallStubGraphBuilder.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/phases/AheadOfTimeVerificationPhase.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/AbstractFrameStateBuilder.java - graal/com.oracle.graal.java/src/com/oracle/graal/java/FrameStateBuilder.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/HIRFrameStateBuilder.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInside.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FrameState.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/InvokeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/UnwindNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValueNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValueNodeUtil.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/IntegerBelowThanNode.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/LeftShiftNode.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/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/extended/ForeignCallNode.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/SwitchNode.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/InstanceOfDynamicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoweredCompareAndSwapNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/TypeSwitchNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.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/ReadEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java ! graal/com.oracle.graal.replacements.hsail/src/com/oracle/graal/replacements/hsail/HSAILMathIntrinsicsNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/GraphKit.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.replacements/src/com/oracle/graal/replacements/nodes/DirectObjectStoreNode.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/ReadRegisterNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/ReverseBytesNode.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/nodes/typesystem/CustomizedUnsafeLoadFinalNode.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/PartialEscapeClosure.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 ! graal/com.oracle.graal.word/src/com/oracle/graal/word/nodes/WordCastNode.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: 3d04915a55c6 Author: Niclas Adlertz Date: 2014-03-19 10:29 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/3d04915a55c6 added kindinterface for valuenode and variable and started to generalize some methods used for bytecodeparsing ! graal/com.oracle.graal.java/src/com/oracle/graal/java/AbstractFrameStateBuilder.java + graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParseHelper.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/Variable.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/KindInterface.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValueNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValueNodeUtil.java Changeset: fb4b44ae8f5c Author: Niclas Adlertz Date: 2014-03-19 14:25 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/fb4b44ae8f5c Remove beginNode() from AbstractBlock interface ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/LIRBlock.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/AbstractBlock.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/BlocksToDoubles.java Changeset: 2ff2a660c4d8 Author: Josef Eisl Date: 2014-03-19 15:22 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2ff2a660c4d8 merge ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/TailcallNode.java - graal/com.oracle.graal.java/src/com/oracle/graal/java/FrameStateBuilder.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java Changeset: 71ec7648c56c Author: Josef Eisl Date: 2014-03-19 15:26 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/71ec7648c56c Fix baseline compiler warnings. ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/LIRBlock.java ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/LIRFrameStateBuilder.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/AbstractBlock.java Changeset: 39daeb102dce Author: Josef Eisl Date: 2014-03-19 17:07 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/39daeb102dce Baseline compiler emitPrologue. ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineCompiler.java + graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/BaselineLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGeneratorCommon.java Changeset: 9fbc1a798558 Author: Josef Eisl Date: 2014-03-19 17:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9fbc1a798558 Use AbstractBlock in StandardOp. ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/StandardOp.java Changeset: 115974c4c7fc Author: Josef Eisl Date: 2014-03-19 17:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/115974c4c7fc Specialize (baseline) emitPrologue for AMD64 and PTX. ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineCompiler.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java Changeset: 5ddfdc13027a Author: Josef Eisl Date: 2014-03-19 19:02 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5ddfdc13027a Baseline emit return. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java Changeset: 17a735726670 Author: Josef Eisl Date: 2014-03-20 13:50 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/17a735726670 Merge. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.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/alloc/LinearScanWalker.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/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReferenceMap.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/Marks.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotLoweringProvider.java - graal/com.oracle.graal.java.decompiler.test/src/com/oracle/graal/java/decompiler/test/Test.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/HIRFrameStateBuilder.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/CompilationResultBuilder.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInside.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PhiNode.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/ReadEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.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/SnippetTemplate.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/PEReadEliminationClosure.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/ReadEliminationClosure.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/nodes/WordCastNode.java ! mx/projects Changeset: 2ed3233503b8 Author: Niclas Adlertz Date: 2014-03-20 18:09 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/2ed3233503b8 Starting point of the baseline bytecode parser + graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/KindInterface.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Value.java ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineCompiler.java ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/LIRControlFlowGraph.java ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/LIRFrameStateBuilder.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/BaselineLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/HIRFrameStateBuilder.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/Variable.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/KindInterface.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java Changeset: 2b17b6c55880 Author: Niclas Adlertz Date: 2014-03-21 13:50 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/2b17b6c55880 Added predecessors to BciBlock ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineCompiler.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java Changeset: 8f6f63e997ba Author: Niclas Adlertz Date: 2014-03-24 10:24 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/8f6f63e997ba BciBlock extends AbstractBlockBase ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineCompiler.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java Changeset: 0361885370fb Author: Josef Eisl Date: 2014-03-24 10:42 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0361885370fb Fix warnings. ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/KindInterface.java ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/LIRFrameStateBuilder.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/BaselineLIRGenerator.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/AbstractFrameStateBuilder.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParseHelper.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/Variable.java Changeset: cbf616a24600 Author: Niclas Adlertz Date: 2014-03-24 12:10 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/cbf616a24600 Added baseline path in runCompilation ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineCompiler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! mx/projects Changeset: 4e784d4f5aea Author: Josef Eisl Date: 2014-03-24 11:58 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4e784d4f5aea BciBlockMapping use AbstractBlockBase.id instead of blockID. ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/AbstractBlockBase.java Changeset: 6c4b46e4f640 Author: Josef Eisl Date: 2014-03-24 13:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6c4b46e4f640 Introduce BytecodeParser interface. ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineCompiler.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java + graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/BytecodeParser.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java Changeset: dbe762fc0eb1 Author: Josef Eisl Date: 2014-03-24 13:56 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/dbe762fc0eb1 Set parameter frameState in BaselineCompiler. ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineCompiler.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/BaselineLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/BytecodeParser.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java Changeset: 6c50d8a6d394 Author: Josef Eisl Date: 2014-03-25 14:57 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6c50d8a6d394 Split up ArithmeticLIRGenerator interface. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/AndNode.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/FloatConvertNode.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/NarrowNode.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/ReinterpretNode.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/SignExtendNode.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/calc/ZeroExtendNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/ArithmeticLIRGenerator.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/ArithmeticLIRLowerable.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/NodeMappableArithmeticLIRGenerator.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/NodeMappableLIRGenerator.java ! graal/com.oracle.graal.replacements.amd64/src/com/oracle/graal/replacements/amd64/AMD64FloatConvertNode.java ! graal/com.oracle.graal.replacements.hsail/src/com/oracle/graal/replacements/hsail/HSAILMathIntrinsicsNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MathIntrinsicNode.java Changeset: 1cf373d2b415 Author: Josef Eisl Date: 2014-03-25 15:37 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1cf373d2b415 Rename LIRGeneratorTool to NodeBasedLIRGeneratorTool. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotSafepointOp.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/HotSpotLIRGenerator.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/DeoptimizeCallerNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/GetObjectAddressNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/JumpToExceptionHandlerInCallerNode.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/PatchReturnAddressNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/StubForeignCallNode.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64ArrayEqualsOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCBitManipulationOp.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractEndNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BreakpointNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/CallTargetNode.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/EntryMarkerNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardedValueNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InfopointNode.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/LogicConstantNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopEndNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryProxyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MergeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ReturnNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/SafepointNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/UnwindNode.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/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/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/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/extended/AddLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ComputeAddressNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ConstantLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FixedValueAnchorNode.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/ForeignCallNode.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/LocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/MembarNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/NullCheckNode.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/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/extended/WriteNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoweredCompareAndSwapNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MonitorIdNode.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/SelfReplacingMethodCallTargetNode.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/LIRLowerable.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/NodeBasedLIRGeneratorTool.java < graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LIRGeneratorTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualObjectNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/DirectReadNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/DirectStoreNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/WriteRegisterNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerAddExactSplitNode.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/arithmetic/IntegerMulExactSplitNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerSubExactSplitNode.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/nodes/WordCastNode.java Changeset: a433795f3af1 Author: Josef Eisl Date: 2014-03-25 15:53 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a433795f3af1 Split up NodeBasedLIRGeneratorTool. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LIRGeneratorTool.java < graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/NodeBasedLIRGeneratorTool.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/NodeBasedLIRGeneratorTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/NodeLIRGeneratorTool.java < graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/NodeBasedLIRGeneratorTool.java Changeset: 945e622f5e2f Author: Josef Eisl Date: 2014-03-25 16:01 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/945e622f5e2f Removed unused LIRGeneratorInterfaces. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java - graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGeneratorCommon.java - graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeBasedLIRGenerator.java Changeset: 3552926a218f Author: Josef Eisl Date: 2014-03-25 16:37 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3552926a218f Added NodeLIRGenerator. + graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRGenerator.java Changeset: f41429da9819 Author: Josef Eisl Date: 2014-03-25 17:23 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f41429da9819 Remove BaselineLIRGenerator. - graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/BaselineLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java Changeset: 47e4d2e01c6e Author: Josef Eisl Date: 2014-03-26 11:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/47e4d2e01c6e Split LIRGenerator and fix AMD64 backend. ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineCompiler.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java + graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64NodeLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/Backend.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/LIRGenLowerable.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/LIRGenResLowerable.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/AMD64HotSpotLIRGenerator.java + graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotNodeLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotSafepointOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64RawNativeCallNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotLIRGenerator.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotNodeLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/AllocaNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/BeginLockScopeNode.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/CurrentLockNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/DeoptimizeCallerNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/DimensionsNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/DirectCompareAndSwapNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/EndLockScopeNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/GetObjectAddressNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/JumpToExceptionHandlerInCallerNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorCounterNode.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/PatchReturnAddressNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/PrefetchAllocateNode.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/TailcallNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VMErrorNode.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64ArrayEqualsOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCBitManipulationOp.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractEndNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BreakpointNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/CallTargetNode.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/EntryMarkerNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardedValueNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InfopointNode.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/LogicConstantNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopEndNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MemoryProxyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MergeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ReturnNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/SafepointNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/UnwindNode.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/FloatAddNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatConvertNode.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/IntegerDivNode.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/NarrowNode.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/ReinterpretNode.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/SignExtendNode.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/calc/ZeroExtendNode.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/ComputeAddressNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ConstantLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FixedValueAnchorNode.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/ForeignCallNode.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/LocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/MembarNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/NullCheckNode.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/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/extended/WriteNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoweredCompareAndSwapNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MonitorIdNode.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/SelfReplacingMethodCallTargetNode.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/ArithmeticLIRLowerable.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/LIRLowerable.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/NodeBasedLIRGeneratorTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/NodeLIRGeneratorTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualObjectNode.java ! graal/com.oracle.graal.replacements.amd64/src/com/oracle/graal/replacements/amd64/AMD64FloatConvertNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/ArrayEqualsNode.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/DirectReadNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/DirectStoreNode.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/ReadRegisterNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/ReverseBytesNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/WriteRegisterNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerAddExactSplitNode.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/arithmetic/IntegerMulExactSplitNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/arithmetic/IntegerSubExactSplitNode.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/nodes/WordCastNode.java Changeset: f2e61bf2a2d8 Author: Josef Eisl Date: 2014-03-26 12:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f2e61bf2a2d8 Removed nodeOperands from LIRGenerator. ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineCompiler.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/LIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRGenerator.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/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotNodeLIRGenerator.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 Changeset: dd75a505f1b6 Author: Josef Eisl Date: 2014-03-26 13:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/dd75a505f1b6 Remove currentBlock from NodeLIRGenerator. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64NodeLIRGenerator.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/gen/NodeLIRGenerator.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/AMD64HotSpotNodeLIRGenerator.java Changeset: b9b1129a5d85 Author: Josef Eisl Date: 2014-03-26 15:04 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b9b1129a5d85 Fix NodeLIRGenerator.append() issue. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRGenerator.java Changeset: ba13350ee179 Author: Josef Eisl Date: 2014-03-26 15:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ba13350ee179 Fix LIRGenerator casting problem. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/BeginLockScopeNode.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/CurrentLockNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/DeoptimizeCallerNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorExitStubCall.java Changeset: 43cd57700476 Author: Josef Eisl Date: 2014-03-26 15:59 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/43cd57700476 Apply LIRGenerator refactoring to HSAIL backend. ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java + graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILNodeLIRGenerator.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/HSAILHotSpotLIRGenerator.java + graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotNodeLIRGenerator.java ! graal/com.oracle.graal.replacements.hsail/src/com/oracle/graal/replacements/hsail/HSAILMathIntrinsicsNode.java Changeset: c132602c640e Author: Josef Eisl Date: 2014-03-26 16:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c132602c640e Apply LIRGenerator refactoring to SPARC backend. ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java + graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCNodeLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRGenerator.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/SPARCHotSpotLIRGenerator.java + graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotNodeLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotSafepointOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCBitManipulationOp.java Changeset: b7948d5c0092 Author: Josef Eisl Date: 2014-03-26 17:02 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b7948d5c0092 Remove remaining LIRGenerator methods from NodeLIRGenerator. ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILNodeLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRGenerator.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/BitScanReverseNode.java Changeset: 97a0878202c2 Author: Josef Eisl Date: 2014-03-26 17:02 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/97a0878202c2 Apply LIRGenerator refactoring to PTX backend. ! 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/PTXNodeLIRGenerator.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/PTXHotSpotLIRGenerator.java + graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotNodeLIRGenerator.java Changeset: fbae9be45c95 Author: Josef Eisl Date: 2014-03-26 20:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/fbae9be45c95 Merge. ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineCompiler.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java + graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64MemoryPeephole.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64NodeLIRGenerator.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRGenerator.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/AMD64HotSpotMemoryPeephole.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotNodeLIRGenerator.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/HSAILHotSpotNodeLIRGenerator.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXWrapperBuilder.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CStringNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VMErrorNode.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.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/InfopointNode.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/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/FloatAddNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatConvertNode.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/IntegerTestNode.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/NarrowNode.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/ReinterpretNode.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/SignExtendNode.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/calc/ZeroExtendNode.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/ForeignCallNode.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/ValueAnchorNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/RegisterFinalizerNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/ArithmeticLIRGenerator.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/NodeLIRGeneratorTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/NodeMappableLIRGenerator.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MathIntrinsicNode.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/ReadEliminationClosure.java ! mx/projects Changeset: a5373295d454 Author: Josef Eisl Date: 2014-03-27 13:54 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a5373295d454 Remove state*() from NodeLIRGenerator. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64MemoryPeephole.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64NodeLIRGenerator.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILNodeLIRGenerator.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXNodeLIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCNodeLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotNodeLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotNodeLIRGenerator.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: f49e2f9cbdc3 Author: Josef Eisl Date: 2014-03-27 15:06 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f49e2f9cbdc3 Merge (defunc). - graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ExternalCompilationResult.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILNodeLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.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/HSAILHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotNodeLIRGenerator.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReferenceMap.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VMErrorNode.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/extended/ForeignCallNode.java - graal/findbugsExcludeFilter.xml ! mx/projects - src/gpu/hsail/vm/hsailKernelArguments.cpp Changeset: 6bde7deb5be1 Author: Josef Eisl Date: 2014-03-27 15:55 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6bde7deb5be1 Adopt HSAILLIRGenerator. ! 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/HSAILHotSpotLIRGenerationResult.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/HSAILHotSpotNodeLIRGenerator.java Changeset: 64e6a5484cac Author: Josef Eisl Date: 2014-03-27 16:21 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/64e6a5484cac Fix style issues. ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/KindInterface.java ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/LIRControlFlowGraph.java ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/LIRFrameStateBuilder.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotNodeLIRGenerator.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/AbstractFrameStateBuilder.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BytecodeParseHelper.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/BlocksToDoubles.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/ArithmeticLIRGenerator.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/NodeMappableLIRGenerator.java Changeset: 3a855006bf28 Author: Josef Eisl Date: 2014-03-27 16:23 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3a855006bf28 Remove unused interface. - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/NodeMappableArithmeticLIRGenerator.java Changeset: 0d158f22f14c Author: Josef Eisl Date: 2014-03-27 17:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0d158f22f14c Merge. Changeset: 9c089e418bc9 Author: Josef Eisl Date: 2014-03-27 17:41 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9c089e418bc9 Fix eclipse format. ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRGenerator.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java Changeset: 2372488fd33f Author: Josef Eisl Date: 2014-03-27 17:47 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2372488fd33f Canonicalize projects. ! mx/projects Changeset: 4f5c312d676e Author: Josef Eisl Date: 2014-03-27 18:35 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4f5c312d676e Fix merge regressions. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java Changeset: 8762b6b8fbb6 Author: Tom Rodriguez Date: 2014-03-27 13:11 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8762b6b8fbb6 fix scanning of method data for redefined methods ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp Changeset: 6325d3d82f1b Author: Tom Rodriguez Date: 2014-03-27 13:12 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6325d3d82f1b set MethodProfileWidth to 0 since it's unused ! src/cpu/sparc/vm/graalGlobals_sparc.hpp ! src/cpu/x86/vm/graalGlobals_x86.hpp Changeset: 0e713dba33bb Author: Michael Van De Vanter Date: 2014-03-27 16:38 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/0e713dba33bb Instrumentation: update probe nodes to new node API ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/instrument/InstrumentationProbeNode.java From tom.deneau at amd.com Fri Mar 28 18:56:37 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 28 Mar 2014 18:56:37 +0000 Subject: Transition Graal to Java 8 In-Reply-To: <343DA700-3CAD-44B0-87E5-C4A708EA7FC2@oracle.com> References: <343DA700-3CAD-44B0-87E5-C4A708EA7FC2@oracle.com> Message-ID: Doug -- So if we have junit tests that use the java8 lambda feature, should we wait until the checkstyle update/replacement that you mention in #6 below before proposing these as additions? -- Tom > -----Original Message----- > From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of > Doug Simon > Sent: Wednesday, March 26, 2014 5:53 PM > To: graal-dev at openjdk.java.net > Subject: Transition Graal to Java 8 > > The changeset[1] has just gone through that transitions the non-pure- > Truffle projects in the Graal repository to Java 1.8. > > The recommended steps for transitioning a local workspace are: > > 1. Ensure Eclipse is running on a 1.8 VM by editing eclipse.ini in the > Eclipse installation directory (Eclipse.app/Contents/MacOS/eclipse.ini > on Mac) to include these lines: > > -vm > /path/to/jdk1.8.0/bin/java > > or on a Mac: > > -vm > /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ser > ver/libjvm.dylib > > > 2. Ensure you are using an Eclipse that has 1.8 support. This is one of > the following: > - Luna (4.4), version I20140318-0830 or later > - Kepler (4.3.2) with the patch at > http://download.eclipse.org/eclipse/updates/4.3-P-builds installed. > Only select "Eclipse JDT (Java Development Tools) Patch with Java 8 > support (for Kepler SR2)" unless > you already have PDE installed. > 3. Configure the JavaSE-1.7 and JavaSE-1.8 Execution Environments > appropriately in Eclipse (Preferences -> Java -> Installed JREs -> > Execution Environments) 4. If you want to build with ECJ, then download > it[2] to mx/ecj.jar 5. Update mx/env so that JAVA_HOME points to the 1.8 > JDK and add a property EXTRA_JAVA_HOMES to point to a 1.7 JDK. > For example: > > > JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home > > EXTRA_JAVA_HOMES=/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Conte > nts/Home > > 6. Do a complete clean (just to be sure): > > mx clean > mx ideclean > mx eclipseinit > > 6. Remove and re-add all projects in Eclipse. > > Note that it is not yet quite open season on using Java 8 language > features as Checkstyle does not yet support Java 8. In all likelihood we > will replace Checkstyle with error-prone[3]. Either way, Checkstyle will > be pulled out soon which removes the last road block to adopting all of > Java 8. > > -Doug > > [1] http://hg.openjdk.java.net/graal/graal/rev/a6c1c3eb20c4 > [2] http://download.eclipse.org/eclipse/downloads/drops4/P20140317- > 1600/download.php?dropFile=ecj-P20140317-1600.jar > [3] https://code.google.com/p/error-prone/ From doug.simon at oracle.com Fri Mar 28 23:06:46 2014 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 29 Mar 2014 00:06:46 +0100 Subject: Transition Graal to Java 8 In-Reply-To: References: <343DA700-3CAD-44B0-87E5-C4A708EA7FC2@oracle.com> Message-ID: <879C0160-77B2-453C-BC1B-1772022147E4@oracle.com> I?m thinking that it might be best to simply disable Checkstyle until it supports Java8 or we have a replacement for it. What do the other Graal devs say? While I?m sure everyone would conscientiously try to adhere to the style guide currently enforce by Checkstyle, there will inevitably be some cleanup necessary once Checkstyle is re-enabled. But I think that?s a fair trade off for being able to use Java8 features earlier. -Doug On Mar 28, 2014, at 7:56 PM, Deneau, Tom wrote: > Doug -- > > So if we have junit tests that use the java8 lambda feature, should we wait > until the checkstyle update/replacement that you mention in #6 below before > proposing these as additions? > > -- Tom > >> -----Original Message----- >> From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of >> Doug Simon >> Sent: Wednesday, March 26, 2014 5:53 PM >> To: graal-dev at openjdk.java.net >> Subject: Transition Graal to Java 8 >> >> The changeset[1] has just gone through that transitions the non-pure- >> Truffle projects in the Graal repository to Java 1.8. >> >> The recommended steps for transitioning a local workspace are: >> >> 1. Ensure Eclipse is running on a 1.8 VM by editing eclipse.ini in the >> Eclipse installation directory (Eclipse.app/Contents/MacOS/eclipse.ini >> on Mac) to include these lines: >> >> -vm >> /path/to/jdk1.8.0/bin/java >> >> or on a Mac: >> >> -vm >> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ser >> ver/libjvm.dylib >> >> >> 2. Ensure you are using an Eclipse that has 1.8 support. This is one of >> the following: >> - Luna (4.4), version I20140318-0830 or later >> - Kepler (4.3.2) with the patch at >> http://download.eclipse.org/eclipse/updates/4.3-P-builds installed. >> Only select "Eclipse JDT (Java Development Tools) Patch with Java 8 >> support (for Kepler SR2)" unless >> you already have PDE installed. >> 3. Configure the JavaSE-1.7 and JavaSE-1.8 Execution Environments >> appropriately in Eclipse (Preferences -> Java -> Installed JREs -> >> Execution Environments) 4. If you want to build with ECJ, then download >> it[2] to mx/ecj.jar 5. Update mx/env so that JAVA_HOME points to the 1.8 >> JDK and add a property EXTRA_JAVA_HOMES to point to a 1.7 JDK. >> For example: >> >> >> JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home >> >> EXTRA_JAVA_HOMES=/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Conte >> nts/Home >> >> 6. Do a complete clean (just to be sure): >> >> mx clean >> mx ideclean >> mx eclipseinit >> >> 6. Remove and re-add all projects in Eclipse. >> >> Note that it is not yet quite open season on using Java 8 language >> features as Checkstyle does not yet support Java 8. In all likelihood we >> will replace Checkstyle with error-prone[3]. Either way, Checkstyle will >> be pulled out soon which removes the last road block to adopting all of >> Java 8. >> >> -Doug >> >> [1] http://hg.openjdk.java.net/graal/graal/rev/a6c1c3eb20c4 >> [2] http://download.eclipse.org/eclipse/downloads/drops4/P20140317- >> 1600/download.php?dropFile=ecj-P20140317-1600.jar >> [3] https://code.google.com/p/error-prone/ > From doug.simon at oracle.com Sat Mar 29 02:00:07 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sat, 29 Mar 2014 02:00:07 +0000 Subject: hg: graal/graal: 19 new changesets Message-ID: <201403290200.s2T20ZnP027514@aojmv0008> Changeset: ea712c41c5a2 Author: Tom Rodriguez Date: 2014-03-27 22:17 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ea712c41c5a2 merge unsigned compare guards with constant indexes or limits ! 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 ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/StampTool.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java Changeset: 8e7667515e31 Author: Doug Simon Date: 2014-03-28 08:25 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8e7667515e31 updated to latest JAI library ! mx/projects Changeset: ae7cbf13e765 Author: Erik Eckstein Date: 2014-03-28 08:26 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ae7cbf13e765 correct guarding of Debug.logv in InliningUtil ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: a0185cd77565 Author: Erik Eckstein Date: 2014-03-28 08:38 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a0185cd77565 Truffle: refactor ompilation related classes for SubstrateVM ! graal/com.oracle.graal.truffle.test/src/com/oracle/graal/truffle/test/PartialEvaluationTest.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/CompilationProfile.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallNode.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTargetImpl.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/TruffleCacheImpl.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/substitutions/OptimizedCallTargetImplSubstitutions.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/OptimizedCallTargetSubstitutions.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/UnexpectedResultExceptionSubstitutions.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/UnexpectedResultException.java Changeset: 8c420f405328 Author: Erik Eckstein Date: 2014-03-28 08:39 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8c420f405328 Truffle: add missing TruffleCache base class + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java Changeset: 3efd4d8ace0b Author: Erik Eckstein Date: 2014-03-28 09:05 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3efd4d8ace0b Merge Changeset: 89a079df9cb4 Author: Erik Eckstein Date: 2014-03-28 09:18 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/89a079df9cb4 Backout changeset ae7cbf13e765708f228be3e2e666e13d421bbd8e ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: a8dce92315a2 Author: Erik Eckstein Date: 2014-03-28 09:47 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a8dce92315a2 Revert wrong change in InliningUtil Changeset: 667710021ea1 Author: Doug Simon Date: 2014-03-28 11:41 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/667710021ea1 removed methods in Indent that are redundant with those in Debug ! graal/com.oracle.graal.baseline/src/com/oracle/graal/baseline/BaselineCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/NodeLIRGenerator.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Indent.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugScope.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/RedundantMoveElimination.java Changeset: e6ce6d9f477f Author: Doug Simon Date: 2014-03-28 11:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e6ce6d9f477f made findbugs quiet if running headless ! mx/mx_graal.py Changeset: 00eb80d735ed Author: Doug Simon Date: 2014-03-28 12:39 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/00eb80d735ed removed Debug.printf and added multi-arg versions of Debug.dump ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugConfig.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/internal/DebugScope.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationPhase.java Changeset: 7dfc0e9fd45a Author: Doug Simon Date: 2014-03-28 14:58 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7dfc0e9fd45a added removal of trailing whitespace to eclipseformat to emulate the actions performed by the IDE ! mxtool/mx.py Changeset: 56704532e1cd Author: Bernhard Urban Date: 2014-03-28 12:01 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/56704532e1cd disable bootstrap in tiered mode ! src/share/vm/graal/graalCompiler.cpp Changeset: 626b02830dfc Author: Bernhard Urban Date: 2014-03-28 15:38 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/626b02830dfc amd64hotspot: don't install compressed oops if -XX:-UseCompressedOops ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64MemoryPeephole.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotMemoryPeephole.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/data/OopData.java Changeset: fdb912b1eb7b Author: Bernhard Urban Date: 2014-03-28 15:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/fdb912b1eb7b gate: use no tiered to test bootstrap, add scaladacapo-kiama (fastdebug) ! mx/mx_graal.py ! mx/sanitycheck.py Changeset: d786bfc78196 Author: Andreas Woess Date: 2014-03-28 17:51 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d786bfc78196 IGV: repair Graal CFG only filter ! src/share/tools/IdealGraphVisualizer/Graal/src/com/sun/hotspot/igv/graal/filters/GraalCFGFilter.java Changeset: 69375786ef70 Author: Andreas Woess Date: 2014-03-28 17:55 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/69375786ef70 ThreadSafetyTest: increase timeout and check test termination with assertion ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/ThreadSafetyTest.java Changeset: 73546bd550f0 Author: Andreas Woess Date: 2014-03-28 18:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/73546bd550f0 CompilerDirectives: add optional nonNull parameter to unsafeCast ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/FrameWithoutBoxing.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/substitutions/CompilerDirectivesSubstitutions.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerDirectives.java Changeset: 1415a62ac8b2 Author: Bernhard Urban Date: 2014-03-29 00:28 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1415a62ac8b2 allow to force bootstrap in tiered ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/runtime/globals_extension.hpp From gilwooden at gmail.com Sat Mar 29 14:09:12 2014 From: gilwooden at gmail.com (Gilles Duboscq) Date: Sat, 29 Mar 2014 15:09:12 +0100 Subject: Transition Graal to Java 8 In-Reply-To: <879C0160-77B2-453C-BC1B-1772022147E4@oracle.com> References: <343DA700-3CAD-44B0-87E5-C4A708EA7FC2@oracle.com> <879C0160-77B2-453C-BC1B-1772022147E4@oracle.com> Message-ID: I vote for disabling checkstyle. Actually I would vote for disabling checkstyle forever since we have formatter checks. -Gilles On 29 Mar 2014 00:09, "Doug Simon" wrote: > I?m thinking that it might be best to simply disable Checkstyle until it > supports Java8 or we have a replacement for it. What do the other Graal > devs say? > > While I?m sure everyone would conscientiously try to adhere to the style > guide currently enforce by Checkstyle, there will inevitably be some > cleanup necessary once Checkstyle is re-enabled. But I think that?s a fair > trade off for being able to use Java8 features earlier. > > -Doug > > On Mar 28, 2014, at 7:56 PM, Deneau, Tom wrote: > > > Doug -- > > > > So if we have junit tests that use the java8 lambda feature, should we > wait > > until the checkstyle update/replacement that you mention in #6 below > before > > proposing these as additions? > > > > -- Tom > > > >> -----Original Message----- > >> From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf > Of > >> Doug Simon > >> Sent: Wednesday, March 26, 2014 5:53 PM > >> To: graal-dev at openjdk.java.net > >> Subject: Transition Graal to Java 8 > >> > >> The changeset[1] has just gone through that transitions the non-pure- > >> Truffle projects in the Graal repository to Java 1.8. > >> > >> The recommended steps for transitioning a local workspace are: > >> > >> 1. Ensure Eclipse is running on a 1.8 VM by editing eclipse.ini in the > >> Eclipse installation directory (Eclipse.app/Contents/MacOS/eclipse.ini > >> on Mac) to include these lines: > >> > >> -vm > >> /path/to/jdk1.8.0/bin/java > >> > >> or on a Mac: > >> > >> -vm > >> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ser > >> ver/libjvm.dylib > >> > >> > >> 2. Ensure you are using an Eclipse that has 1.8 support. This is one of > >> the following: > >> - Luna (4.4), version I20140318-0830 or later > >> - Kepler (4.3.2) with the patch at > >> http://download.eclipse.org/eclipse/updates/4.3-P-builds installed. > >> Only select "Eclipse JDT (Java Development Tools) Patch with Java 8 > >> support (for Kepler SR2)" unless > >> you already have PDE installed. > >> 3. Configure the JavaSE-1.7 and JavaSE-1.8 Execution Environments > >> appropriately in Eclipse (Preferences -> Java -> Installed JREs -> > >> Execution Environments) 4. If you want to build with ECJ, then download > >> it[2] to mx/ecj.jar 5. Update mx/env so that JAVA_HOME points to the 1.8 > >> JDK and add a property EXTRA_JAVA_HOMES to point to a 1.7 JDK. > >> For example: > >> > >> > >> JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home > >> > >> EXTRA_JAVA_HOMES=/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Conte > >> nts/Home > >> > >> 6. Do a complete clean (just to be sure): > >> > >> mx clean > >> mx ideclean > >> mx eclipseinit > >> > >> 6. Remove and re-add all projects in Eclipse. > >> > >> Note that it is not yet quite open season on using Java 8 language > >> features as Checkstyle does not yet support Java 8. In all likelihood we > >> will replace Checkstyle with error-prone[3]. Either way, Checkstyle will > >> be pulled out soon which removes the last road block to adopting all of > >> Java 8. > >> > >> -Doug > >> > >> [1] http://hg.openjdk.java.net/graal/graal/rev/a6c1c3eb20c4 > >> [2] http://download.eclipse.org/eclipse/downloads/drops4/P20140317- > >> 1600/download.php?dropFile=ecj-P20140317-1600.jar > >> [3] https://code.google.com/p/error-prone/ > > > > From doug.simon at oracle.com Sun Mar 30 11:34:55 2014 From: doug.simon at oracle.com (Doug Simon) Date: Sun, 30 Mar 2014 13:34:55 +0200 Subject: Transition Graal to Java 8 In-Reply-To: References: <343DA700-3CAD-44B0-87E5-C4A708EA7FC2@oracle.com> <879C0160-77B2-453C-BC1B-1772022147E4@oracle.com> Message-ID: On Mar 29, 2014, at 3:09 PM, Gilles Duboscq wrote: > I vote for disabling checkstyle. > Actually I would vote for disabling checkstyle forever since we have formatter checks. Formatter checks? We have auto-formatting which is different. And auto-formatting doesn?t (can?t?) enforce style policies such as field name format etc. It also was not clear to me that error-prone can be made to perform all the current Checkstyle checks we have (and really care about). -Doug > On 29 Mar 2014 00:09, "Doug Simon" wrote: > I?m thinking that it might be best to simply disable Checkstyle until it supports Java8 or we have a replacement for it. What do the other Graal devs say? > > While I?m sure everyone would conscientiously try to adhere to the style guide currently enforce by Checkstyle, there will inevitably be some cleanup necessary once Checkstyle is re-enabled. But I think that?s a fair trade off for being able to use Java8 features earlier. > > -Doug > > On Mar 28, 2014, at 7:56 PM, Deneau, Tom wrote: > > > Doug -- > > > > So if we have junit tests that use the java8 lambda feature, should we wait > > until the checkstyle update/replacement that you mention in #6 below before > > proposing these as additions? > > > > -- Tom > > > >> -----Original Message----- > >> From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of > >> Doug Simon > >> Sent: Wednesday, March 26, 2014 5:53 PM > >> To: graal-dev at openjdk.java.net > >> Subject: Transition Graal to Java 8 > >> > >> The changeset[1] has just gone through that transitions the non-pure- > >> Truffle projects in the Graal repository to Java 1.8. > >> > >> The recommended steps for transitioning a local workspace are: > >> > >> 1. Ensure Eclipse is running on a 1.8 VM by editing eclipse.ini in the > >> Eclipse installation directory (Eclipse.app/Contents/MacOS/eclipse.ini > >> on Mac) to include these lines: > >> > >> -vm > >> /path/to/jdk1.8.0/bin/java > >> > >> or on a Mac: > >> > >> -vm > >> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ser > >> ver/libjvm.dylib > >> > >> > >> 2. Ensure you are using an Eclipse that has 1.8 support. This is one of > >> the following: > >> - Luna (4.4), version I20140318-0830 or later > >> - Kepler (4.3.2) with the patch at > >> http://download.eclipse.org/eclipse/updates/4.3-P-builds installed. > >> Only select "Eclipse JDT (Java Development Tools) Patch with Java 8 > >> support (for Kepler SR2)" unless > >> you already have PDE installed. > >> 3. Configure the JavaSE-1.7 and JavaSE-1.8 Execution Environments > >> appropriately in Eclipse (Preferences -> Java -> Installed JREs -> > >> Execution Environments) 4. If you want to build with ECJ, then download > >> it[2] to mx/ecj.jar 5. Update mx/env so that JAVA_HOME points to the 1.8 > >> JDK and add a property EXTRA_JAVA_HOMES to point to a 1.7 JDK. > >> For example: > >> > >> > >> JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home > >> > >> EXTRA_JAVA_HOMES=/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Conte > >> nts/Home > >> > >> 6. Do a complete clean (just to be sure): > >> > >> mx clean > >> mx ideclean > >> mx eclipseinit > >> > >> 6. Remove and re-add all projects in Eclipse. > >> > >> Note that it is not yet quite open season on using Java 8 language > >> features as Checkstyle does not yet support Java 8. In all likelihood we > >> will replace Checkstyle with error-prone[3]. Either way, Checkstyle will > >> be pulled out soon which removes the last road block to adopting all of > >> Java 8. > >> > >> -Doug > >> > >> [1] http://hg.openjdk.java.net/graal/graal/rev/a6c1c3eb20c4 > >> [2] http://download.eclipse.org/eclipse/downloads/drops4/P20140317- > >> 1600/download.php?dropFile=ecj-P20140317-1600.jar > >> [3] https://code.google.com/p/error-prone/ > > > From doug.simon at oracle.com Mon Mar 31 01:00:06 2014 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Mon, 31 Mar 2014 01:00:06 +0000 Subject: hg: graal/graal: 4 new changesets Message-ID: <201403310100.s2V10CG7005433@aojmv0008> Changeset: 6b579d35f95e Author: Thomas Wuerthinger Date: 2014-03-12 02:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6b579d35f95e Merge. Changeset: 54fa8e06831c Author: Thomas Wuerthinger Date: 2014-03-17 16:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/54fa8e06831c Merge. - agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotGraphCache.java - graal/com.oracle.graal.java.decompiler.test/src/com/oracle/graal/java/decompiler/test/Test.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/GraphCache.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/NodesToDoubles.java - src/os/bsd/dtrace/hotspot.d - src/os/bsd/dtrace/hotspot_jni.d - src/os/bsd/dtrace/hs_private.d - src/os/solaris/dtrace/hotspot.d - src/os/solaris/dtrace/hotspot_jni.d - src/os/solaris/dtrace/hs_private.d - src/share/vm/utilities/dtrace_usdt2_disabled.hpp Changeset: 1617b1e25d31 Author: Thomas Wuerthinger Date: 2014-03-19 11:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1617b1e25d31 Merge. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/Marks.java Changeset: 000c283d7b71 Author: Thomas Wuerthinger Date: 2014-03-30 16:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/000c283d7b71 Merge. - graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ExternalCompilationResult.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java - graal/com.oracle.graal.java/src/com/oracle/graal/java/FrameStateBuilder.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/substitutions/UnexpectedResultExceptionSubstitutions.java - graal/findbugsExcludeFilter.xml - src/gpu/hsail/vm/hsailKernelArguments.cpp From juan.fumero at ed.ac.uk Mon Mar 31 17:41:25 2014 From: juan.fumero at ed.ac.uk (Juan Jose Fumero) Date: Mon, 31 Mar 2014 18:41:25 +0100 Subject: Graph for lambda expression Message-ID: <1396287685.4089.26.camel@gofio> Hello, I am working with some transformations in the lambda graph. I am trying to create a new object in the lambda expression and return it. The input of the lambda expression, let say, is the type A and the return type is different (type B). The thing is I get different graphs if I declare and create at least one object of type B before the lambda. Here is a little testcase. 7 package com.gpu.stream.test; 8 9 public class TestCase { 10 11 public static void main(String []args) { 12 13 Tuple1[] tuple1 = new Tuple1[N]; 14 // tuple1[0] = new Tuple1<>(); // --> here 15 16 Stream streamTuple1 = new Stream(); 17 tuple1 = stream.map( 18 x -> { 19 int i = x; 20 Tuple1 t1 = new Tuple1<>(); 21 t1._1(x); 22 return t1; 23 }).run(v1); 24 } 25 } Stream is a method which receives a Function in jdk8. The input of this function is an Integer and the output should be a Tuple1 object created in the lambda expression. The class Tuple1 class is very simple: 7 package com.gpu.stream.test; 8 public class Tuple1 { 9 public T _1; 10 11 public T _1() { 12 return this._1; 13 } 14 15 public void _1(T _1) { 16 this._1 = _1; 17 } 18 } If I run the program TestCase and print the graph (note the line 14 is commented), I get the following graph for the lambda expression: 0|StartNode 1|Parameter(0) 2|FrameState at 0 3|Deopt 4|IsNull 5|GuardingPi I expected at least the NewInstanceNode and the ReturnNode. If I uncomment the line 14 in TestCase, the graph is the following: 0|StartNode 1|Parameter(0) 2|FrameState at 0 3|NewInstance 4|Return 5|IsNull 6|GuardingPi 7|StoreField#_1 8|FrameState at 5 9|FrameState at 15 In this case I would say the graph is correct. It contains the NewInstanceNode, ReturnNode and StoreFieldNodes. Is this the right behaviour? Why I need to create at least one object? Note: I am calling to the optimisations in Graal like Inlining, but if I do not call to the optimisations, the result is the same. Any idea? Thanks Juanjo -- PhD Student University of Edinburgh The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From rednaxelafx at gmail.com Mon Mar 31 17:58:24 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 31 Mar 2014 10:58:24 -0700 Subject: Graph for lambda expression In-Reply-To: <1396287685.4089.26.camel@gofio> References: <1396287685.4089.26.camel@gofio> Message-ID: Hi Juan, Out of total ignorance of Graal and Sumatra, this looks like you're hitting a class initialization issue. If a class has not been initialized at the time Graal compiles a method, then any use of that class will result in a Deopt in Graal. If you create an instance of Tuple1 before the stream.map(), it'll ensure the Tuple1 class is initialized. You use other means to force initialization of Tuple1, too, e.g. Class.forName(Tuple1.getName()). Try it and see if it works the same. If it works, then it should be it. BTW, new Tuple1<>[] will NOT force initialization of the Tuple1 class. - Kris On Mon, Mar 31, 2014 at 10:41 AM, Juan Jose Fumero wrote: > Hello, > > I am working with some transformations in the lambda graph. I am > trying to create a new object in the lambda expression and return it. > The input of the lambda expression, let say, is the type A and the > return type is different (type B). The thing is I get different graphs > if I declare and create at least one object of type B before the > lambda. > > Here is a little testcase. > > 7 package com.gpu.stream.test; > 8 > 9 public class TestCase { > 10 > 11 public static void main(String []args) { > 12 > 13 Tuple1[] tuple1 = new Tuple1[N]; > 14 // tuple1[0] = new Tuple1<>(); // --> here > 15 > 16 Stream streamTuple1 = new Stream(); > 17 tuple1 = stream.map( > 18 x -> { > 19 int i = x; > 20 Tuple1 t1 = new Tuple1<>(); > 21 t1._1(x); > 22 return t1; > 23 }).run(v1); > 24 } > 25 } > > > Stream is a method which receives a Function in jdk8. The input of > this function is an Integer and the output should be a Tuple1 object > created in the lambda expression. > > The class Tuple1 class is very simple: > > 7 package com.gpu.stream.test; > 8 public class Tuple1 { > 9 public T _1; > 10 > 11 public T _1() { > 12 return this._1; > 13 } > 14 > 15 public void _1(T _1) { > 16 this._1 = _1; > 17 } > 18 } > > > If I run the program TestCase and print the graph (note the line 14 is > commented), I get the following graph for the lambda expression: > > > 0|StartNode > 1|Parameter(0) > 2|FrameState at 0 > 3|Deopt > 4|IsNull > 5|GuardingPi > > I expected at least the NewInstanceNode and the ReturnNode. If I > uncomment the line 14 in TestCase, the graph is the following: > > 0|StartNode > 1|Parameter(0) > 2|FrameState at 0 > 3|NewInstance > 4|Return > 5|IsNull > 6|GuardingPi > 7|StoreField#_1 > 8|FrameState at 5 > 9|FrameState at 15 > > > In this case I would say the graph is correct. It contains the > NewInstanceNode, ReturnNode and StoreFieldNodes. > > > Is this the right behaviour? Why I need to create at least one object? > > > Note: I am calling to the optimisations in Graal like Inlining, but if I > do not call to the optimisations, the result is the same. > > > Any idea? > > Thanks > Juanjo > > > -- > PhD Student > University of Edinburgh > > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > From duboscq at ssw.jku.at Mon Mar 31 22:05:45 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Tue, 1 Apr 2014 00:05:45 +0200 Subject: Graph for lambda expression In-Reply-To: References: <1396287685.4089.26.camel@gofio> Message-ID: Hello Juan, I agree with Kris' diagnostic. The most likely problem is that some type is not loaded yet when you compile this method. You can try to run the method a few times normally before compiling it to be sure everything is loaded. You can also look at how we do our unit tests (especially in GraalCompilerTest and JTTTest). In those tests we configure the GraphBuilderPhase such that it eagerly loads classes to avoid this kind of problems. -Gilles On Mon, Mar 31, 2014 at 7:58 PM, Krystal Mok wrote: > Hi Juan, > > Out of total ignorance of Graal and Sumatra, this looks like you're hitting > a class initialization issue. If a class has not been initialized at the > time Graal compiles a method, then any use of that class will result in a > Deopt in Graal. > > If you create an instance of Tuple1 before the stream.map(), it'll ensure > the Tuple1 class is initialized. You use other means to force > initialization of Tuple1, too, e.g. Class.forName(Tuple1.getName()). Try it > and see if it works the same. If it works, then it should be it. > > BTW, new Tuple1<>[] will NOT force initialization of the Tuple1 class. > > - Kris > > > On Mon, Mar 31, 2014 at 10:41 AM, Juan Jose Fumero > wrote: > >> Hello, >> >> I am working with some transformations in the lambda graph. I am >> trying to create a new object in the lambda expression and return it. >> The input of the lambda expression, let say, is the type A and the >> return type is different (type B). The thing is I get different graphs >> if I declare and create at least one object of type B before the >> lambda. >> >> Here is a little testcase. >> >> 7 package com.gpu.stream.test; >> 8 >> 9 public class TestCase { >> 10 >> 11 public static void main(String []args) { >> 12 >> 13 Tuple1[] tuple1 = new Tuple1[N]; >> 14 // tuple1[0] = new Tuple1<>(); // --> here >> 15 >> 16 Stream streamTuple1 = new Stream(); >> 17 tuple1 = stream.map( >> 18 x -> { >> 19 int i = x; >> 20 Tuple1 t1 = new Tuple1<>(); >> 21 t1._1(x); >> 22 return t1; >> 23 }).run(v1); >> 24 } >> 25 } >> >> >> Stream is a method which receives a Function in jdk8. The input of >> this function is an Integer and the output should be a Tuple1 object >> created in the lambda expression. >> >> The class Tuple1 class is very simple: >> >> 7 package com.gpu.stream.test; >> 8 public class Tuple1 { >> 9 public T _1; >> 10 >> 11 public T _1() { >> 12 return this._1; >> 13 } >> 14 >> 15 public void _1(T _1) { >> 16 this._1 = _1; >> 17 } >> 18 } >> >> >> If I run the program TestCase and print the graph (note the line 14 is >> commented), I get the following graph for the lambda expression: >> >> >> 0|StartNode >> 1|Parameter(0) >> 2|FrameState at 0 >> 3|Deopt >> 4|IsNull >> 5|GuardingPi >> >> I expected at least the NewInstanceNode and the ReturnNode. If I >> uncomment the line 14 in TestCase, the graph is the following: >> >> 0|StartNode >> 1|Parameter(0) >> 2|FrameState at 0 >> 3|NewInstance >> 4|Return >> 5|IsNull >> 6|GuardingPi >> 7|StoreField#_1 >> 8|FrameState at 5 >> 9|FrameState at 15 >> >> >> In this case I would say the graph is correct. It contains the >> NewInstanceNode, ReturnNode and StoreFieldNodes. >> >> >> Is this the right behaviour? Why I need to create at least one object? >> >> >> Note: I am calling to the optimisations in Graal like Inlining, but if I >> do not call to the optimisations, the result is the same. >> >> >> Any idea? >> >> Thanks >> Juanjo >> >> >> -- >> PhD Student >> University of Edinburgh >> >> >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> >> From Eric.Caspole at amd.com Mon Mar 31 22:40:35 2014 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Mon, 31 Mar 2014 22:40:35 +0000 Subject: Graal and Clojure In-Reply-To: <532B5D35.4010108@yahoo.com> References: <1394063789.8387.YahooMailNeo@web122406.mail.ne1.yahoo.com> <5326354D.8010204@yahoo.com> <53277532.3030807@amd.com>,<532B5D35.4010108@yahoo.com> Message-ID: Hi Jules, I updated everything and got Clumatra running on the real hardware today. In project.clj, I used this: :jvm-opts ["-server" "-ea" "-esa" "-Xms1g" "-Xmx1g" "-verbosegc" "-G:Log=CodeGen" "-XX:+GPUOffload" "-XX:+TraceGPUInteraction"] Then make sure your /path/to/okra/dist/bin is in the PATH and LD_LIBRARY_PATH. When it is using the simulator, you will see this: [HSAIL] using _OKRA_SIM_LIB_PATH_=/tmp/okraresource.dir_2595501614013009358/libokra_x86_64.so With hardware or external okra you will see this: [HSAIL] library is libokra_x86_64.so Regards, Eric ________________________________________ From: Jules Gosnell [jules_gosnell at yahoo.com] Sent: Thursday, March 20, 2014 5:27 PM To: Caspole, Eric; graal-dev at openjdk.java.net; sumatra-dev at openjdk.java.net Subject: Re: Graal and Clojure Eric, I just checked support to Clumatra for running individual unit tests from the CLI - should be enough to get you set up with your debugger. All details at the bottom of the README. https://github.com/JulesGosnell/clumatra I'm afraid you will need to install maven if you don't already have it - for some reason lein does not seem to have a test-jar target. It is still a little rough around the edges, but better than nothing :-) I also just bought my HSA h/w - should be up and running next week sometime. Did you figure out how to enable native-mode Okra ? catch you later, Jules On 17/03/14 22:20, Eric Caspole wrote: > Hi everybody, > I was setting up a new HSA system today and I installed Clumatra and got > it working under the simulator. I have a real HSA system not too > different from this: > > http://code.google.com/p/aparapi/wiki/SettingUpLinuxHSAMachineForAparapi > > In the clojure/lein/maven based system there is so much harness I can't > immediately see how to switch in the real hardware version of Okra > instead of the simulator Okra that gets installed into maven and > exploded in /tmp when the tests run. > > Jules, could you show how to bypass the harness etc to switch the Okra? > Can I just run 1 test with a simple java command line? This makes it a > lot easier to use a debugger which I will definitely want to do. > > Otherwise this is a cool project and we already found 1 or 2 issues we > can fix in HSAIL Graal related to your clojure tests. > Regards, > Eric > > > > On 03/17/2014 06:43 AM, Doug Simon wrote: >> Hi Julian, >> >> In terms of what to test, I?ll leave it up to the Sumatra developers >> at AMD and Oracle to comment on what may be interesting. >> >> As far as I know, no one in the Graal team is that familiar with >> Clojure. This actually makes the value of having Clojure tests >> integrated into our gate system somewhat problematic - >> debugging/fixing failures may be difficult. I?d suggest you report >> failures your discover on the sumatra-dev and graal-dev lists and we >> can resolve them that way for now. >> >> In addition, for Graal we?re always interested in benchmark suites for >> JVM hosted languages. Can you recommend any well known and trusted >> Clojure benchmarks we should consider? >> >> -Doug >> >> On Mar 17, 2014, at 12:35 AM, Jules Gosnell >> wrote: >> >>> Doug, >>> >>> Sorry it has taken me a while to get back - I've been busy playing >>> with code. >>> >>> I currently have a small clojure testsuite up and running. I plan to >>> broaden this and then think about providing it in a junit-compatible >>> way to your project. >>> >>> I still haven't made up my mind exactly what I should be testing. It >>> seems unnecessary to duplicate all your tests in Clojure, since you >>> are already guarding against regression in these areas - I think I >>> will start out with a fairly general set of tests as I probe for >>> particular problem areas for Clojure, into which I may dive for more >>> detail - time will tell... if you have any ideas, please let me know. >>> >>> I've checked my stuff in at github, if anyone is interested - here is >>> the project: >>> >>> https://github.com/JulesGosnell/clumatra >>> >>> here is some clojure that I reverse engineered from GraalKernelTester: >>> >>> https://github.com/JulesGosnell/clumatra/blob/master/src/clumatra/core.clj >>> >>> >>> and here are the first successful tests: >>> >>> https://github.com/JulesGosnell/clumatra/blob/master/test/clumatra/core_test.clj >>> >>> >>> not very pretty yet - I am still feeling my way. >>> >>> cheers >>> >>> >>> Jules >>> >>> >>> >>> >>> On 06/03/14 10:24, Doug Simon wrote: >>>> Hi Julian, >>>> >>>> This looks very interesting and will be an good alternative testing >>>> vector for the Sumatra work as it matures. If Clojure tests can >>>> somehow be made to run from Junit, then I?m sure we can try >>>> integrating it into our testing. >>>> >>>> -Doug >>>> >>>> On Mar 6, 2014, at 12:56 AM, Julian Gosnell >>>> wrote: >>>> >>>>> Guys, >>>>> >>>>> I just built the Java8 / Graal / Okra stack and managed to run some >>>>> very simple Clojure copying the contents of one int array into >>>>> another one on Okra. >>>>> >>>>> https://groups.google.com/forum/#!topic/clojure/JpjK__NTR5Y >>>>> >>>>> >>>>> I find the ramifications of this very exciting :-) >>>>> >>>>> I understand that fn-ality is limited at the moment - but I am keen >>>>> to keep testing and to help ensure early visibility of Clojure >>>>> related issues to both communities - perhaps even the submission of >>>>> a Clojure testsuite if Graal developers thought that useful. >>>>> >>>>> I'd be very interested in your thoughts on Graal / Clojure. >>>>> >>>>> regards, >>>>> >>>>> >>>>> Jules >>>>> >>>> >>>> >>> >> >> > > From tom.deneau at amd.com Mon Mar 31 23:07:08 2014 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 31 Mar 2014 23:07:08 +0000 Subject: VirtualObjects at deoptimization points. Message-ID: Gilles -- I noticed in one of our java8 lambda tests (not yet pushed to trunk) we had some object allocation that was eliminated by escape analysis. But when we try to run this with the trunk now, we get com.oracle.graal.graph.GraalInternalError: unimplemented at com.oracle.graal.graph.GraalInternalError.unimplemented(GraalInternalError.java:38) at com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.getNodeForValueFromFrame(HSAILHotSpotLIRGenerator.java:182) at com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createFrameState(HSAILHotSpotLIRGenerator.java:149) at com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createHostDeoptBranch(HSAILHotSpotLIRGenerator.java:140) where the line 182 in getNodeForValueFromFrame has } else if (localValue instanceof VirtualObject) { throw GraalInternalError.unimplemented(); } What would we need to do to support VirtualObjects at our deoptimization infopoints? (We also don't support stack slots yet, but I think I understand what is needed to support those). -- Tom