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