Request for review:8020309:Remove InstanceKlass::_cached_class_file_len and record the length together with the cached class file bytes

[serguei.spitsyn at oracle.com]

Hi Jiangli,

I like the Ioi's sugestion.
It will help to avoid the manipulations with offsets that look as 
unnecessary complexity.

Thanks,
Serguei


On 7/10/13 6:39 PM, Jiangli Zhou wrote:
> Hi Ioi,
>
> That's good suggestion. Let me look into it.
>
> Thanks!
>
> Jiangli
>
> On 07/10/2013 05:53 PM, Ioi Lam wrote:
>> Hi Jiangli,
>>
>> I think it's better to move the logic of deciding the length into 
>> JVMTI. E.g., have something like
>>
>> struct JvmtiCachedClassFileData {
>>    int _length;
>>    unsigned char data[1];
>> };
>>
>> void 
>> instanceKlass::set_jvmti_cached_class_file_data(JvmtiCachedClassFileData 
>> *data);
>>
>> - Ioi
>>
>> On 07/10/2013 04:58 PM, Jiangli Zhou wrote:
>>> Hi,
>>>
>>> Please review the webrev for JDK-8020309 
>>> <https://jbs.oracle.com/bugs/browse/JDK-8020309>:
>>>
>>> http://cr.openjdk.java.net/~jiangli/8020309/webrev.00/
>>>
>>> The _cached_class_file_bytes and _cached_class_file_len are not 
>>> set/used if no jvmti agent is attached. The _cached_class_file_len 
>>> field can be eliminated and the file length can be recorded as part 
>>> of the cached class data in _cached_class_file_bytes for redefined 
>>> class. The above change allocates extra 4bytes when allocating 
>>> memory for cached class file and stores the length as the first 
>>> 4bytes and the file data as the rest. It saves 4 bytes per class. 
>>> For classes redefined, the memory usage is the same.
>>>
>>> Tested with following tests and JPRT:
>>>
>>>     jdk/test/java/lang/instrument
>>>     jdk/test/com/sun/jdi
>>>     nsk.jvmti
>>>     nsk.jdi
>>>     nsk.hprof
>>>
>>> Thanks,
>>> Jiangli
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130711/1b9a6587/attachment.html