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


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?


More information about the hotspot-dev mailing list