harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [drlvm][gcv5] finalizer design
Date Wed, 20 Dec 2006 21:23:33 GMT
Xiao-Feng Li wrote:
> 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.

This would mean you should implement JVMTI heap iteration since it is 
currently implemented in drlvm GC. Do you have plans to support JVMTI 
heap iteration 
(http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#Heap) in GCv5?

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


-- 
Gregory


Mime
View raw message