RFR [S] 8087133: Improve sharing of native wrappers in SignatureHandlerLibrary

Bertrand Delsart bertrand.delsart at oracle.com
Fri Jun 12 08:12:14 UTC 2015


Hi all,

This CR allows to reduce the number of generated fast native signature 
handlers, based on a CPU-dependent normalization of the signatures.

This will be pushed through hs-rt as part of a series of webrevs that 
implement a closed JEP which adds support for some pregenerated code, 
including these handlers.

https://bugs.openjdk.java.net/browse/JDK-8087133

http://cr.openjdk.java.net/~bdelsart/8087133/webrev.01/webrev/index.html

In the general use case, this only slightly reduces the number of 
generated native handlers, leading to a negligible code size gain. 
However, this sharing is more critical for our closed pregenerated code 
JEP. This is why the CPU-dependent normalization, which triggers the 
sharing, is currently only implemented on these closed platforms.

The webrev also fixes a minor debug issue that was discovered while 
validating the change on our closed platforms. 
-XX:+PrintSignatureHandlers did not work correctly because 
Interpreter::result_handler(return_type) is not always executable code. 
On some platforms, this is just a value used by the native wrappers 
instead of code jumped to.

Regards,

Bertrand
-- 
Bertrand Delsart,                     Grenoble Engineering Center
Oracle,         180 av. de l'Europe,          ZIRST de Montbonnot
38330 Montbonnot Saint Martin,                             FRANCE
bertrand.delsart at oracle.com             Phone : +33 4 76 18 81 23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of
the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


More information about the hotspot-runtime-dev mailing list