[9] RFR(S): 8029343: CodeCache::allocate increments '_number_of_blobs' even if allocation fails.

[Igor Veresov]

Alright, sounds like a plan.

igor

On May 6, 2014, at 5:49 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:

> Hi Igor,
> 
> On 06.05.2014 09:41, Igor Veresov wrote:
>> BufferBlob::operator new() doesn’t seem to be quite ready to see the NULL return. Could we put some error handling in there? Like a call to fatal() similar to other places. Otherwise looks good.
> 
> I would suggest we fix this together with [1]. NULL is already returned in case the allocation in the code cache fails. A call to fatal() is not appropriate here, because the sweeper may solve the problem by freeing space in the code cache.
> 
> Thanks,
> Tobias
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8022968
> 
>> igor
>> 
>> On May 6, 2014, at 12:27 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
>> 
>>> Hi,
>>> 
>>> please review the following patch for bug 8029343.
>>> 
>>> Problem:
>>> (1) CodeCache::allocate(...) increments _number_of_blobs before the actual allocation is performed. In case the allocation fails the counter is set to a wrong value.
>>> (2) The guarantee(size >= 0, ...) is incorrect. Calling CodeCache::allocate(...) with size = 0 leads to a segmentation fault. Further, a guarantee is too strong here. We can simply return NULL at runtime if the size is <= 0.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029343
>>> 
>>> Solution:
>>> (1) The increment is moved after the allocation.
>>> (2) An assert is used instead of the guarantee and NULL is returned if size <= 0.
>>> Webrev: http://cr.openjdk.java.net/~anoll/8029343/webrev.00/
>>> 
>>> Thanks,
>>> Tobias
>