<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 3, 2011, at 2:18 AM, Steve Poole wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div text="#000000" bgcolor="#ffffff">
On 30/04/11 00:05, Kelly O'Hair wrote:
<blockquote cite="mid:C1EB8205-AE42-4988-90E1-2AB89BC81797@oracle.com" type="cite"><br>
<div>
<div>On Apr 29, 2011, at 1:31 PM, Steve Poole wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div text="#000000" bgcolor="#ffffff"> On 26/04/11 15:54,
Kelly O'Hair wrote:
<blockquote cite="mid:52703127-B2C9-479E-A48B-810F200C49EA@oracle.com" type="cite"><br>
<div>
<div>On Apr 26, 2011, at 12:59 AM, Steve Poole wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family:
Times; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: 2; text-indent: 0px;
text-transform: none; white-space: normal; widows:
2; word-spacing: 0px; font-size: medium;">
<blockquote cite="mid:4FD1ED99-3447-4339-9C41-0897043BF8B6@oracle.com" type="cite">
<div>
<blockquote type="cite">
<div style="word-wrap: break-word;">
<div>
<pre style="white-space: pre-wrap;"><span class="Apple-style-span" style="font-family: Courier; font-size: 14px;">
* Allow for use of more portable build tools (compilers etc.) where possible</span></pre>
</div>
</div>
</blockquote>
</div>
</blockquote>
Can I add support for alternative JVM's ?</span></blockquote>
<br>
</div>
<div>Seems a bit out of scope to me.</div>
<div><br>
</div>
</blockquote>
Sorry, it was a bit of a flippant one liner, I owe you
more details. <br>
<br>
There are three usecases I see that require the OpenJDK
build process to be modified to accommodate:<br>
<br>
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. <br>
In this usecase it's possible that an simple interpreter
based JVM would be sufficient (ie Zero) (or even maybe a
cross compiling mode)</div>
</blockquote>
</div>
<div>
<blockquote type="cite">
<div text="#000000" bgcolor="#ffffff"> <br>
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. <br>
<font class="Apple-style-span"><font class="Apple-style-span" color="#144fae"><br>
</font></font></div>
</blockquote>
<blockquote type="cite">
<div text="#000000" bgcolor="#ffffff"> 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.<br>
<br>
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.<br>
</div>
</blockquote>
</div>
<br>
<div>I certainly can understand these needs, but it is still seems
beyond the initial scope of this project.</div>
<div>Maybe in a phase 2?</div>
</blockquote>
<br>
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?<br></div></blockquote><div><br></div>The contract or plumbing design between the JVM implementation and the JDK itself, in my opinion, belongs</div><div>with the JVM teams.</div><div>If there was a detailed specification with regards to how a JVM plumbs into a JDK, we could certainly use that</div><div>as part of the build process, Right now, it's just a list of files that get built by the hotspot repository build,</div><div>and placed in specific locations of the JDK install image. The export/import process defined in the makefiles</div><div>now, rather haphazardly, perhaps we can clean it up. But as I understand it, there is no formal spec here.</div><div>The actual native 'extern' symbol contracts between the JDK and JVM might be fairly well-defined, but</div><div>I'm not sure where, that's a deeper micro plumbing issue beyond building.</div><div><br></div><div>When the langtools, corba, jaxp, and jaxws sources were split out of the original j2se Teamware workspace,</div><div>I tried to define a simple delivery mechanism for these repositories, such that after they built, the files in their</div><div>"dist/" directory would be the delivery into the overall JDK image. A classes.zip and a src.zip in the simpliest</div><div>cases (this will likely become a bundle of modules in the jdk8 timeframe).</div><div>With hotspot, it wasn't as simple, and it currently constructs a sparse JDK-like install image for delivery into</div><div>the overall JDK build process. So we know what hotspot contributes to the JDK build, it's just not very well documented.</div><div>We can certainly try to clean that up and provide some documentation, assuming we can enforce updating the</div><div>documents when developers change things.</div><div><br></div><div>I was going to say that building hotspot does NOT require a Boot JDK to build, but I would be wrong, it does,</div><div>but I agree, it probably should not. As I recall, there is some XML processing, the stupid gamma launcher Queens use,</div><div>and building the extra java code for the Serviceability Agent and something else I forget the name of.</div><div>I would prefer that building hotspot not rely on a JDK at all, but I can't promise anything there.</div><div>As we get more into cross compilation for embedded building, we will need to address these issues cleanly, and I</div><div>suspect that what you want may fall out of that work.</div><div><br></div><div>So I would like to say that anything we do should be an improvement for J9 plugging in.</div><div>But predictions of the future have always been a problem for me, I'm trying Tarot cards, no luck so far.</div><div><br></div><div>-kto</div><div><br></div><div><blockquote type="cite"><div text="#000000" bgcolor="#ffffff">
<br>
<br>
<blockquote cite="mid:C1EB8205-AE42-4988-90E1-2AB89BC81797@oracle.com" type="cite">
<div><br>
</div>
<div>-kto</div>
<div><br>
</div>
</blockquote>
<br>
</div>
</blockquote></div><br></body></html>