[vm][classlib] hythr library

[Alexey Petrenko <al...@gmail.com>]

Guys,

is there any progress in making possible for IBM and DRL VM to use the
same hythr 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
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...

SY, Alexey

Re: [vm][classlib] hythr library

[Alexey Petrenko <al...@gmail.com>]

2006/11/14, Alexei Fedotov <al...@gmail.com>:
> Andrey, Angela,
>
> If I understood a problem correctly Alexey asked to make a developer's
> life easier.
Yes :)

> 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.
No :)
He should not but he could. That's an another solution:
1. Go to classlib
2. Build it
3. Go to DRL VM
4. Build it (DRL VM copies classlib to internal deploy directory while build)
5. Go to classlib
6. Run the tests, pointing to DRL VM internal deploy directory

> 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.
The easiest way to achieve this is to copy DRL VM to deploy directory
of class library and make it possible for IBM VME and DRL VM to work
in one deploy directory.
That's what I'm talking about.

Another big reason for this solution is to give Harmony users an easy
possibility to switch between different Harmony VMs.

> Alexey mentioned scripts as a quick solution. Is it possible to solve
> this problem on a build script level?
Yes, it's possible. We could specify needed VM by property and copy
hythr library for needed VM in class library "test" target. But this
solution looks like a "hack" but not "fix" :)

> Or should we change a launcher to reorder paths in LD_LIBRARY_PATH?
That's possible solution two. But I think it will be easier to move
hythr library to VMs directory (deploy/jdk/jre/bin/default or so) and
let VM load it from there.

> 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 <al...@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....@gmail.com> wrote:
> > > On 11/13/06, Alexey Petrenko <al...@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
>

Re: [vm][classlib] hythr library

[Alexei Fedotov <al...@gmail.com>]

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 <al...@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....@gmail.com> wrote:
> > On 11/13/06, Alexey Petrenko <al...@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

Re: [vm][classlib] hythr library

[Angela Lin <al...@gmail.com>]

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....@gmail.com> wrote:
> On 11/13/06, Alexey Petrenko <al...@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
>

Re: [vm][classlib] hythr library

[Alexey Petrenko <al...@gmail.com>]

So... If nobody objects...
I've created few JIRA issues to fix this problem:
http://issues.apache.org/jira/browse/HARMONY-2362

Tim, can you please try to resolve IBM VME issue?
http://issues.apache.org/jira/browse/HARMONY-2364

Patches are welcome :)

SY, Alexey

2006/11/24, Geir Magnusson Jr. <ge...@pobox.com>:
>
>
> Alexey Petrenko wrote:
> > 2006/11/24, Tim Ellison <t....@gmail.com>:
> >> Alexey Petrenko wrote:
> >> > 2006/11/13, Andrey Chernyshev <a....@gmail.com>:
> >> >> 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?
> >> >
> >> > Is that really so? Tim?
> >> That is really so, and it does not differ greatly from hythr.
> > If it is really so then why IBM VME needs hythr in bin? Let's remove
> > it from there. Leave a stub in classlib to build with. And move hythr
> > for DRLVM to VM directory as for IBM VME.
>
> Right - if the VMs are providing their own thread lib...  why not?
>
> geir
>

Re: [vm][classlib] hythr library

["Geir Magnusson Jr." <ge...@pobox.com>]

Alexey Petrenko wrote:
> 2006/11/24, Tim Ellison <t....@gmail.com>:
>> Alexey Petrenko wrote:
>> > 2006/11/13, Andrey Chernyshev <a....@gmail.com>:
>> >> 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?
>> >
>> > Is that really so? Tim?
>> That is really so, and it does not differ greatly from hythr.
> If it is really so then why IBM VME needs hythr in bin? Let's remove
> it from there. Leave a stub in classlib to build with. And move hythr
> for DRLVM to VM directory as for IBM VME.

Right - if the VMs are providing their own thread lib...  why not?

geir

Re: [vm][classlib] hythr library

[Alexey Petrenko <al...@gmail.com>]

2006/11/24, Tim Ellison <t....@gmail.com>:
> Alexey Petrenko wrote:
> > 2006/11/13, Andrey Chernyshev <a....@gmail.com>:
> >> 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?
> >
> > Is that really so? Tim?
> That is really so, and it does not differ greatly from hythr.
If it is really so then why IBM VME needs hythr in bin? Let's remove
it from there. Leave a stub in classlib to build with. And move hythr
for DRLVM to VM directory as for IBM VME.

> >> 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?
> >
> > I do not quite understand this approach... :(
> > How it will look like? We keep hythr library in bin directory and it
> > forwards the calls to VM specific threading library?
>
> That appears to be the proposal.
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>

Re: [vm][classlib] hythr library

[Tim Ellison <t....@gmail.com>]

Alexey Petrenko wrote:
> 2006/11/13, Andrey Chernyshev <a....@gmail.com>:
>> 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?
>
> Is that really so? Tim?

That is really so, and it does not differ greatly from 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?
>
> I do not quite understand this approach... :(
> How it will look like? We keep hythr library in bin directory and it
> forwards the calls to VM specific threading library?

That appears to be the proposal.

Regards,
Tim

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Re: [vm][classlib] hythr library

[Alexey Petrenko <al...@gmail.com>]

2006/11/13, Andrey Chernyshev <a....@gmail.com>:
> On 11/13/06, Alexey Petrenko <al...@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?
This will fix only the part of the problem. It will be impossible to
easily switch between different Harmony VMs.

> > 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?
Is that really so? Tim?

> 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?
I do not quite understand this approach... :(
How it will look like? We keep hythr library in bin directory and it
forwards the calls to VM specific threading library?

SY, Alexey

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

Re: [vm][classlib] hythr library

[Andrey Chernyshev <a....@gmail.com>]

On 11/13/06, Alexey Petrenko <al...@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