Guys,
1. Make classlib/modules/portlib directory (or portlib in the root?)
and move hyprt, hysig and hythread code into it. Update build to work
with new directory.
[Andrey]- pull out hythread from classlib, make it a shared
component
The first step is done in JIRA HARMONY-1843.
I move common, pool, port, thread, sig from luni to new component
portlib.
The first idea was to move only port, thread, sig, but they depend on
common and pool libs. It looks natural to do not produce cyclic
dependencies among components, so I move these two also to portlib.
Unfortunately, this does not fully solve two stage luni building
process (build-native-core and build-native-secondary), but this is
another problem.
So If we are still committed on these reorganization, please review
and apply the patch.
A move_to_portlib.sh script create portlib directory structure and
move appropriate files from luni to portlib (by svn move).
A portlib_files.patch update build to works with new structure.
Thanks
Artem
On 9/29/06, Artem Aliev <[EMAIL PROTECTED]> wrote:
Guys,
Let me try to make this changes.
Here is my understanding of the steps I need to do.
1. Make classlib/modules/portlib directory (or portlib in the root?)
and move hyprt, hysig and hythread code into it. Update build to work
with new directory.
[Andrey]- pull out hythread from classlib, make it a shared
component
2. Move DRLVM hythread to classlib and update drlvm build for it. So
both classlib and drlvm will work on the drlvm hythread.
- split hythread, refine the bottom layer (thrdsup.h and mutex.h)
and
upper layer (hythead_xxx)
- migrate classlib code to the bottom layer (1) of hythread
I do not think it is necessary because the hythread will be shared
library.
This make sense only in case we move only layer(1) into the shared
directory.
3. merge hythreads into one library getting bast code from both
sources.
migrate DRLVM's thread manager to (1) from APR
Will be done on this stage.
4. merge classlib and drlvm signal handling code.
5. merge port libs code.
6. ????
Thanks
Artem
On 9/28/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote:
On 9/28/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote:
+1 on the below.
I am assuming Andrey and his team will do this work. (Andrey,
when
will you
start?)
We have to start first by pulling hythread out, but where? After
thinking about it for 5 more seconds, putting it on the top level
enhanced/<something>
is IMO a bad idea. There's nothing worse than going to a
project's
SVN and finding tons of confusing things.
I agree making "thread" a standalone component at the level of
enhanced/<something> probably isn't worth doing. What may make a
sense
is to consider thread a part of the portlib and make the portlib a
separate component at that level. Portlib is the only piece
which is
shared between VM and classlib, this could justify it's appearance
at
the high level.
Is there any downside to keeping it somewhere under
/classlib/trunk
My only guess would be the inability to build VM independently from
the classlib.
Sure, you'll still need either to build the /portlib or the /classlib
and simply make it a module by itself?
If we can not have a portlib as a high level component (like
classlib
or drlvm), then at least having it as a separate module within
classlib would be nice.
This is one of those things where doing the small step (do it in
classlib) and then consider the large step (do it as a peer) seems to
be reasonable, but i don't feel too strongly...
geir
Thanks,
Andrey.
Hopefully we can clean up how drlvm handles the classlib portlib
function
table at the same time. Currently two versions of this table
are
created
during startup. "Portlib function table - let there be one!"
Seriously,
this is incredibly difficult code to maintain.
On 9/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Yes, exactly.
Regards,
Tim
Andrey Chernyshev wrote:
On 9/26/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
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?
I can suggest the following steps:
- pull out hythread from classlib, make it a shared
component
- split hythread, refine the bottom layer (thrdsup.h and
mutex.h) and
upper layer (hythead_xxx)
- migrate classlib code to the bottom layer (1) of hythread
- migrate DRLVM's thread manager to (1) from APR
Each step can be done without breaking the whole code stack.
As a result, we'll have a bottom part of hythread which will
be
shared
between the classlib and DRLVM.
Some additional steps could be:
- pull the rest of the portlib out of the classlib, make
it a
shared
component as well
- migrate DRLVM to portlib
Thanks,
Andrey.
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: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail:
[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: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
--
Weldon Washburn
Intel Middleware Products Division
---------------------------------------------------------------------
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]
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
