Recent HotSpot changes in OpenJDK break Mac OS X

[Greg Lewis]

G'day all,

I'm working on the BSD port of OpenJDK and we recently merged in HotSpot
changes that have broken the build on Mac OS X.

The breakage looks like this:

/Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/interp_masm_x86_32.hpp:
In member function 'void InterpreterMacroAssembler::empty_expression_stack()':
/Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/interp_masm_x86_32.hpp:123:
error: call of overloaded 'movptr(Address, int)' is ambiguous
/Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2010:
note: candidates are: void MacroAssembler::movptr(Address, intptr_t)
/Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2012:
note:                 void MacroAssembler::movptr(Address, RegisterImpl*)
make[6]: *** [incls/_precompiled.incl.gch] Error 1

The guilty line of code in interp_masm_x86_32.hpp is this one:

      // NULL last_sp until next java call
      movptr(Address(rbp, frame::interpreter_frame_last_sp_offset * wordSize), (int32_t)NULL_WORD);

There are many other similar instances though, thats just the first one the
compiler encounters.

The prototypes in assember_x86.hpp are:

  void movptr(Address dst, intptr_t src);
  void movptr(Address dst, Register src);

Note that Mac OS X is not LP64, so the additional prototype for movptr
that takes an int32_t as the second parameter doesn't get defined (and it
wouldn't be helpful anyway since that definition is specifically for 64 bit
x86 OSes).

The code is basically relying on int32_t and intptr_t being typedef'ed to
the same thing on 32 bit platforms.  However, there is no language standard
I'm aware of that guarantees this.  On FreeBSD and Linux they are both
typedef'ed to an int, so this works.  I suspect the same is true on Solaris
although I haven't got a box I can check that on.  However, on Mac OS X
int32_t is typedef'ed as an int and intptr_t is typedef'ed as a long, hence
the above error.

This could be "fixed" with a Mac OS X specific definition that takes an
int32_t, but thats just papering over the broken assumption in the code.
I'd also like to avoid littering the code with #ifdef's that call the
int32_t version on LP64 and the intptr_t version otherwise.  Another way
would be something like this:

#ifdef _LP64
#define 32BIT_MOVPTR_CAST_TYPE int32_t
#else
#define 32BIT_MOVPTR_CAST_TYPE intptr_t
#endif

and then cast to (32BIT_MOVPTR_CAST_TYPE).  That still seems hacky though,
and introduces a lot of gratuitous changes into the BSD port which will
make merging harder.

Can anyone think of a more general solution that doesn't undo the merge of
the 32 and 64 bit code that appears to be responsible for this?

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org