RFR(10)(S): 8181503: Can't compile hotspot with c++11

[Kim Barrett]

> On Jun 13, 2017, at 3:59 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
> 
> 
>> On Jun 12, 2017, at 5:07 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> 
>> src/share/vm/utilities/vmError.hpp
>> 38   static uint         _id;              // Solaris/Linux signals: 0 - SIGRTMAX
>> 
>> I think changing the type of _id from int to uint is really not so
>> simple. There's a bit of a type mess in this area, with some functions
>> expecting or using int and others uint. _id is set from an int value.
>> It is passed to os::exception_name, which takes an int argument. The
>> windows implementation of that function immediately casts that
>> argument to a uint, but the posix implementation actually wants an int
>> value. OTOH, there are other places that expect or treat _id as a
>> uint. So the proposed change is really just rearranging the deck
>> chairs in that mess, and is not really much of an improvement.
>> I *think* using uint consistently throughout for this value could be
>> made to work, but I haven't completely worked through it.
> 
> Thanks Kim,
> 
> I didn’t see anywhere in the code the _id being compared using arithmetic (ex: “if (_id < 0)"), so I thought we were good using uint. Thanks for taking a closer look.
> 
> Would redefining the 3 troublesome enums from:
> 
> enum VMErrorType {
> INTERNAL_ERROR   = 0xe0000000,
> OOM_MALLOC_ERROR = 0xe0000001,
> OOM_MMAP_ERROR   = 0xe0000002
> };
> 
> to:
> 
> enum VMErrorType {
> INTERNAL_ERROR   = 0xe000000,
> OOM_MALLOC_ERROR = 0xe000001,
> OOM_MMAP_ERROR   = 0xe000002
> };
> 
> (i.e. removing one 0 from the defined values) be a good fix? SIGRTMAX is 64 (on Linux tested using “kill -l") so anything well above that would be user defined and therefore safe?

I *think* the current values were chosen for consistency with other Windows error codes.
There’s a table in os_windows, used by os::exception_name.  And then one would need
to deal with the question of a VMErrorType possibly having a different type on different
platforms.  As is, its representation type is forced to uint (for all of LP32, LP64, or LLP64),
but with that change of values it could be representationally either int or uint, and I’m pretty
sure different platforms make different choices in that regard.  So such a value change is
less simple than it might appear.

I’m not sure there is an easy, clean, and portable answer.  It looks like windows works best
here with uint, while for posix int would be preferred, so that regardless of which is used
there will be inconsistencies somewhere.