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 Fri, 19 May 2006 14:47:42 GMT
> Eventually I imagine us having HDK, JDK and JRE bundles for
> the Classlib and each VM, and the developer/user can just pick and
> mix as they wish from that selection.

I agree, I think this is good idea.
Another option could be still to have a single HDK for VM, but have
different versions of components within it - various GC's, various
JIT's e,t,c. It will allow developers to compose the JRE they would
like with some more flexibility, just like if we had different
versions of the same module in classlib. This approach, however,
assumes a high level of modularity and compliance to some internal
API's (like OPEN?) across multiple VM's, which certainly isn't the
case at the moment :)

Thanks,
Andrey.


On 5/19/06, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> Andrey Chernyshev wrote:
> > 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).
>
> I personally prefer the idea of separate HDKs for VMs and classlib, although
> I dont feel strongly about it - it just makes the most sense to me.
> If someone wants to work exclusively on, say, classlib, they probably won't
> want to have to download extra hdk libraries for all of the VMs.
> In the case where someone works on both the Classlib and a VM (or
> more than one VM) if the HDKs have a uniform structure then they
> need only download the Classlib HDK and the VM HDK of their
> choice and unpack them in the same place.
>
> Eventually I imagine us having HDK, JDK and JRE bundles for
> the Classlib and each VM, and the developer/user can just pick and
> mix as they wish from that selection.
>
> Regards,
> Oliver
>
> >
> > 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
> >
> >
>
> --
> 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