FW: Porting OpenJDK 6 to Stratus OpenVOS on IA32 -- Endianness and the Direct-X-Buffer Classes

[Barnes, Richard]

We are looking for suggestions of how to get around an endianness
problem we have run into while porting Java. We have a very unusual
situation in which the jvm runs in little-endian mode (on an x86
platform), but the rest of our operating system and user code runs in
big-endian mode. Since there is no endian mode control on x86, our
compilers take care of endian differences (including gcc).
We decided to compile and run jvm as little-endian both for efficiency
and so we could use the existing i386 implementation as a base without
needing to change all hotspot code generation to deal with big-endian
memory. We believed that the JNI (as well as JVM interfaces) entails
sufficient opaqueness so that we could define them as being big-endian
and thus all jvm clients could run big-endian. For the most part, the
env pointer array is all that is affected.
This all works pretty well except for the Direct-X-Buffer classes which
want to know about the endianness of the underlying memory in order to
be most efficient. (Note: we never allow direct access to memory by
native code - the "critical" JNI interfaces always make a copy which is
big-endian). Direct-X-Buffer uses the native endianness information
derived by the Bits class via unsafe class methods which access memory
directly (without swaps in our case) and so thinks memory is
little-endian - which indeed it is for jvm code, but not for native code
interfacing via JNI. It then uses unsafe methods based on this knowledge
to access the buffer. Our first thoughts of how to deal with this was to
make the unsafe methods do the swaps of memory contents so as to be
consistent with the JNI from a native method's point of view This
resulted in the native endianness looking to be big-endian, and with
this change all tests in the nio suite passed.
But there are problems with this approach (other than just the matter of
efficiency). The assumption we made is that as long as memory is
consistently fetched and set by unsafe methods, it doesn't matter what
kind of transformation it undergoes as long as it's consistently
applied. Unfortunately, this is not the case, as we learned in the
ExternalizableBlockData test. Here we see the unsafe class being used to
set an object pointer in memory which is later accessed directly by the
generated interpreter code.
So it seems clear that we need to make the unsafe methods behave as
expected returning actual memory contents and deal with the
Direct-X-Buffer knowledge of endianness. We believe this situation is
most likely the first of its kind: that is where the jvm and its clients
are running with different endianness. However, we believe the design of
Direct-X-Buffer implementation has the flexibility to handle this
situation, but we're not sure of the best way to go about accomplishing
this. Simply forcing "native" endianness to big-endian is not the
answer.
In summary, what we're looking for is a simple and straightforward way
to get the Direct-X-Buffer classes out of the business of recognizing
endianness to promote efficient access. Do you have any ideas or
suggestions for how to do this?
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/20090630/b0bd0172/attachment.html