8146115 - Improve docker container detection and resource configuration usage

[John Rose]

On Sep 27, 2017, at 1:22 PM, Bob Vandette <bob.vandette at oracle.com> wrote:

> I don’t have a problem with following the approved style.

Of course!  For the record, I certainly didn't intend to imply
any such problems.  My previous note was perhaps short
enough to carry an abrupt tone.  I think I wrote it on my phone.
Sorry.  :-)

I'm going to take this opportunity to expand on my reasoning,
for the record.  I'll also address your counterexamples.

So, I wrote the style guide for Hotspot to help preserve some
pleasing (at least, useful) regularities in the style of the code base.
The guide is successful (at least, partly) if it gives a clear nudge
towards a reasonable norm we can all share.

Under the assumption that judgment and taste are important
in our creative activity of software engineering, the style guide
states clearly that there can always be reasons to depart from the
rules.  That makes it relatively weak as a process component, and
that is intentional.  It is guidance not mandate, and as such dependent
on everyone's judgment and taste.

> Since I am more or less extending the os class, I followed os.hpp’s lead.   

This argument ("I'm modifying an API where an alternative style
is the local norm.") is warmly supported by the style guide.  See:

  https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#StyleGuide-Counterexamples

Some details: os.hpp has 900 LOC and a crude grep shows about
40 nullary non-boolean access methods plus a non-grepped
number of non-nullary access methods.

$ grep ' static .*( *)' os.hpp | grep -v 'static *void *[^*]' | grep -v 'static *bool'

Of these nine have "get_" pattern in their names.  So it's a
mixed bag.  Choosing how to add new names is not an exact
science, but I'd say there is a "tilt" here towards avoiding
"get_", but not a decisive one.  Is there a local convention
or just blind bit-evolution?  I think it's probably just evolution.
But I won't be upset if someone points out a reason for
some of those "get_" names.

Also, Paul's bug for un-mixing some of the various bags is
good as a low-frequency cleanup activity.  When he calls for
review, folks can take a look and give reasons why local conventions
are important and should not be "cleaned up".  If we want
to agree to leave things as they are, for some durable reason,
we can capture an explanatory comment and move on.
We might even decide, "please don't ever change this bit
because it will cause a maintenance burden", in which case
that too should be recorded clearly.

I hope this helps.

— John