Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15318] rvmroot/trunk

> 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 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.