Project Proposal: Build Infrastructure Changes

[Steve Poole]

On 03/05/11 17:05, Kelly O'Hair wrote:
>
> 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.
It would be part of the output of this project to scope the existing 
relationship between JVM and class libs.
>
> 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.

Given your timeframe Kelly, I'd suggest that we keep my usecases on file 
for  phase 2 and when the JDK8 feature gate opens I'll raise them there too.

>
> -kto
>
>>
>>
>>>
>>> -kto
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20110506/0a9a2eab/attachment.htm>