RFR(xs): 8199656: Make slow metaspace verifications switchable in debug builds

David Holmes david.holmes at oracle.com
Thu Mar 15 12:21:41 UTC 2018


On 15/03/2018 8:06 PM, Thomas Stüfe wrote:
> Hi David,
> 
> On Thu, Mar 15, 2018 at 10:31 AM, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Thomas,
> 
>     This seems fine to me.
> 
>     As it is a develop flag no CSR request is needed. (Under rules we
>     recently clarified with CSR group, but which have yet to be
>     documented somewhere on the wiki.)
> 
>     Thanks,
>     David
> 
> 
> Thanks for the review! Out of curiosity, would a diagnostic switch need 
> a CSR?

No. product & manageable (a variation of product) require a CSR request. 
Develop, diagnostic & experimental do not.

David

> Thomas
> 
> 
>     On 15/03/2018 5:09 PM, Thomas Stüfe wrote:
> 
>         Hi all,
> 
>         may I please have reviews for this small rfe:
> 
>         Bug: https://bugs.openjdk.java.net/browse/JDK-8199656
>         <https://bugs.openjdk.java.net/browse/JDK-8199656>
>         webrev:
>         http://cr.openjdk.java.net/~stuefe/webrevs/8199656-verifymetaspace-switch/webrev.00/webrev/
>         <http://cr.openjdk.java.net/~stuefe/webrevs/8199656-verifymetaspace-switch/webrev.00/webrev/>
> 
>         We have a number of useful metaspace verifications which are all
>         switched
>         off via a const bool in code. This change makes these verifications
>         switchable.
> 
>         Note: the switch is develop because all the verifications are
>         ASSERT only,
>         so it makes no sense to make it the switch diagnostic. If we
>         want the tests
>         in product builds too, we need to revise the test code.
> 
>         For the effect this has,
>         try ./hotspot/variant-server/libjvm/gtest/gtestLauncher.exe
>         -XX:-VerifyMetaspace -jdk:./images/jdk/
>         --gtest_filter=MetaspaceAllocationTest*. With verifications,
>         runtime almost
>         triples in fastdebug.
> 
>         Thanks and Kind Regards, Thomas
> 
> 


More information about the hotspot-runtime-dev mailing list