harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Artem Aliev" <artem.al...@gmail.com>
Subject Re: [drlvm][classlib] thread library - let there be one!
Date Thu, 19 Oct 2006 15:04:56 GMT
Angela, all,

I see you point and agree.
But if we move hythread lib to the VM we will require all VMs fully support it.
Is it necessary dependency?

So Here is the third way I see.
Leave the minimum implementation of hythread in the classlib, with the
set of functions any VM should provide for classlib.
  This will simplifies adopting classlib to new VM and allows to have
solid threading model.
So any VM could have its own super set of threading functions.

Note: Classlib uses only monitor, TLS, and thread_create() from hythread.

Thanks
Artem




On 10/18/06, Angela Lin <alin.harmony@gmail.com> wrote:
> Artem et al,
>
> Sorry for jumping in late here.
>
> I maintain the J9VM thread lib.
>
> Option 1 worries me because it implies that the classlib could use a
> different threading model from the VM. This is bad because they both
> operate on the same threads.
>
> For example: Layer (2) of hythread might include internal thread state
> tracking, which is needed to support inspecting the thread state.
> Using layer (1) directly would bypass the thread state tracking.
>
> Angela
>
>
> On 10/16/06, Artem Aliev <artem.aliev@gmail.com> wrote:
> > Tim,
> >
> > Reading through discussion, I find two option for the second step.
> > Let's discuss them.
> >
> > 1.
> > > -  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
> > Then move the rest of hythread to VM.
> >
> > In this case we will move all VM releated functionality out of a classlib.
> > The classlib will use tls, mutex and thread_create from *.h files.
> > VM will be free to implement threading in any way.
> >
> > 2. Move hythread out from the drlvm to a portlib.
> > In this case  classlib will contains a lot of only VM releated code.
> > So we will meet the same problems with an new VM.  But we will have
> > common place for all synchronization primitives and could control
> > them.
> >
> > Thanks
> > Artem
> >
> >
> >
> >
> >
> > On 10/16/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> > >
> > >
> > > 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
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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