RFR (S): 7009641: Don't use CodeCache for allocations if it is already full

[Albert Noll]

Hi,

can I consider this as reviewed?

Best,
Albert

On 18.09.2013 15:33, Vitaly Davidovich wrote:
>
> Nice, looks good (not a Reviewer).
>
> Sent from my phone
>
> On Sep 18, 2013 1:06 AM, "Albert Noll" <albert.noll at oracle.com 
> <mailto:albert.noll at oracle.com>> wrote:
>
>     Hi Vitaly,
>
>     thanks, I missed that.
>     'num_vtable_chunks' does not seem to be read at any other
>     position, so I removed it.
>
>     Here is the updated webrev:
>     http://cr.openjdk.java.net/~anoll/7009641/webrev.01/
>     <http://cr.openjdk.java.net/%7Eanoll/7009641/webrev.01/>
>
>     Best,
>     Albert
>
>     On 18.09.2013 01:45, Vitaly Davidovich wrote:
>>
>>     Hi Albert,
>>
>>     In VtableStub::operator new, num_vtable_chunks is incremented
>>     first thing in the function.  Before your change, that seems fine
>>     since OOM would cause VM to exit.  But now that you return NULL,
>>     is it a problem if num_vtable_chunks is overstated?
>>
>>     Thanks
>>
>>     Sent from my phone
>>
>>     On Sep 17, 2013 1:44 PM, "Albert Noll" <albert.noll at oracle.com
>>     <mailto:albert.noll at oracle.com>> wrote:
>>
>>         Hi,
>>
>>         could I have reviews for this small patch?
>>
>>         bug: https://bugs.openjdk.java.net/browse/JDK-7009641
>>         webrev: http://cr.openjdk.java.net/~anoll/7009641/webrev.00/
>>         <http://cr.openjdk.java.net/%7Eanoll/7009641/webrev.00/>
>>
>>
>>
>>         Problem:
>>         If the code cache is full and we try to allocate vtable
>>         stubs, we have a crash although we could continue execution.
>>
>>         Solution:
>>         Since memory from the code cache can be allocated/released by
>>         multiple threads, the cleanest solution is to let the allocation
>>         in the code cache return NULL instead of failing the entire
>>         VM (for vtable stubs). If there is no memory left, no vtable
>>         stubs will
>>         be created and the IC is cleaned.
>>
>>         Many thanks in advance,
>>         Albert
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130919/76dd1a74/attachment-0001.html