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

[Bertrand Delsart]

Thanks Coleen,

Comments inlined. Will send the updated webrevs in another mail.

On 22/06/2015 22:49, Coleen Phillimore wrote:
>
> 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?

Yes, some of my target platforms use the fast signature handlers and 
others do not :-)

>
> +        if (! CodeCacheExtensions::support_dynamic_code()) {
>
>
> Small nit, most people don't put a whitespace there.

Mea culpa. I had fixed that for the code you had pre-reviewed but I 
forgot about it for the code I added after. I'm part of those who 
automatically add a whitespace in that case to be sure the '!' is easy 
to notice :-(

I've made another pass over my changes to remove it in a few locations.

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

Realigned the lines I had modified.

> 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?

Yes. There are still issues around RBT and cross-compilation but I 
managed to run lot of tests both with and without the pregenerated 
interpreter.

Will do one more pass before the push, focusing on the non-pregenerated 
case so as to avoid regressions (using RBT for the platforms it supports).

Regards,

Bertrand.

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


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