harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: [DRLVM] build process improvement
Date Fri, 19 May 2006 14:52:41 GMT


Andrey Chernyshev wrote:
>> 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 :)

But certainly something that would be great to have, and there's no harm
in us aiming high :)

>
> 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
>
>

-- 
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


Mime
View raw message