-
Enhancement
-
Resolution: Fixed
-
P3
-
None
-
b31
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8014155 | 8 | Dean Long | P3 | Resolved | Fixed | b89 |
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-November/008888.html
Hi,
The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub
to update the IC with NativeMovConstReg. The current implementation assumes that
the load is always the first instruction in the stub. This is an artificial restriction. E.g.,
it might be useful to load the constant pool address (MachConstantBase) before the
IC load (as we do on PPC).
This change adds a constant specifying an offset from the beginning of the stub to
the IC load. The offset is platform specific and 0 on sparc and x86.
You can find the change here:
http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/
or in our ppc port:
http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33
Thank you and best regards,
Goetz
Hi,
The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub
to update the IC with NativeMovConstReg. The current implementation assumes that
the load is always the first instruction in the stub. This is an artificial restriction. E.g.,
it might be useful to load the constant pool address (MachConstantBase) before the
IC load (as we do on PPC).
This change adds a constant specifying an offset from the beginning of the stub to
the IC load. The offset is platform specific and 0 on sparc and x86.
You can find the change here:
http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/
or in our ppc port:
http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33
Thank you and best regards,
Goetz
- backported by
-
JDK-8014155 specify offset of IC load in java_to_interp stub
-
- Resolved
-