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

[Coleen Phillimore]

Bertrand,

http://cr.openjdk.java.net/~bdelsart/8087333/webrev.00/webrev/src/share/vm/interpreter/interpreterRuntime.cpp.udiff.html

I like the name CodeCacheExtensions.

Did you test -XX:-UseFastSignatureHandlers with the pre-generated 
template interpreter?

+        if (! CodeCacheExtensions::support_dynamic_code()) {


Small nit, most people don't put a whitespace there.

http://cr.openjdk.java.net/~bdelsart/8087333/webrev.00/webrev/src/share/vm/memory/heap.hpp.udiff.html

-  bool  contains(const void* p) const            { return low_boundary() <= p && p < high(); }
-  void* find_start(void* p)     const;           // returns the block containing p or NULL
+  virtual bool  contains(const void* p) const            { return low_boundary() <= p && p < high(); }
+  virtual void* find_start(void* p)     const;           // returns the block containing p or NULL


indentation seems wrong in cdiffs anyway.

This looks really clean.   There are new directions to run 
remote-build-and-test, have you run this or the equivalent 
vm.quick.testlist against this change?

Thanks,
Coleen

On 6/12/15 1:30 PM, Bertrand Delsart wrote:
> 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.
>
>