Project Proposal: Build Infrastructure Changes

Tue May 3 16:05:12 UTC 2011

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
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20110503/4472270a/attachment.htm>