RFR: 8000818: SA constant pool need to reference to reference map after permgen removal

[Yumin Qi]

Serguei,

   You are right, here should use 0xffff which is for short.
   First we got a short from GetBytesXXX function, we assign it to int.  
When it is used, only lower 16 bits are used. To prevent it has invalid 
bits set in upper 16 bits, masking off them.
   Switch bytes, is for in case the index is a short number stored in 
method byte code. On X86, bytes needed to be switched to reflect the 
correct value as java conform.

   Thanks
   Yumin

On 10/17/2012 1:05 PM, serguei.spitsyn at oracle.com wrote:
> Hi Yumin,
>
> I have a question.
> ByteCodeRewriter.java:
> 65 return (short)cpool.objectToCPIndex(refIndex & 0xff);
>
>   Why the mask 0xff is used above?  The refIndex can be a short value, 
> right?
>   Otherwise, why would you need to swap bytes at the line 62 ? :
>     62 case 3: refIndex = 
> bytes.swapShort(method.getBytecodeShortArg(bci)); break;
>
> And I agree with David that one of these assignements seems to be 
> redundant:
>    58 int refIndex = method.getBytecodeByteArg(bci);
> 61 case 2: refIndex = method.getBytecodeByteArg(bci); break;
>
>
> Thanks,
> Serguei
>
>
> On 10/16/12 9:51 PM, Yumin Qi wrote:
>> Hi, all
>>
>>   May I have your codereview on
>>
>> http://cr.openjdk.java.net/~minqi/8000818/ 
>> <http://cr.openjdk.java.net/%7Eminqi/8000818/>
>>
>> 8000818: SA constant pool need to reference to reference map after 
>> permgen removal
>> Summary: After permgen removal, constant pool changed to put _ldc and 
>> _ldc_w (fast_ldc and fast_ldcw) index to reference map, no longer 
>> calculated via constant pool cache.
>> Also, there is a mistake in 6879063: SA should use hsdis. Bytes.swap 
>> should only check if the underlying platform is big endian  since 
>> java code follows big endian.  Revert it back to its orginal form, 
>> else it will fail  ClassDump.
>>
>> Reviewed-by:
>> Contributed-by: yumin.qi at oracle.com
>>
>>
>> Thanks
>> Yumin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20121017/479f7ac8/attachment-0001.html