On May 3, 2011, at 2:18 AM, Steve Poole wrote: > On 30/04/11 00:05, Kelly O'Hair wrote: >> >> >> On Apr 29, 2011, at 1:31 PM, Steve Poole wrote: >> >>> On 26/04/11 15:54, Kelly O'Hair wrote: >>>> >>>> >>>> On Apr 26, 2011, at 12:59 AM, Steve Poole wrote: >>>> >>>>>>> >>>>>>> * Allow for use of more portable build tools (compilers etc.) where >>>>>>> possible >>>>> Can I add support for alternative JVM's ? >>>> >>>> Seems a bit out of scope to me. >>>> >>> Sorry, it was a bit of a flippant one liner, I owe you more details. >>> >>> There are three usecases I see that require the OpenJDK build process to be >>> modified to accommodate: >>> >>> The first is bootstrapping a build. I'd like to be able to build OpenJDK >>> on a new platform without the need for a previous SDK build to be present. >>> In this usecase it's possible that an simple interpreter based JVM would be >>> sufficient (ie Zero) (or even maybe a cross compiling mode) >> >>> >>> The second is getting OpenJDK to build on a platform where a hotspot JVM >>> doesn't exist and may never exist. As you guess I'm thinking of IBM >>> platforms specifically. I'm don't expect to port Hotspot to AIX so I need >>> to be able to make the OpenJDK build work with J9. >>> >>> The third (a variant of the 2nd) is where another JVM vendor wants to get >>> OpenJDK working with their JVM - regardless of the availability of a >>> Hotspot JVM on the target platform. >>> >>> To be clear. I'm not suggesting that this project step up to defining the >>> interfaces between JVM and classes. This is simple pragmatics. The >>> Hotspot JVM is the starting point for the mould and I would expect to make >>> J9 (or any new JVM) fit into it as much as possible. However there will >>> be changes needed. These are mostly simple, like parameterising JVM >>> command line options, to the more complicated like separating out JVM >>> intrinsic classes such as String.java, Object.java, Thread.java etc so >>> that the right versions get build and packaged. >> >> I certainly can understand these needs, but it is still seems beyond the >> initial scope of this project. >> Maybe in a phase 2? > > Hmm, maybe doing all of them in one go may be a stretch :-) The 2nd usecase > is fundamental though to supporting IBM platforms, something you mentioned > you wanted to do. Is there any reason why realising that usecase is beyond > phase 1?
The contract or plumbing design between the JVM implementation and the JDK itself, in my opinion, belongs with the JVM teams. If there was a detailed specification with regards to how a JVM plumbs into a JDK, we could certainly use that as part of the build process, Right now, it's just a list of files that get built by the hotspot repository build, and placed in specific locations of the JDK install image. The export/import process defined in the makefiles now, rather haphazardly, perhaps we can clean it up. But as I understand it, there is no formal spec here. The actual native 'extern' symbol contracts between the JDK and JVM might be fairly well-defined, but I'm not sure where, that's a deeper micro plumbing issue beyond building. When the langtools, corba, jaxp, and jaxws sources were split out of the original j2se Teamware workspace, I tried to define a simple delivery mechanism for these repositories, such that after they built, the files in their "dist/" directory would be the delivery into the overall JDK image. A classes.zip and a src.zip in the simpliest cases (this will likely become a bundle of modules in the jdk8 timeframe). With hotspot, it wasn't as simple, and it currently constructs a sparse JDK-like install image for delivery into the overall JDK build process. So we know what hotspot contributes to the JDK build, it's just not very well documented. We can certainly try to clean that up and provide some documentation, assuming we can enforce updating the documents when developers change things. I was going to say that building hotspot does NOT require a Boot JDK to build, but I would be wrong, it does, but I agree, it probably should not. As I recall, there is some XML processing, the stupid gamma launcher Queens use, and building the extra java code for the Serviceability Agent and something else I forget the name of. I would prefer that building hotspot not rely on a JDK at all, but I can't promise anything there. As we get more into cross compilation for embedded building, we will need to address these issues cleanly, and I suspect that what you want may fall out of that work. So I would like to say that anything we do should be an improvement for J9 plugging in. But predictions of the future have always been a problem for me, I'm trying Tarot cards, no luck so far. -kto > > >> >> -kto >> >
