RFR (S): 7009641: Don't use CodeCache for allocations if it is already full
albert.noll at oracle.com
Wed Sep 18 22:09:06 PDT 2013
can I consider this as reviewed?
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:
> 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?
>> 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:
>> 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/
>> If the code cache is full and we try to allocate vtable
>> stubs, we have a crash although we could continue execution.
>> 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,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev