harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm][classlib] thread library - let there be one!
Date Mon, 16 Oct 2006 14:04:11 GMT


Tim Ellison wrote:
> First step (moving out of luni) looks good to me.
> 
> I'd like some more discussion around the second step (picking up drlvm
> version) before you do a wholesale replacement.

Yes please.  Lets do small, reversible steps.

geir

> 
> Regards,
> Tim
> 
> Weldon Washburn wrote:
>> Artem,
>> Thanks.  I will take a look.
>>
>>
>> On 10/12/06, Artem Aliev <artem.aliev@gmail.com> wrote:
>>> 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 <artem.aliev@gmail.com> 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. <geir@pobox.com> wrote:
>>>>> On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote:
>>>>>
>>>>>> On 9/28/06, Geir Magnusson Jr. <geir@pobox.com> 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 <t.p.ellison@gmail.com> wrote:
>>>>>>>>> Yes, exactly.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Tim
>>>>>>>>>
>>>>>>>>> Andrey Chernyshev wrote:
>>>>>>>>>> On 9/26/06, Geir Magnusson Jr. <geir@pobox.com>
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 <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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Andrey Chernyshev
>>>>>> Intel Middleware Products Division
>>>>>>
>>>>>>
>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>> ---------------------------------------------------------------------
>>> 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


Mime
View raw message