From Richard.Barnes at stratus.com Thu Dec 11 12:59:37 2008 From: Richard.Barnes at stratus.com (Barnes, Richard) Date: Thu, 11 Dec 2008 15:59:37 -0500 Subject: FW: Porting OpenJDK 6 to Stratus OpenVOS on IA32 -- OpenVOS function pointers not the same as code pointers Message-ID: 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 From gbenson at redhat.com Mon Dec 15 01:16:28 2008 From: gbenson at redhat.com (Gary Benson) Date: Mon, 15 Dec 2008 09:16:28 +0000 Subject: FW: Porting OpenJDK 6 to Stratus OpenVOS on IA32 -- OpenVOS function pointers not the same as code pointers In-Reply-To: References: Message-ID: <20081215091628.GA3141@redhat.com> Hi Richard, I *think* Address(method, methodOopDesc::native_function_offset()) will return whatever your operating system things is a function pointer, ie it will return a pointer to the descriptor rather than the code pointer. That's certainly how it works on ppc64, which has a similar system. But just try it; if it crashes then maybe try it the other way ;) Cheers, Gary Barnes, Richard wrote: > 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 -- http://gbenson.net/ From Richard.Barnes at stratus.com Mon Dec 15 14:07:08 2008 From: Richard.Barnes at stratus.com (Barnes, Richard) Date: Mon, 15 Dec 2008 17:07:08 -0500 Subject: FW: Porting OpenJDK 6 to Stratus OpenVOS on IA32 -- OpenVOSfunction pointers not the same as code pointers In-Reply-To: 20081215091628.GA3141@redhat.com References: 20081215091628.GA3141@redhat.com Message-ID: Hi Gary, That is indeed the way I decided to proceed last Friday. I will be adding some code that will only run on our OS that will make sure that the value is treated as a function pointer. Thanks for your confirmation. Richard -----Original Message----- From: Gary Benson [mailto:gbenson at redhat.com] Sent: Monday, December 15, 2008 4:16 AM To: Barnes, Richard Cc: porters-dev at openjdk.java.net; Joe.Darcy at Sun.COM Subject: Re: FW: Porting OpenJDK 6 to Stratus OpenVOS on IA32 -- OpenVOSfunction pointers not the same as code pointers Hi Richard, I *think* Address(method, methodOopDesc::native_function_offset()) will return whatever your operating system things is a function pointer, ie it will return a pointer to the descriptor rather than the code pointer. That's certainly how it works on ppc64, which has a similar system. But just try it; if it crashes then maybe try it the other way ;) Cheers, Gary Barnes, Richard wrote: > 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 -- http://gbenson.net/