« Return to Thread: Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15318] rvmroot/trunk
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
> 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
« Return to Thread: Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15318] rvmroot/trunk
| Free embeddable forum powered by Nabble | Forum Help |
