Revision1: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments

Gerard Ziemski gerard.ziemski at oracle.com
Tue May 26 17:15:22 UTC 2015


Thank you David for feedback. Please see my answers inline:

> -------- Forwarded Message --------
> Subject:	Re: Revision1: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments
> Date:	Tue, 26 May 2015 18:10:14 +1000
> From:	David Holmes<david.holmes at oracle.com>
> Organization:	Oracle Corporation
> To:	Gerard Ziemski<gerard.ziemski at oracle.com>,hotspot-dev at openjdk.java.net  Developers<hotspot-dev at openjdk.java.net>, Coleen Phillimore<coleen.phillimore at oracle.com>, Dmitry Dmitriev<dmitry.dmitriev at oracle.com>
> CC:	david.therkelsen at oracle.com, Thomas Stüfe<thomas.stuefe at gmail.com>, sangheon.kim<sangheon.kim at oracle.com>
>
> Hi Gerard,
>
> Progress review so I can send this out tonight - I still have to
> complete the review and double-check the responses to my previous comments.
>
> In globals.hpp, looking at all the "stack parameters" I expect to see a
> constraint function specified somewhere, but there isn't one. So now I'm
> a bit confused about how constraint functions are specified and used. If
> there has to be a relationship maintained between A, B and C, is the
> constraint function specified for all of them or none of them and simply
> executed as post argument processing step? Can you elaborate on when
> constraint functions may be used, and must be used, and how they are
> processed?
>
Constraints were not meant as a framework that imposes restrictions as to when and how to be used. It’s a helper framework that makes it easy for a developer to implement the kind of a constraint that a particular flag(s) demands. The decision as to what goes into it is left to the engineer responsible for a particular flag. The process of implementing constraints and ranges is still ongoing for many of the flags, and there are 3 subtasks tracking the issue. This webrev covers the introduction of the range/constraint framework and a subset of ranges/constraints implemented for those flags for which I was able to find existing ad hoc code or comments describing them.


> A few minor specific comments below:
>
> src/share/vm/c1/c1_globals.hpp
>
> Minor nit: Could you change:
>
>    range(1, NOT_LP64(K) LP64_ONLY(32*K))
>
> to
>
>    range(1, NOT_LP64(1*K) LP64_ONLY(32*K))
>
> or even:
>
>    range(1, NOT_LP64(1) LP64_ONLY(32) *K)
>
> I find the (K) by itself a little odd-looking.
>
Done.


> ---
>
> src/share/vm/runtime/globals.cpp
>
> +       if (withComments) {
> + #ifndef PRODUCT
> +         st->print("%s", _doc);
> + #endif
> +       }
>
> The ifdef should be around the whole if block (as it should for the
> existing code just before this change).

Done.


> ---
>
> src/share/vm/runtime/globals.hpp
>
> range(1, NOT_LP64(K) LP64_ONLY(M))
>
> 1*K and 1*M please.

Done.


> 1328   /* 8K is well beyond the reasonable HW cache line size, even with
> the   */\
>
> delete the end 'the'
>
> 1329   /* aggressive prefetching, while still leaving the room for
> segregating */\
>
> delete 'the’.

Done.


> Nit:
>
> 1981           range(ReferenceProcessor::DiscoveryPolicyMin,
>           \
> 1982           ReferenceProcessor::DiscoveryPolicyMax)
>           \
>
> 1982 should be indented so the Reference's line up.

Done.


> 2588
> range((intx)Arguments::get_min_number_of_compiler_threads(),      \
> 2589                 max_jint)
>           \
>
> Seems odd for a range to be expressed this way - seems more like a
> constraint. And get_min_number_of_compiler_threads doesn't really seem
> like an API for Arguments.
>
All ranges could be expressed as constraints. Ranges are just “trivial” constraint, which is most of them, and are supposed to be easy to use by the developer. get_min_number_of_compiler_threads() in this context of expressing a range is “constant”. I need that value; it used to be accessed from Arguments internally, so it did not need to be exposed before, but with the range/constraints factored out, I need to be able to get at the value.

I will be persenting webrev 2 shortly after I do build and some testing.


cheers



More information about the hotspot-dev mailing list