FW: Porting OpenJDK 6 to Stratus OpenVOS on IA32 -- OpenVOS function pointers not the same as code pointers

[Barnes, Richard]

One of the problems we have run into is that on most platforms a
function pointer contains the address of the entrypoint of the function.
That is, it is literally a pointer to the code.  With OpenVOS, like on
PA-RISC and IA64, a function pointer is a pointer to a two-word
descriptor -- one word pointing to the code and the other pointing to
data (think of this as a pointer to the global offset table or a pointer
to thread-local storage).  

The HotSpot code we have seen does not seem to be prepared for this
difference in what a function pointer is.  Consider the macros
CAST_FROM_FN_PTR and CAST_TO_FN_PTR in
src/share/vm/utilities/globalDefinitions.hpp, where it is obvious that a
function pointer is supposed to be a direct pointer to the entry point.
This is causing us confusion in what we might have to do to make native
calls work, such as in src/cpu/i486//vm/interpreter_i486.cpp's
InterpreterGenerator::generate_native_entry() method.  What we do not
know is whether Address(method, methodOopDesc::native_function_offset())
is going to return a function pointer or a pointer to the code.  While
this wouldn't matter for most platforms, it does matter for ours.

Does anybody have any experience with this kind of problem?

Thanks,

Richard Barnes
Senior Technical Consultant
Stratus Technologies

> ______________________________________________ 
> From: 	Barnes, Richard  
> Sent:	Friday, September 12, 2008 4:31 PM
> To:	'porters-dev at openjdk.java.net'
> Cc:	'Joe.Darcy at Sun.COM'; Richard Barnes
> Subject:	Porting OpenJDK 6 to Stratus OpenVOS on IA32
> 
> I am part of a small team at Stratus Technologies that is planning to
> port OpenJDK6 to its proprietary OpenVOS operating system running on
> IA32.  What makes this interesting and unusual is that even though we
> are targeting a little-endian chip, for compatibility reasons OpenVOS
> must present a big-endian environment to its users, so that gcc and
> g++, as well as native OpenVOS compilers, produce code that makes IA32
> appear to be big-endian at the source level.  The internals of OpenVOS
> are quite different from the internals of Unix, but we have added a
> POSIX.1 API to our operating system in recent years, which should help
> to make this project possible.  The runtime conventions are close to
> those of Unix on IA32, with the exception of endianness and some
> register usage, but that should not be insurmountable.
> 
> When I first sent mail to jdk-6.dev, Joe Darcy of Sun suggested that
> we check in with this group for community advice.
> 
> For these reasons, we hope to have our project accepted to join
> OpenJDK.
> 
> Thanks,
> 
> Richard Barnes
> Senior Technical Consultant
> Stratus Technologies
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20081211/c78a2d45/attachment.html