harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][classlib] thread library - let there be one!
Date Wed, 20 Sep 2006 15:22:46 GMT
On 9/20/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>
> Artem Aliev wrote:
> > Gier,
> >
> > The hythread is just most visible example. There are also signal
> > handling problem. classlib hysig lib setup signal handlers and then
> > drlvm overrides them by its owns. There are code duplication in
> > classlib hyprt.dll drlvm port.lib:
> > classlib/trunk/modules/luni/src/main/native/port vm/port/src
> >
> > These three pair of components contains significant part of the
> > system dependent code for both VM and CLASSLIB. I think, all this
> > code naturally defines portlib component that could be shared between
> > classlib and VMs. So, as a first step, we could move all this code in
> > to the one place, name portlib to have three directories classlib,
> > drlvm, portlib.
>
> I think it is quite reasonable to call out the portlib and threadlib
> separate (in the repository) to the VM and classlib.  As you point out,
> then VM and classlib can share the code -- though it will not become a
> requirement for VMs that run the harmony code to be using those
> libraries for their own implementation.


Tim,
One of the things to worry about is system-wide lock protocol.  We will need
to think through what locks portlib, threadlib and JVM are holding and if
there are any deadlock possibilities.

Another issue is the implementation of signal chaining.  There seems to be
code in hysignal.c that implement "-Xrs".  I guess the idea is that a
Harmony JVM would somehow not link this code and use its own
implementation.  The bottom line is that we probably need to carefully pick
through what is currently in classlib threads/signals and rearrange stuff so
that it reduces the confusion.  We need to make this part of the system much
easier to work on.

Do you have recommendations on next steps?  Does it make sense to start
moving stuff into the directories described above.  Or is more discussion
needed.



> As the second step, the pairs of libraries should be merged and the
> > classlib and drlvm refactoried to have only 3 lib instead of 6.
>
> Yep, this would be part of the consolidation into new Harmony top-level
> components.  It makes sense that we share the same impl in the project.
>
> > The 3rd step is to replace most of the functions with APR ones and
> > move the rest of the code to the APR.
>
> I think it is quite well documented on this list that this should not be
> a goal.


I agree we don't need to move classlib to APR provided that:

1)
There is an easy to understand distinct seperation of the different
threading/signals packages.  In specific, we need to know which threading
package is being called by DRLVM without ambiguity.

2)
There is clear understanding of how JVM and classlib threading/signals
interoperate.


Regards,
> Tim
>
> > Thoughts?
> >
> > Thanks
> > Artem
> >
> >
> >
> >
> >
> >
> > On 9/19/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> >> All,
> >>
> >> we need to put this issue to bed, as we're tripping over it, it seems.
> >>
> >> Any thoughts on how to move forward on this?
> >>
> >> geir
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> 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
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message