On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:
Weldon, I agree with your comments and observations below. Let's take
baby steps to get fully unified. I'm sure we all want to keep things
working throughout.
So what's the first stop? Move hythread as-is out of classlib to a
peer in the tree?
geir
Regards,
Tim
Weldon Washburn wrote:
On 9/20/06, Tim Ellison <[EMAIL PROTECTED]> 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. <[EMAIL PROTECTED]> 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-
[EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-------------------------------------------------------------------
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
--------------------------------------------------------------------
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
