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

Kim Barrett kim.barrett at oracle.com
Tue Jun 16 22:36:06 UTC 2015


On Jun 16, 2015, at 5:11 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
> 
> Coleen, Dmitry, David, Kim, Derek and Bengt,
> 
> I have create an incremental webrev as requested: http://cr.openjdk.java.net/~gziemski/8059557_rev2_to_rev3
> 
> As per suggestion from Kim and Coleen, I will not be spinning webrev4 unless there is a blocker in the code that we haven't found yet.
> 
> The plan right now is to check in rev3 and have https://bugs.openjdk.java.net/browse/JDK-8112746 track any follow up issues, which I already populated with comments from Coleen, Dmitry and Kim.
> 
> Can I have a final sign off on this webrev rev3 from all of you please?

A few more minor comments to add to the collection of followups, but
no showstoppers.  Looks good to me.

------------------------------------------------------------------------------
src/share/vm/runtime/commandLineFlagConstraintList.cpp
  41   // the "name" argument must be a string literal

[and others like it.]

That isn't strictly true. The real constraint is that the lifetime of
the string must be at least as long as the lifetime of the constraint
object, since the string is being captured without copying it. A
string literal is in practice the usual way that gets satisfied; we
don't have any directly constructed constraint objects that I know of,
or function calls for the names of the any options in the macros.

------------------------------------------------------------------------------
src/share/vm/runtime/commandLineFlagRangeList.hpp
  47   ~CommandLineFlagRange() {}

Destructor should be virtual, to prevent accidental slicing.
Similarly for ~CommandLineFlagConstraint.

[I think in current practice this doesn't matter, as the objects are
constructed, added to the associated list, and never deleted.]

------------------------------------------------------------------------------



More information about the hotspot-dev mailing list