harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robin Garner" <robin.gar...@anu.edu.au>
Subject Re: [drlvm][gcv5] finalizer design
Date Sun, 17 Dec 2006 12:51:12 GMT
Naively, I would have thought the design of finalization and GC were 
orthogonal.

In terms of interfaces,
a) VM informs GC upon creation that an object has a finalizer (and needs
notifying when it becomes unreachable).
b) GC informs VM (and forwards or marks object) when an object with a
finalizer becomes unreachable (VM is then responsible for keeping it alive
until finalization is complete).

What happens after (b) is outside the scope of the GC, surely ?  And isn't
how the GC deals with the information provided by (a) outside the scope of
the VM ?

signed,
Puzzled, in Canberra.

> All. It's good to see this discussion initiated. That's exactly what
> we want. It would be a little frustrating to see our solution
> committed without any response from the community. :-)  Anyway, we
> submitted GCv5 finalizer solution for three reasons:
>
> 1. We don't want GCv5 submission to break any existing functionality,
> and to keep the impact to minimum.
> 2 . We think it might be good idea to have more than one Finalizer
> solutions in a JVM, as we have multiple JITs, multiple GCs, and
> probably multiple other components as well.
> 3 . We think a native thread Finalizer solution is better than a Java
> thread solution. Since the Java thread actually runs in a native
> thread, we don't need the extra wrapper.
>
> Explanations to 2.
>   - It doesn't matter to have multiple solutions for one component
> except for very strong reason.  Multiple solutions can be measured and
> studied for different scenarios.
>   - A Java thread finalizer solution is not a bad idea, and it would
> be also desirable to have a native thread finalizer if it has many
> advantages as described below. Different GCs can invoke different
> finalizer solutions for its best performance, or same GC can invoke
> different finalizer solutions at different times. This is feature
> rather than a bug.
>   - It is probably good for DRLVM to have the two finalizer solutions
> to exercise its modularity design in the finalization subsystem. This
> is one of the goals of DRLVM design.
>   - It might be unreasonable to say one solution is absolutely better
> than the other one, hence it is uncessary to quickly decide to keep
> one and reject another one. The VM is evolving, so are its subsystems.
>
> Explanations to  3 .
>   - In Java finalizer thread implementation, there exists potential
> circular dependence between the Java thread startup and JVM
> bootstrapping. The bootstrapping issues or bugs with Java code in VM
> were discussed more than once.
>   - In Java finalizer thread implementation, there are rounds of
> redundant steps to do finalization with Java thread. In existing Java
> thread implementation, to execute the finalizers, VM native calls Java
> method startFinalization to wakeup finalizer threads. The finalizer
> Java threads call a native method doFinalization to excute the
> finalizers. This native method accesses native queue and calls Java
> finalizer method again. With a native thread finalizer, it simply
> calls the Java finalizer directly without all other boundary
> crossings.
>   - A java finalizer thread finally maps to a native thread managed by
> VM. This extra mapping is unnecessary.
>   - Finalizer threads are VM internal entities. VM may want to
> schedule it as it wants for load balance or helper threading. This is
> much easier with the direct native threads.
>   - With native thread finalizer, we can share the same thread pool
> with other VM components such as GC, etc. This helps to manage the
> system overall performance and scalability, and it's easier.
>   - DRLVM is in written in C++, its components interact through native
> interfaces. It is natural for VM core components written in native
> code.
>
> It would be good to continue this discussion to reach an agreement on
> the design. We probably can converge on one solution, or agree to keep
> two solutions.
>
> Thanks,
> xiaofeng
>
>
> On 12/16/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
>> 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
View raw message