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

Calvin Cheung calvin.cheung at oracle.com
Fri Jun 3 20:55:19 UTC 2016


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