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

[Albert Noll]

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/20130918/27361ed7/attachment-0001.html