RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int) method to be implemented
David Holmes
david.holmes at oracle.com
Mon Dec 8 07:00:04 UTC 2014
Hi Igor,
On 8/12/2014 4:27 PM, Igor Ignatyev wrote:
> 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);
>> }
Yes that would be more acceptable. I've looked at the other tests and
see how the use of uint/x forces us to use Java longs. But still seems
to me that the tests are where we should be concerned that we haven't
overflowed the int. But I can live with the above safety check.
Thanks,
David
> 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
More information about the hotspot-dev
mailing list