FW: Porting OpenJDK 6 to Stratus OpenVOS on IA32 -- OpenVOS function pointers not the same as code pointers
Richard.Barnes at stratus.com
Thu Dec 11 12:59:37 PST 2008
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?
Senior Technical Consultant
> 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
> Richard Barnes
> Senior Technical Consultant
> Stratus Technologies
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the porters-dev