From harmony-dev-return-9799-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Thu Jul 06 14:40:13 2006
Return-Path:
Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org
Received: (qmail 95049 invoked from network); 6 Jul 2006 14:40:12 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
by minotaur.apache.org with SMTP; 6 Jul 2006 14:40:12 -0000
Received: (qmail 2589 invoked by uid 500); 6 Jul 2006 14:40:09 -0000
Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org
Received: (qmail 2548 invoked by uid 500); 6 Jul 2006 14:40:09 -0000
Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: harmony-dev@incubator.apache.org
Delivered-To: mailing list harmony-dev@incubator.apache.org
Received: (qmail 2537 invoked by uid 99); 6 Jul 2006 14:40:09 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Jul 2006 07:40:09 -0700
X-ASF-Spam-Status: No, hits=1.4 required=10.0
tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: 64.74.244.71 is neither permitted nor denied by domain of geir@pobox.com)
Received: from [64.74.244.71] (HELO chi.mobile-health-diary.com) (64.74.244.71)
by apache.org (qpsmtpd/0.29) with SMTP; Thu, 06 Jul 2006 07:40:08 -0700
Received: (qmail 7093 invoked from network); 6 Jul 2006 14:39:45 -0000
Received: from ool-43560edb.dyn.optonline.net (HELO ?192.168.1.102?) (geir@67.86.14.219)
by b014.internal.mobile-health-diary.com with SMTP; 6 Jul 2006 14:39:45 -0000
Message-ID: <44AD20B1.9040408@pobox.com>
Date: Thu, 06 Jul 2006 10:39:45 -0400
From: Geir Magnusson Jr
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] Removing classlib-related tasks from VM build (was Doing
the minimum to support Java 5 classfiles)
References: <6928c5160607040738n7d8f1aa0h1d7b924d1c8ec8c@mail.gmail.com> <44AA9CC2.50403@pobox.com> <6928c5160607041046k6cdbcc44x65a6f4007ca574a5@mail.gmail.com>
In-Reply-To: <6928c5160607041046k6cdbcc44x65a6f4007ca574a5@mail.gmail.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N
Andrey Chernyshev wrote:
> On 7/4/06, Geir Magnusson Jr wrote:
>>
>>
>> Andrey Chernyshev wrote:
>> >> 4) Change the drlvm build so that its deploy tree layout has no
>> classlib
>> >> files in it. So we can do ...
>> >
>> > As a first step, I suggest that we make drlvm build completely free
>> > from the classlib-related tasks and files, this may help to avoid
>> > further confusion.
>>
>> I don't quite see what you mean. We need to use things from classlib to
>> build, like headers.
>
> I have created HARMONY-753 to illustrate what I mean :)
> Some of the things, like icu libraries, are copied twice at the moment -
> one time along with classlib binaries "bulk copy" (target
> "deploy.copy_classlib") and once more with the
> make/components/extra/icu4c.xml for example.
> I'm just suggesting to remove those tasks which are obsoleted by the
> fact that
> we are now using the complete classlib binaries.
Great. Got it.
>
>>
>> > For example, it doesn't have to copy things like
>> > icu, seralizer, xalan e.t.c. - they are already taken from pre-built
>> > class libraries.
>>
>> When you say "taken from pre-built class libraries" do you mean
>> "pre-build libraries"?
>>
>> Yes, we don't have to copy those - we really should organize a top level
>> dependency tree. I think I posted a note summarizing where we were last
>> week.
>>
>> > If there are no objections, I'm going to submit a
>> > patch which will remove some of that stuff from vm build.
>> >
>> > As a last step, one would remove the copying of the classlib binaries
>> > (e.g. deploy.copy_classlib) after we have a top-level build in place.
>>
>> I think I know what you mean, but I think that we still want this
>> option, so that someone could remain working in the drlvm directory.
>> IOW, there's no harm leaving it, and the top level build will just tell
>> drlvm to build itself into a canonical tree for copying by the top
>> level, and finding classlib is up to the top level builder.
>>
>> Note to self - we'll need to pass the location of the classlib to the
>> drlvm as a parameter with a top-level builder...
>
> I believe CLASSLIB_HOME env. variable can be used for that, right?
> One note - it currently used to point to the CLASSLIB root in a source
> tree, but may be it makes sense to have it pointing directly to the
> classib binaries.
We do need header files.
>
> BTW: drlvm build has a built-in machinery to get the resources from
> Internet. Do you think it may make sense to teach it to get the
> classlib binaries snapshots from the web site?
NO!
> I think
> remote.CLASSLIB.archive variable in win/lnx.properties can be used
> for that purpose, we only need to specify there the binaries location
> instead of source tree url.
No. You should be able to go get it yourself, unpack somewhere, and
point the variable.
>
> One of the issues here is that VM may not always work with the latest
> class libraries, hence hardcoding of the specific classlib snapshot
> URL/version in *.properties may be helpful (in the past SVN revision
> was used for that purpose).
Right
geir
>
> Thanks,
> Andrey.
>
>
>>
>> geir
>>
>>
>> >
>> > Thanks,
>> > Andrey.
>> >
>> >
>> > On 6/23/06, Mark Hindess wrote:
>> >>
>> >> On 23 June 2006 at 17:10, Tim Ellison wrote:
>> >> > Rana Dasgupta wrote:
>> >> > > On 6/23/06, Geir Magnusson Jr wrote:
>> >> > >> >>Pavel Pervov wrote:
>> >> > >> >> Geir,
>> >> > >> >>
>> >> > >> >> What's the first thing we do?
>> >> > >> >> I'd suggest switching the build to 1.5.
>> >> > >> >>
>> >> > >> >> The rest will come shortly :)
>> >> > >>
>> >> > >> >Now that's a plan! :)
>> >> > >
>> >> > >
>> >> > > Hi Geir,
>> >> > > Actually what Pavel says makes sense. Not sure what plan we need.
>> >> We could
>> >> > > do it either way. We can make some changes to the class structure,
>> >> loader,
>> >> > > and the jit/interpreter, and submit a couple of patches. It is not
>> >> the
>> >> > > "huge" patch that you have mentioned .. 7-8 files or so. Or we can
>> >> switch
>> >> > > the build first. This will break drlvm for a short time, and we
>> can
>> >> > > submit a
>> >> > > couple of bug fixes to get it going again. This way, we will just
>> >> add the
>> >> > > minimum needed for removing the compiler hack. Whatever way you
>> >> think makes
>> >> > > sense.
>> >> > > However, you started this thread with saying "no patch over the
>> >> wall"
>> >> > > and making this "learning exercise about DRLVM". Where are you
>> >> going with
>> >> > > this? Do you want to actually enumerate/discuss which source files
>> >> need to
>> >> > > change and in what way, on this thread so that more people can
>> >> participate?
>> >> > >
>> >> > > Marginally confused :-)
>> >> > > Rana
>> >> >
>> >> > Just for the record, my goal was to avoid 'moving the goalposts' for
>> >> > drlvm to integrate with the classlib and run the tests, apps, etc.
>> >> >
>> >> > If consensus here is that moving to 5.0 (and thereby delaying that
>> >> goal)
>> >> > is more desirable then I'm happy to go along with it, though I'm
>> >> keen to
>> >> > get the entire end-to-end story working soonest.
>> >> >
>> >> > Regards,
>> >> > Tim
>> >>
>> >> My feeling at the moment is that although drlvm and classlib are
>> working
>> >> together[0], it is evident[1] that things are not really integrated.
>> >> I would prefer to see "real integration" before we break[0] things by
>> >> moving to 5.0.
>> >>
>> >> As Geir pointed out recently, we are not just a Class library project,
>> >> so perhaps a change of focus is warranted? Perhaps if we can agree a
>> >> set of prerequisite goals (involving our JVMs) for moving to 5.0,
>> we can
>> >> ... err ... encourage this change of focus?
>> >>
>> >> My prerequisite goals would include things like:
>> >>
>> >> 1) Fix the (reasonable) 'hacks' that help us get this far with drlvm
>> >> integration - e.g. the static libhyprt.a for instance.[2]
>> >>
>> >> 2) Implement enough of the classlibadapter kernel classes such that
>> >> JCHEVM will run 'ant rebuild' in classlib[3]. We have some difficult
>> >> problems (thread attach) but there is also a lot of low hanging
>> fruit in
>> >> terms of missing or incomplete methods.
>> >>
>> >> 3) Get drlvm loading with the Harmony launcher from Classlib so we
>> >> can have both drlvm and IBM VME around for testing. I think this is
>> >> important because it will make it easier for people to test with
>> either
>> >> JVM.
>> >>
>> >> 4) Change the drlvm build so that its deploy tree layout has no
>> classlib
>> >> files in it. So we can do ...
>> >>
>> >> 5) Create the top-level build that can combine the trimmed drlvm
>> deploy
>> >> tree and the classlib deploy tree to produce a working jdk. (In much
>> >> the same way that we currently combine the classlib and IBM VME.)
>> >>
>> >> 6) Pull out shared dependencies to top-level so we only need one copy.
>> >>
>> >>
>> >> At the moment, I think moving to 5.0 would increase the divide between
>> >> the JVMs and Classlib.
>> >>
>> >> In the meantime there is still plenty of work to do for those that,
>> for
>> >> whatever reasons, don't find these tasks exciting enough - for
>> instance,
>> >> the missing java.lang.Character/java.lang.Math methods[4].
>> >>
>> >> Regards,
>> >> Mark.
>> >>
>> >> [0] Thanks Geir!
>> >>
>> >> [1] http://issues.apache.org/jira/browse/HARMONY-651
>> >>
>> >> [2] This isn't a criticism; I think these hacks can be justified.
>> >>
>> >> [3] I tried this the other day. It got to the second (non-comment)
>> line
>> >> of the first ant script before crashing because
>> >> ClassLoader.getResources()
>> >> isn't implemented yet.
>> >>
>> >> [4]
>> >>
>> http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html#pkg_java_lang
>>
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>>
>>
>
>
---------------------------------------------------------------------
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