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