RFR [M] : 8087333, Optionally Pre-Generate the HotSpot Template Interpreter

[Bertrand Delsart]

Hi all,

This webrev is related to a closed JEP. Its main objective is to
support the template interpreter in highly secure contexts where
dynamically generated code is not allowed.

This will be pushed through hs-rt.

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

http://cr.openjdk.java.net/~bdelsart/8087333/webrev.00/webrev/

This is a forward port to 9 of a feature that was in our embedded 
workspace. That workspace was used to build both our regular embedded 
binaries and pregenerated-enabled ones. As such, the 8 changes were 
already mature and, even more important, did not lead to regressions on 
platforms not using them. Similarly, no regression has been noticed on 
the 9 forward and the changes pass JPRT (including the openJDK builds 
and tests).

The above webrev may not apply as is to jdk9/hs-rt since it comes on top 
of other CRs concurrently being reviewed (the JEP was split into smaller 
easier to review parts). The corresponding changesets are:
http://cr.openjdk.java.net/~bdelsart/8079473/
  "allow demangling to be optional in dll_address_to_function_name"
  (approved, not yet pushed)
http://cr.openjdk.java.net/~bdelsart/8081406/
  "cleanup and minor extensions of the debugging facilities in CodeStrings"
  (waiting for reviewers)
http://cr.openjdk.java.net/~bdelsart/8087133/
  "Improve sharing of native wrappers in SignatureHandlerLibrary"
  (waiting for reviewers)
http://cr.openjdk.java.net/~bdelsart/8030076
  "remove unused runtime related code"
  (waiting for reviewers)

Brief overview of the shared code changes for this webrev:

- Minimum changes in agent code to support CodeHeap subclasses,
   with different visitors, necessary for the pregenerated heap
   Latest version is generic, allowing to define different CodeHeap
   layouts for future extensions

   Validated with "search codebase" CLHSDB agent command, which
   correctly parses both the pregenerated and the regular heap.

- Build extension for the hotspot subtree, to support closed
   extensions
   * an extra generated 'extensions' directory
   * ability to compile the *.S files, forcing the preprocessor to
     be used before the assembler (used to convert pregenerated code
     to *.o files)
   * extra *.o files added into libjvm
   * ability to extend the content of vm.def

- Source code support for a new CodeCacheExtensions API, which
   allows to load a pregenerated template interpreter (+all
   stubs required for the interpreter to work). The same API
   is also used to pregenerate this code.

   See hotspot/src/share/vm/code/codeCacheExtensions_ext.hpp
   for a definition of that API. The default implementation in
   open performs nothing and inlining should prevent overheads.

   These are HotSpot internals only, not accessible to the
   end-user Java application.

Details of the shared source code changes, mostly additional calls 
allowing our closed extension to better control what happens during 
bootstrap:

- support for more than one CodeHeap (independently of
   -XX:+SegmentedCodeCache), including CodeHeap subclasses
   that have a different layout

- ability to rename a CodeBuffer (allowing to pass the name to
   SignatureHandlerLibrary::set_handler)

- ability to save/load all stubs generated during bootstrap,
   using CodeCacheExtensions::handle_<...> methods

- ability to avoid wasting away CodeHeap space (by optimizing
   the buffer sizes, avoiding to generate useless code, detecting which
   interpreter entries are impacted by JVMTI, ...)

- ability to install a list of pregenerated fast native
   signature handlers.

- ability, similarly to zero, to generate two interpreter loops,
   one highly optimized and one which supports JVMTI. The interface
   is in fact more flexible, allowing to have more than two such loops

- ability to prevent the CodeHeap from being executable

- a few complete_step calls to allow the extension mechanism to
   perform additional actions. This could be extended to plug-in
   other extensions during the bootstrap.

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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~