Summary
-------

A new switch controls hs-err file verbosity.

Problem
-------

SAP added a lot of functionality to the crash reporter, and plans on continuing this work. However, we met some resistance and keep having reoccurring discussions. The reason is that there are conflicting goals for the error reporter:

One side prefers to keep crash reports brief and succinct, possibly at the expense of completeness, since support usually works with cores or debuggable repro cases.

The other side (we) would like to have the crash reports as complete as possible, to better support cases where these files are our sole information source.

Part of this discussion is whether to include possibly security relevant information (as one example, see discussion linked above about a proposal to add current user id). Again there are two usage scenarios: in cases where crash reports are getting posted verbatim in forums and bug reports one should be discreet. Where error reports are handled through secure channels and all parties are covered by support contracts, this discretion is not needed.

(For completeness sake, note that crash reports may always contain security relevant information, since they include register content and memory portions dumped.)

See also prior discussion: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-October/034505.html

Solution
--------

A switch could control inclusion of information into the hs-err file which is either considered too extensive, too security relevant, or both. 

Name proposal: "-XX:+-ExtensiveErrorReports", 

Which information in particular is controlled can then be decided on a case by case base when reviewing hs-err file additions.

The switch should be false by default, to keep error reports small in the stock product OpenJDK. It should be true in !product.

The switch should not affect jcmd VM.info.


Specification
-------------

    --- a/src/hotspot/share/runtime/globals.hpp     Mon Oct 08 13:25:39 2018 +0800
    +++ b/src/hotspot/share/runtime/globals.hpp     Mon Oct 08 12:03:39 2018 +0200
    @@ -2604,7 +2604,12 @@
               "Start flight recording with options"))                           \
                                                                                 \
       experimental(bool, UseFastUnorderedTimeStamps, false,                     \
    -          "Use platform unstable time where supported for timestamps only")
    +          "Use platform unstable time where supported for timestamps only") \
    +
    +  product(bool, ExtensiveErrorReports, PRODUCT_ONLY(false) NOT_PRODUCT(true), \
    +                 "Error reports include extensive information")               \
    +
    
     #define VM_FLAGS(develop,                                                   \
                      develop_pd,                                                \



Notes
-----

The error output controlled by this flag will be intermingled with the existing, unconditional output. However, setting this switch to true should not endanger existing error reporting steps (so, should not degrade the error reporting as a whole). 
Therefore, only full steps shall be protected by this switch - since every error reporting step runs under its own secondary error protection, that means that even if an extended step crashes, the subsequent steps - extended or not - will continue to work.

Code example:

      STEP("printing type of error")
      ....
      STEP("Cool extended feature producing lengthy output")
        if (ExtensiveErrorReports) {
    	... bla
        }

      STEP("printing exception/signal name")

 
But not like this:

      STEP("printing type of error")
      
          switch(static_cast<unsigned int>(_id)) {
             case OOM_MALLOC_ERROR:
             case OOM_MMAP_ERROR:
             if (ExtensiveErrorReports) {
    	           ... bla
             }
    
      STEP("printing exception/signal name")