harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [vm][classlib] hythr library
Date Mon, 13 Nov 2006 22:55:45 GMT
Andrey, Angela,

If I understood a problem correctly Alexey asked to make a developer's
life easier. It looks like now a developer should rebuild class
library, then to rebuild DRLVM each time he wants to check his class
library changes with DRLVM.

Can we simplify the procedure? For example, if I don't change DRLVM, I
shouldn't rebuild it each time to have correct files in jre/bin.
* This is more conventional.
* This allows people to use prebuilt DRLVM binaries.
* Prebuilt binaries minimize astonishment for a class library developer.

Alexey mentioned scripts as a quick solution. Is it possible to solve
this problem on a build script level? Or should we change a launcher
to reorder paths in LD_LIBRARY_PATH?

Your design discussion about long term solution is quite interesting
reading as well. Andrey said IBM should expose object layout. Let me
speculate on it a bit. I really don't have any knowledge on J9, so any
coincidence is not intentional.
* Imagine that J9 is able to work with Sun's class library that was
licensed by IBM from Sun for 10 years.
* Imagine that class library has functions which access objects
directly for performance reasons.

Taking these two statements together I don't think we should count on
exposing this object layout to the third party when this third party
is a competing Open Source community.

Thank you, Alexei


On 11/13/06, Angela Lin <alin.harmony@gmail.com> wrote:
> Hmm... Pre-Harmony, the IBM VM + classlib used the same thread
> library. When the classlib was contributed, I guess they forked the
> thread lib and changed the names of the functions. (I'm only
> speculating since I wasn't involved in that process.) hythr should be
> virtually identical to a subset of j9thr23.dll.
>
> I agree, the IBM VM + classlib should be using the same thread
> library. It shouldn't be hard to implement a redirector lib from hythr
> to j9thr.
>
> Would this obsolete the current classlib hythr implementation?
>
> Angela
>
> On 11/13/06, Andrey Chernyshev <a.y.chernyshev@gmail.com> wrote:
> > On 11/13/06, Alexey Petrenko <alexey.a.petrenko@gmail.com> wrote:
> > > Guys,
> > >
> > > is there any progress in making possible for IBM and DRL VM to use the
> > > same hythr library?
> >
> > I imagine they would have to share some more VM internals first, like
> > GC or object layout interface, before they can migrate to a common
> > threading library :)
> >
> > >
> > > It is really a pain now to run class library tests on DRLVM now. And
> > > nearly impossible to easy switch VMs by launcher command line
> > > parameters. Since class library builds IBM version of hythr library
> > > and rewrites it in jre/bin directory. So you need to copy this library
> >
> > What if just disable copying of the hythr.dll into the
> > deploy/jre/jdk/bin directory,
> > may be harmony-vme could be providing the one?
> >
> > > from DRL VM after each build. (Yes, I know how to write scripts :)
> > >
> > > If it is not possible for both VMs to use the same library probably we
> > > need to move these libraries to VM directories...
> >
> > +1.
> > Seems like we don't have any VM at the moment which would be really
> > using the hythr from classlib. Even IBM VME doesn't use the hythr. As
> > Tim wrote earlier, VME is using it's own threading library called
> > j9thr23 [1]. Does it differ a much from the hythr?
> >
> > Guess it might be favourable for the classlib + IBM VME stack as well
> > if it was using a single thread library. Would it be possible for VME
> > to include a straightforward hythr implementation which can delegate
> > hythread_* calls to the j9thr23?
> >
> > Thanks,
> > Andrey.
> >
> >
> > [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/%3c449B0751.8000209@gmail.com%3e
> >
> >
> > >
> > > SY, Alexey
> > >
> >
> >
> > --
> > Andrey Chernyshev
> > Intel Enterprise Solutions Software Division
> >
>


-- 
Thank you,
Alexei

Mime
View raw message