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

Albert Noll albert.noll at oracle.com
Tue Sep 17 22:07:11 PDT 2013

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:


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 

More information about the hotspot-compiler-dev mailing list