RFR: 8157189: 'iload_w' in shared class is not interpreted correctly

harold seigel harold.seigel at oracle.com
Fri Jun 3 20:59:28 UTC 2016


Looks good to me, also.

Thanks, Harold


On 6/3/2016 4:55 PM, Calvin Cheung wrote:
> Hi Jiangli,
>
> It looks good.
>
> thanks,
> Calvin
>
> On 6/2/16, 12:51 PM, Jiangli Zhou wrote:
>> Please review the fix for the ‘iload_w’ issue in shared class.
>>
>>    webrev: http://cr.openjdk.java.net/~jiangli/8157189/
>>    bug: https://bugs.openjdk.java.net/browse/JDK-8157189?filter=14921
>>
>> When CDS archives classes at dump time, it rewrites the ‘iload’ 
>> opcode to ‘nofast_iload’ in methods. At runtime, ‘nofast_iload’ 
>> bytecode instructions are interpreted the same as ‘iload’ 
>> instructions but without patching. The ‘iload’ opcode can be used in 
>> conjunction with the ‘wide’ instruction to access a local variable 
>> using a two-byte unsigned index. The CDS bytecode rewriter does not 
>> check if the current ‘iload’ is ‘iload_w’ during rewriting at dump 
>> time, and rewrites all ‘iload’ to ’nofast_iload'. That causes 
>> problems when the originally ‘iload_w’ is handled the same as the 
>> ‘iload’ at runtime. The fix is to only rewrite the opcode to the 
>> nofast version when it is not ‘iload_w’. As the VM does not patch the 
>> ‘iload_w’ instruction, so the fix doesn’t introduce any new writes to 
>> the shared class either.
>>
>> Thanks,
>> Jiangli



More information about the hotspot-runtime-dev mailing list