Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15318] rvmroot/trunk
|
View:
New views
11 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15318] rvmroot/trunk
by David P Grove
::
Rate this Message:
Steve Blackburn <Steve.Blackburn@...> wrote on 02/03/2009 06:36:32 PM: |
|
|
Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15318] rvmroot/trunk
by Steve Blackburn
::
Rate this Message:
On 04/02/2009, at 1:14 PM, David P Grove wrote:
No worries. We've all made errors when committing. This one would have gone under the radar except that I stumbled on it while tracking down the compress regression which seemed to "magically" disappear. I guess for future reference, depending on the importance of the changes, the best thing to do would either be to simply reply to the list with that commit on the subject line (so that the reply comes up when searching on the commit id), or if it was significant, just back out and recommit as intended. In this case I was just trying to get to the bottom of the compress regression and was a bit baffled when it narrowed down to this commit. Even after reading through the commit I couldn't easily figure out why it "fixed" the compress regression. It disturbs me when performance changes significantly for no clear reason, so having some clue as to what's going on here would be helpful, and I was speculating that that was what Ian may have been trying to address (which is why I sought clarification). The issue with the barriers is that the changes amount to a change in an API which some people rely on heavily, so while it may make sense to change it, it really should be discussed first. --Steve ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Jikesrvm-core mailing list Jikesrvm-core@... https://lists.sourceforge.net/lists/listinfo/jikesrvm-core |
|
|
Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15318] rvmroot/trunk
by Ian Rogers (nabble)
::
Rate this Message:
2009/2/4 David P Grove <groved@...>:
> Steve Blackburn <Steve.Blackburn@...> wrote on 02/03/2009 06:36:32 > PM: >> >> Can explain to us what you were trying to do with r15318? The commit >> message says "fix typos", I assume that was a mistake on your part >> because the commit doesn't seem to have a lot to do with typos. A >> bunch of other things are going on in there which appear significant >> and that affect others: > > I'll leave it to Ian to explain the content of the commit, but I can confirm > that he meant to do two commits, one to fix a few typos and the second to > make the more interesting change. We tried to fix the commit log message > after the fact, but sf svn doesn't allow the necessary operation. > > --dave Hi Steve, the more interesting part of the commit were the changes to the barrier code. This is a speedup primarily on Intel baseline code. I'll take each barrier in turn: aastore: previously: the aastore would emit a call to checkstore and then a call to the aastore barrier now: a single aastore helper can inline both of these calls and therefore we pay only 1 call. Another consequence of this is the baseline compiler emits less code (which should make it faster). putfield/putstatic: previously: the arguments to the barrier routines in MemoryManager were in a different order to the values on the JVM's operand stack, to call the barrier the parameters were shuffled now: the order of operands on the barrier routines now match, we no longer need to shuffle parameters losing around 2 instructions (long 4 byte instructions) per baseline barrier call. Regards, Ian ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Jikesrvm-core mailing list Jikesrvm-core@... https://lists.sourceforge.net/lists/listinfo/jikesrvm-core |
|
|
Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15318] rvmroot/trunk
by Ian Rogers (nabble)
::
Rate this Message:
2009/2/4 Steve Blackburn <Steve.Blackburn@...>:
> On 04/02/2009, at 1:14 PM, David P Grove wrote: > > I'll leave it to Ian to explain the content of the commit, but I can confirm > that he meant to do two commits, one to fix a few typos and the second to > make the more interesting change. We tried to fix the commit log message > after the fact, but sf svn doesn't allow the necessary operation. > > No worries. We've all made errors when committing. This one would have > gone under the radar except that I stumbled on it while tracking down the > compress regression which seemed to "magically" disappear. I guess for > future reference, depending on the importance of the changes, the best thing > to do would either be to simply reply to the list with that commit on the > subject line (so that the reply comes up when searching on the commit id), > or if it was significant, just back out and recommit as intended. > In this case I was just trying to get to the bottom of the compress > regression and was a bit baffled when it narrowed down to this commit. What is the compress regression? > Even after reading through the commit I couldn't easily figure out why it > "fixed" the compress regression. It disturbs me when performance changes > significantly for no clear reason, so having some clue as to what's going on > here would be helpful, and I was speculating that that was what Ian may have > been trying to address (which is why I sought clarification). I've been trying to get the barrier code into shape but no one commit should have moved performance back. I think the major issue is that we've had a week or so of misleading performance results from Habanero. > The issue with the barriers is that the changes amount to a change in an API > which some people rely on heavily, so while it may make sense to change it, > it really should be discussed first. I thought the MemoryManager API was analogous to RuntimeEntrypoints, entry points for the compiler and not something that people should be deliberately coding against. Ian > --Steve > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code > to > build responsive, highly engaging applications that combine the power of > local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Jikesrvm-core mailing list > Jikesrvm-core@... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-core > > ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Jikesrvm-core mailing list Jikesrvm-core@... https://lists.sourceforge.net/lists/listinfo/jikesrvm-core |
|
|
Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15318] rvmroot/trunk
by Steve Blackburn
::
Rate this Message:
Thanks Ian,
> This is a speedup primarily on Intel baseline code. Have you had the opportunity to measure the performance effect of these changes? I can see (below) what motivated you to pursue these changes, but my experience (and I have to tell you I have recently spent a *lot* of time on barrier performance) is that intuition is generally not a good guide for these issues. The only way to know is to map out a few logical alternatives and then measure each of them thoroughly *and* measure them on different platforms. We found that the performance of different barrier alternatives changed significantly depending on the platform (out of order / in order, IA32/PPC) and also on whether the builds were built with profiling or not, etc. Changes to code like this (which is performance-critical and is important to other people) should be discussed first. Whether the particular ideas are ultimately deemed good or not, it is important to discuss them with others (and evaluate them) beforehand. Cheers, --Steve > aastore: > previously: the aastore would emit a call to checkstore and then a > call to the aastore barrier > now: a single aastore helper can inline both of these calls and > therefore we pay only 1 call. Another consequence of this is the > baseline compiler emits less code (which should make it faster). > > putfield/putstatic: > previously: the arguments to the barrier routines in MemoryManager > were in a different order to the values on the JVM's operand stack, to > call the barrier the parameters were shuffled > now: the order of operands on the barrier routines now match, we no > longer need to shuffle parameters losing around 2 instructions (long 4 > byte instructions) per baseline barrier call. ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Jikesrvm-core mailing list Jikesrvm-core@... https://lists.sourceforge.net/lists/listinfo/jikesrvm-core |
|
|
Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15318] rvmroot/trunk
by Steve Blackburn
::
Rate this Message:
On 04/02/2009, at 7:27 PM, Ian Rogers wrote:
RVM-743
I think you've misunderstood. a. There was a documented regression, RVM-743, which goes back to r15240 (a month ago), long before the habanero slowdown (which was at 15301, 5 days ago). r15240 had an unintended effect on space efficiency. You increased the heap size for compress by 1MB (r15255) but that did not fix the OOME's completely, which indicates that the bloat was at least 1MB. b. The OOME's on compress stopped abruptly with r15318. I started reading through r15318 to work out why it affected RVM-743 and I wondered whether you had been trying to fix RVM-743 in r15318. I was puzzled, so I asked :-) Apparently not.
Those of us who are working with barriers often find ourselves coding against the interface you've changed. I can say this because it happens that I'm doing so right now. It also happens that Daniel and Fil are doing completely unrelated work for new concurrent GC barriers that is also affected by this. --Steve ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Jikesrvm-core mailing list Jikesrvm-core@... https://lists.sourceforge.net/lists/listinfo/jikesrvm-core |
|
|
Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15318] rvmroot/trunk
by Ian Rogers (nabble)
::
Rate this Message:
2009/2/4 Steve Blackburn <Steve.Blackburn@...>:
> On 04/02/2009, at 7:27 PM, Ian Rogers wrote: > > In this case I was just trying to get to the bottom of the compress > > regression and was a bit baffled when it narrowed down to this commit. > > What is the compress regression? > > RVM-743 > > Even after reading through the commit I couldn't easily figure out why it > > "fixed" the compress regression. It disturbs me when performance changes > > significantly for no clear reason, so having some clue as to what's going on > > here would be helpful, and I was speculating that that was what Ian may have > > been trying to address (which is why I sought clarification). > > I've been trying to get the barrier code into shape but no one commit > should have moved performance back. I think the major issue is that > we've had a week or so of misleading performance results from > Habanero. > > I think you've misunderstood. > a. There was a documented regression, RVM-743, which goes back to r15240 (a > month ago), long before the habanero slowdown (which was at 15301, 5 days > ago). r15240 had an unintended effect on space efficiency. You increased > the heap size for compress by 1MB (r15255) but that did not fix the OOME's > completely, which indicates that the bloat was at least 1MB. So this doesn't make sense. r15240 changed an encoding of: MOV REG, [ESP+0] to MOV REG, [ESP] 4 bytes as apposed to 3 bytes. It also tried to reduce the code for accessing the stack so that rather than: if (VM.BuildFor32Addr) // do 32bit load from stack else // do 64bit load from stack we did a single call to a helper (that then contained the if-then-else). Whilst their would have been code associated with the helper routine it wouldn't equate to 1MB. > b. The OOME's on compress stopped abruptly with r15318. I started reading > through r15318 to work out why it affected RVM-743 and I wondered whether > you had been trying to fix RVM-743 in r15318. I was puzzled, so I asked :-) > Apparently not. For the tight GCs we're sporadically getting OOMEs on more benchmarks than just compress. The problem is that rather than throw an OOME to the application we should kill the compilation thread. Perhaps there should be a call into the VM to ask the VM release any memory it has, and then retry the application allocation before we throw the OOME. In the current thread model just using the Thread.stop logic would be enough to kill the compiler threads. Unfortunately I can't repeat RVM-743. > The issue with the barriers is that the changes amount to a change in an API > > which some people rely on heavily, so while it may make sense to change it, > > it really should be discussed first. > > I thought the MemoryManager API was analogous to RuntimeEntrypoints, > entry points for the compiler and not something that people should be > deliberately coding against. > > Those of us who are working with barriers often find ourselves coding > against the interface you've changed. I can say this because it happens > that I'm doing so right now. It also happens that Daniel and Fil are doing > completely unrelated work for new concurrent GC barriers that is also > affected by this. > --Steve I don't understand, why are people coding against an entry point for the compiler? The code this calls I can see. I have got significant speed up from code related to the changes to the Barrier code, but I am not releasing it yet (and it's specifically for work using BaseBase - although I've seen speed ups in the region of 3% for opt builds). I wanted to commit back changes to the API as the current API is inconsistent (in the case of aastore - the use of helper routines is to avoid problems associated with not inlining in the baseline compiler, calling 2 helpers is unnecessary and doubling the problem of not inlining) and sub-optimal (in the case of putfield/putstatic - every barrier was causing the stack to be reshuffled as parameters to the entry point method didn't match the operand stack - this looked like cruft from the initial Intel port, on PPC the values are passed through registers so the ordering is arbitrary, on Intel it is more expensive as we pass values through the stack and registers). Currently (I think this is a long standing issue) we are compiling barriers with the opt compiler in a sub-optimal manner, hence RVM-755. I propose fixing the compiler to handle this and Dave proposes an invasive change to MMTk. There is an associated patch to fix this, r15297, in the quarantine branch that it'd be nice to move to the trunk. The performance advantage will be minimal, but register pressure when we generate barriers will be reduced, as will the opt compiler overhead for a barrier. Ian ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Jikesrvm-core mailing list Jikesrvm-core@... https://lists.sourceforge.net/lists/listinfo/jikesrvm-core |
|
|
Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15318] rvmroot/trunk
by Steve Blackburn
::
Rate this Message:
Hi Ian,
On 04/02/2009, at 11:18 PM, Ian Rogers wrote: > > So this doesn't make sense. r15240 changed an encoding of: [...snip...] > we did a single call to a helper (that then contained the > if-then-else). Whilst their would have been code associated with the > helper routine it wouldn't equate to 1MB. Sure. The point was that something in that commit caused compress to reliably OOME whereas it had not before. Increasing the heap by 1MB did not resolve it. This says to me that something about that commit caused at least a 1MB increase in the memory pressure for compress. I have no idea why. My POV is that if we suddenly get a regression, we should try to understand why, hence RVM-743. >> b. The OOME's on compress stopped abruptly with r15318. I started >> reading >> through r15318 to work out why it affected RVM-743 and I wondered >> whether >> you had been trying to fix RVM-743 in r15318. I was puzzled, so I >> asked :-) >> Apparently not. > > For the tight GCs we're sporadically getting OOMEs on more benchmarks > than just compress. Sure. However, prior to the above commit we had not seen any on compress. > The problem is that rather than throw an OOME to > the application we should kill the compilation thread. Perhaps there > should be a call into the VM to ask the VM release any memory it has, > and then retry the application allocation before we throw the OOME. In > the current thread model just using the Thread.stop logic would be > enough to kill the compiler threads. That's fine. I agree we need to handle the OOME's better. However, it is orthogonal to the point I'm making. My point is that something in that commit increased the memory pressure on compress by at least 1MB, and that in and of itself should be a concern until we understand it. > Unfortunately I can't repeat RVM-743. Not sure what you mean. You saw the problem and you increased the heap size. Until you increased the heap size compress-GC3 was failing with an OOME 100% of the time (I believe it was 100%). > I don't understand, why are people coding against an entry point for > the compiler? The code this calls I can see. Because they are extending the semantics. In my case this is for arraylets. For Daniel and Fil for more general use barriers. > I have got significant > speed up from code related to the changes to the Barrier code, but I > am not releasing it yet (and it's specifically for work using BaseBase > - although I've seen speed ups in the region of 3% for opt builds). Wait. My question was: did you observe any performance gain for the changes you have already committed? If not, then you really need to clearly motivate the change properly before committing. > I propose fixing the compiler to handle this and Dave proposes an > invasive change to MMTk. Dave? What change are you proposing? --Steve ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Jikesrvm-core mailing list Jikesrvm-core@... https://lists.sourceforge.net/lists/listinfo/jikesrvm-core |
|
|
Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15318] rvmroot/trunk
by Ian Rogers (nabble)
::
Rate this Message:
2009/2/4 Steve Blackburn <Steve.Blackburn@...>:
> Hi Ian, > > On 04/02/2009, at 11:18 PM, Ian Rogers wrote: >> >> So this doesn't make sense. r15240 changed an encoding of: > > [...snip...] > >> we did a single call to a helper (that then contained the >> if-then-else). Whilst their would have been code associated with the >> helper routine it wouldn't equate to 1MB. > > Sure. The point was that something in that commit caused compress to > reliably OOME whereas it had not before. Increasing the heap by 1MB > did not resolve it. This says to me that something about that commit > caused at least a 1MB increase in the memory pressure for compress. > I have no idea why. My POV is that if we suddenly get a regression, > we should try to understand why, hence RVM-743. > >>> b. The OOME's on compress stopped abruptly with r15318. I started >>> reading >>> through r15318 to work out why it affected RVM-743 and I wondered >>> whether >>> you had been trying to fix RVM-743 in r15318. I was puzzled, so I >>> asked :-) >>> Apparently not. >> >> For the tight GCs we're sporadically getting OOMEs on more benchmarks >> than just compress. > > Sure. However, prior to the above commit we had not seen any on > compress. > >> The problem is that rather than throw an OOME to >> the application we should kill the compilation thread. Perhaps there >> should be a call into the VM to ask the VM release any memory it has, >> and then retry the application allocation before we throw the OOME. In >> the current thread model just using the Thread.stop logic would be >> enough to kill the compiler threads. > > That's fine. I agree we need to handle the OOME's better. > > However, it is orthogonal to the point I'm making. My point is that > something in that commit increased the memory pressure on compress by > at least 1MB, and that in and of itself should be a concern until we > understand it. > >> Unfortunately I can't repeat RVM-743. > > Not sure what you mean. You saw the problem and you increased the > heap size. Until you increased the heap size compress-GC3 was failing > with an OOME 100% of the time (I believe it was 100%). I mean that if I check out the RVM and repeatedly run compress with the smaller heap size I don't get OOMEs. The problem is something to do with the balance of habanero, the RVM and the adaptive optimization system. >> I don't understand, why are people coding against an entry point for >> the compiler? The code this calls I can see. > > Because they are extending the semantics. In my case this is for > arraylets. For Daniel and Fil for more general use barriers. Is there a JIRA for arraylets? In any case the code in question is now easier to maintain for arraylets as you don't need to do any hand coding (instead this is done in the helper routine) that is making use of existing magic code (which unfortunately needs porting for arraylets - but I couldn't save you that one). >> I have got significant >> speed up from code related to the changes to the Barrier code, but I >> am not releasing it yet (and it's specifically for work using BaseBase >> - although I've seen speed ups in the region of 3% for opt builds). > > Wait. My question was: did you observe any performance gain for the > changes you have already committed? > > If not, then you really need to clearly motivate the change properly > before committing. I think the performance reports are speaking for themselves. In general generating less code and smaller code is a good thing. >> I propose fixing the compiler to handle this and Dave proposes an >> invasive change to MMTk. > > Dave? What change are you proposing? > > --Steve It's probably worth following this up through JIRA: http://jira.codehaus.org/browse/RVM-755 Ian ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Jikesrvm-core mailing list Jikesrvm-core@... https://lists.sourceforge.net/lists/listinfo/jikesrvm-core |
|
|
Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15318] rvmroot/trunk
by David P Grove
::
Rate this Message:
Steve Blackburn <Steve.Blackburn@...> wrote on 02/04/2009 07:47:21 AM: |
| Free embeddable forum powered by Nabble | Forum Help |
