RFR(10)(S): 8181503: Can't compile hotspot with c++11
Gerard Ziemski
gerard.ziemski at oracle.com
Tue Jun 13 19:59:21 UTC 2017
> 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?
cheers
More information about the hotspot-dev
mailing list