<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 03/05/11 17:05, Kelly O'Hair wrote:
<blockquote
cite="mid:9A363E8C-755D-423F-9398-E273EE4557F5@oracle.com"
type="cite"><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>
</blockquote>
It would be part of the output of this project to scope the existing
relationship between JVM and class libs. <br>
<blockquote
cite="mid:9A363E8C-755D-423F-9398-E273EE4557F5@oracle.com"
type="cite">
<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>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:9A363E8C-755D-423F-9398-E273EE4557F5@oracle.com"
type="cite">
<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>
</blockquote>
<br>
</body>
</html>