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 <[EMAIL PROTECTED]> 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 <[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]
>>>
>>>
>>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]