harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Chernyshev" <a.y.chernys...@gmail.com>
Subject Re: [DRLVM] build process improvement
Date Thu, 18 May 2006 17:17:12 GMT
On 5/18/06, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> Andrey Chernyshev wrote:
> >> We would not want to couple the classlib to a particular VM however. So
> >> far I have been thinking
> >> about the HDK from a classlib perspective, without considering the VM
> >> used. I imagined that any
> >> developer who used a classlib HDK would just grab a VM snapshot (or the
> >> IBM VME) and overlay
> >> that onto the classlib HDK in the same way we overlay the VME onto
> >> deploy now.
> >
> > Well, may be I'm missing some simple points here, but...
> > Is there any specific reason not to bundle a "Harmony VM" (let's
> > forget about DRLVM for now) into the HDK? Is this just a matter of
> > choice between SableVM, drlvm, e.t.c.?
> > I just thought it could be convenient for developers (as well as for
> > Harmony users) to take a complete workable JRE without an additional
> > need to combine something together.
>
> I agree it would be useful to have a complete jre available, but I
> wasn't sure
> how we would pick the VM to use when we potentially have 3/4 VMs
> (if DRLVM is accepted, and once the classlib adapter is completed)
> capable of
> running with Harmony classlib.

As for the DRLVM, it doesn't actually require any specific adapter for
Harmony class libraries except a small patch for MsgHelp and
URLClassLoader patch which is already included with JIRA-438.

One additional patch would be required to make it workable with the
most recent classlib version (at the time we preparing DRLVM, we were
just using classlib version taken at March 13). This isn't big as well
- just rename MsgHelp and former com.ibm.oti.vm.VM.java to the right
locations, and then update a bunch of building files to accommodate
the recent API contributions and migrate to 1.5 compiler. I can add
this to JIRA as well, but, I just thought it may make sense to see if
the DRLVM is accepted first.

>
> Perhaps we could just produce a jre for each VM once they are up and
> working?

Yes, I think this could be the choice, if we don't select some "default" one.

> I just thought that if we had separate classlib and a VM jre's which
> both contained
> a predefined and matching directory structure, then the step of
> unpacking them
> into the same directory to get them working is fairly straightforward.

That should work as well, at least for class libs. Actually I was
thinking of HDK containing the pre-compiled binaries for all modules,
not just the ones from the class libraries. VM developers would
probably want to be able to work on a single module as well, for ex.
JIT or GC. They wouldn't want to compile, for example, log4cxx or APR
each time they want to build VM, these binaries are also worth to be
the part of HDK.

Either it would result into a separate HDK's containing VM and
classlib modules, or we just can combine everything within a single
HDK (which seems to me just simpler).

Thanks,
Andrey.


>
> Regards,
> Oliver
>
> >
> > Thank you,
> > Andrey Chernyshev
> > Intel Middleware Products Division
> >
> > On 5/18/06, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> >>
> >>
> >> Mark Hindess wrote:
> >> > On 18 May 2006 at 14:36, "Alexey Petrenko"
> >> <alexey.a.petrenko@gmail.com>
> >> > wrote:
> >> >
> >> >> 2006/5/18, Mark Hindess <mark.hindess@googlemail.com>:
> >> >>
> >> >>> I was assuming that the HDK for the classlib would not contain
> >> >>> any VM specific artifacts.  If it did, which VM artifacts would
> >> >>> it contain SableVM, drlvm, etc. or all of them?  (Of course, the
> >> >>> classlib hdk will contain the VM stubs that the classlib build
uses
> >> >>> today.)
> >> >>>
> >> >> But we need to run the classlib on some machine.
> >> >>
> >> >
> >> > Of course.
> >> >
> >>
> >> We would not want to couple the classlib to a particular VM however. So
> >> far I have been thinking
> >> about the HDK from a classlib perspective, without considering the VM
> >> used. I imagined that any
> >> developer who used a classlib HDK would just grab a VM snapshot (or the
> >> IBM VME) and overlay
> >> that onto the classlib HDK in the same way we overlay the VME onto
> >> deploy now.
> >>
> >> I suggested in the "Supporting working on a single module?" thread
> >> (sorry, no link - it's not in the
> >> archives yet) that a Harmony VM could produce releases in a jre or jdk
> >> layout. This
> >> would allow a Classlib developer to grab an HDK and overlay the VM jre
> >> bundle onto it,
> >> but at the same time an actual Harmony runtime user could grab a
> >> classlib jdk/jre snapshot and
> >> combine it with the same VM.
> >>
> >> Regards,
> >> Oliver
> >>
> >> --
> >> Oliver Deakin
> >> IBM United Kingdom Limited
> >>
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> --
> Oliver Deakin
> IBM United Kingdom Limited
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message