harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Afremov" <pavel.n.afre...@gmail.com>
Subject Re: [drlvm][gcv5] finalizer design
Date Fri, 15 Dec 2006 10:21:46 GMT
Hi.



Weldon.

Could You be so kind to read mail list <<[DRLVM][GCv5] patch for new LOS
collector and finalizer/weakref support>>.

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.



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" ?
>
>

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