RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int) method to be implemented

[Dmitrij Pochepko]

Hi,

connection is simple: MemoryPoolMXBean::getUsage()::getUsed() returns 
long. Also, -XX:CodeCacheSegmentSize and -XX:CodeCacheMinBlockLength 
returned as long, so, most operation uses long, and basically the only 
call using int is WB::allocateCodeBlob. So, that's more logical to have 
long parameter in allocateCodeBlob. An alternative is to make some 
surrogate with basically the same code in tests, while it might be 
needed in another tests, so, it seems like moving it to WhiteBox would 
be more logical.

Thanks,
Dmitrij
> David,
>
> initially, we wanted to change WB::allocateCodeBlob to take jlong w/o 
> truncating. for that we make CodeCache::allocate to take size_t 
> instead of int, however it leads to too many changes in the product. 
> And we were sure that all these changes are safe, so it was decided to 
> make changes as smaller as possible.
>
> what do you think about the version w/ check? smth like:
>> public long allocateCodeBlob(long size, int type) {
>>  int i = (int) size;
>>  if ((long)i != size) { throw new IAE(); }
>>  return allocateCodeBlob(i, type);
>> }
>
> 8065134 was filled by Dmitrij Pochepko, and it's needed for his tests 
> JMX tests for SegmentedCodeCache[1]. so I think he can enlighten us 
> about connection.
>
> Dima,
> could you please explain connection between beans and allocateCodeBlob?
>
> [1] 
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016336.html
>
> Thanks,
> Igor
>
> On 12/08/2014 05:09 AM, David Holmes wrote:
>> On 5/12/2014 10:37 PM, Tatiana Pivovarova wrote:
>>> Hi all,
>>>
>>> please review this new small patch
>>>
>>> bugid: https://bugs.openjdk.java.net/browse/JDK-8065134
>>> webrev:
>>> http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.02/
>>>
>>> Problem:
>>> Need WhiteBox::allocateCodeBlob(long, int), currently only
>>> WhiteBox::allocateCodeBlob(int, int) exist.
>>>
>>> I change previous fix to this new patch because this conversation [*]
>>>
>>> Solution:
>>>    public long allocateCodeBlob(long size, int type) {
>>>        return allocateCodeBlob((int) size, type);
>>>    }
>>
>> I still think this is a bad idea. The callsite needs to know, and show,
>> that the size it is passing will be truncated. And I still don't see a
>> connection between MX bean memory sizes and allocateCodeBlob.
>>
>> David
>>
>>
>>> Test: jprt
>>>
>>> [*]
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016316.html 
>>>
>>>
>>>
>>>
>>> Thanks,
>>> Tatiana