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

Jiangli Zhou jiangli.zhou at oracle.com
Fri Jun 3 21:13:08 UTC 2016


Hi Calvin and Harold,

Thanks for the review!

Jiangli

> On Jun 3, 2016, at 1:59 PM, harold seigel <harold.seigel at oracle.com> wrote:
> 
> 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