harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][gcv5] finalizer design
Date Fri, 15 Dec 2006 16:54:25 GMT
On 12/15/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
>
> Hi.
>
>
>
> Weldon.
>
> Could You be so kind to read mail list <<[DRLVM][GCv5] patch for new LOS
> collector and finalizer/weakref support>>.


Yes, I recall your comments.  I decided that since GCV5 finalizer does not
disrupt existing finalizer to go ahead and do the commit.  Its is fairly
simple to commit compensating changes if we decide to eliminate GCV5
finalizer.

I tried to start discussion in it, during patch review process. But it was
> stopped  by Ligang Wang, because, as I understand, the "new" solution is
> not
> "real" solution (Work Balance Subsystem was turned of there, for
> example), "it's
> only a start, and at the moment only for GCv5". So it's a temporary
> solution.


The discussion needs to be restarted.  Xiao Feng, can you reply to the
questions?

So I have several question for "new" scheme, and when it will be solved, we
> will be ready to discuss a future development of finalization system. I
> will
> be glad to share my ideas in this area.
>
>
>
> Salikh.
>
> You can find prepared by my patch
> HARMONY-2230<https://issues.apache.org/jira/browse/HARMONY-2230>,
> which contains described by you feature, implemented in more correct way,
> as
> I think.
>
>
>
> Thanks.
>
> Pavel Afremov.
>
>
>
>
> On 12/15/06, Salikh Zakirov <Salikh.Zakirov@intel.com> wrote:
> >
> > Weldon Washburn wrote:
> > > Harmony-2560 adds a second finalizer implementation to the Apache code
> > > base.
> >
> > Speaking of finalizers design, I would like to note that HARMONY-1952
> > has a proof-of-concept idea of refining the current weak references
> > design to prevent running java code from a vm_hint_finalize() callback,
> > which may happen anywhere in the user code.
> >
> > > But "build
> > > test" does not exercise finalizers to any degree.
> >
> > Not true.
> > $ grep -lr finalize vm/tests/
> > vm/tests/kernel/java/lang/RuntimeAdditionalSupport2.java
> > vm/tests/kernel/java/lang/RuntimeAdditionalTest40.java
> > vm/tests/kernel/java/lang/RuntimeAdditionalTest43.java
> > vm/tests/kernel/java/lang/RuntimeTest2.java
> > vm/tests/kernel/java/lang/SystemExtensionTest.java
> > vm/tests/smoke/exception/FinalizeStackTest.java
> > vm/tests/smoke/gc/Finalizer.java
> > vm/tests/smoke/gc/FinAlloc.java
> > vm/tests/smoke/gc/RunFinalizersOnExitTest.java
> > vm/tests/smoke/gc/SynchronizedFinilazersTest.java
> > vm/tests/smoke/stress/Finalizer.java
> > vm/tests/smoke/thread/InfiniteFinalizer.java
> >
> > But then, I believe that 'build test' run without any additional
> switches
> > will not exercise any of GCv5.
> >
> > > In any case, long term we need just one finalizer design and
> > > implementation.  I would like to see a discussion on the merits of
> each
> > of
> > > the finalizer approaches.  It would be good to pick one approach
> within
> > one
> > > week.  Then we can clean up the code to reduce confusion.
> >
> > I guess you mean "it would be good if someone submits a _cleaned code_
> > within one week so that we could make a decision" ?
> >
> >
>
>


-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message