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

[Vitaly Davidovich]

Nice, looks good (not a Reviewer).

Sent from my phone
On Sep 18, 2013 1:06 AM, "Albert Noll" <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/
>
> 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> 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/
>>
>>
>>
>> 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/08b7f720/attachment.html