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 Tue, 19 Dec 2006 11:14:18 GMT
Hi

See my comments inline, please.

On 12/19/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:

> For "magic", I don't see why this is special to the Java finalization
> implementation. The key of finalization is to execute the Java
> objects' finalize method. The "magics" can be applied to both ways
> (Java thread finalization or native). Can you give detailed
> explanation why you think "magic" technology can make the Java thread
> finalization better in performance than native thread implementation.



The "magic" technology can provide opportunity to get finalizable object
from protected native queue, and call finalize method without "native" code
invoke. All finalization system code can be written on "magic" java. It can
increase safety and performance of finalization system.

For "WBS", I personally think the idea of WBS is buggy. For
> finalization, increasing thread number to compete with Java thread for
> scheduling opportunity is problematic.



The idea of WBS is not increasing threads number ;) Large quantity of java
thread is not our target. The main idea of WBS is increasing relative
performance of finalization system. The other question how its implemented.
Lest split idea and implementation. About "buggy" implementation. At first
parallelization handling of one type tasks is not a "buggy", it common,
usually used optimization for multithreading environment.



Some time ago I had a several experiments with finalization system
scheduling. On one processor without hiperthreading changing priority of
finalazer thread works OK. But on multi-core, multi-processor and on
hyperthreading machine one finalizer thread sometimes is not enough. And it
independents on priority of this thread. At same time several finalizer
thread (2-4) works OK. Also performance of multithread implementation is
higher with usual finalization workload. So implementation with 2-4 usual
finalizer threads works better than 2 with high priority. Of cause with
heavy work load on finalization system several hi-priority threads will be
work better than many usual threads, because in this case many threads
impede each others. But current implementation is optimized for usual
workload.



Also, taking it into account, current "java" implementation works better, in
heavy work load situation, than new "native" implementation. It can be
checked with gc.SynchronizedFinalizerTest. As I know LiGang Wang checked it,
and found out that it passes "with more native threads specified" only. So
dynamic work balance mechanism is required.



I think that WBS should increase relative finalization performance by
following steps.

   - Increase number of finalizer threads while them quantity is less
   then processors number.
   - Using locks for stopping user threads. I have some ideas how to do
   this without deadlock.
   - Increase priority of finalizer thread. Or reduce priority of user
   threads which generate finalizable objects, because finalization activities
   shouldn't stop "good" threads which don't create fianalizabe object.

This idea is an assumption that
> the underlying scheduling system in OS will work as WBS expects, but
> this assumption is not necessarily true.



Why?



> We have better idea to
> support aggressive finalization activities than WBS which is not in
> the patch yet.



Could You describe your ideas? It's better to discuss it before
implementation. I hope my experience in finalization area can be useful.
Also I think that GC v5 should start work with current finalization system
implementation (both "native" and "java"). When it will be OK, new
improvements can be added to Finalization system, and it can be split to
separate component. It's Right, isn't it?

As I said, the native finalization implementation is still evolving. I
> would suggest to have some benchmarks to compare the Java thread
> implementation and the native one, which can help us to understand the
> design better.



We can support both and compare them. But any GC should works with any
finalization system.

1% is not the point. The point is, the implementation of those
> boundary crossings make the  code harder to maintain. Removing those
> crossings will help a lot to the reliability and security. It doesn't
> matter if those crossing calls have frequently or not.



But You didn't removed call through native-java-native boundaries totally.
You just reduced it quantity. To totally removing I see only one way, use
"magic" java code. I don't against native thread, and I'd like it in some
case. But frankly speaking, this argument can be advantage of native
finalizer thread.



In my mind "ideal" fianilization system is "hybrid". It should create and
start "native" finalizer thread, which assoshiatets itself with java thread
and calls  "magic" java code, which provide finalization without java-native
invokes.

Thanks
Pavel Afremov



On 12/19/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
>
> Pavel, I cannot agree on your major points:
>
> 1. Use "magic" technology for extra performance;
> 2. Use "Work Balance Subsystem"(WBS) for better scheduling.
>
> For "magic", I don't see why this is special to the Java finalization
> implementation. The key of finalization is to execute the Java
> objects' finalize method. The "magics" can be applied to both ways
> (Java thread finalization or native). Can you give detailed
> explanation why you think "magic" technology can make the Java thread
> finalization better in performance than native thread implementation.
>
> For "WBS", I personally think the idea of WBS is buggy. For
> finalization, increasing thread number to compete with Java thread for
> scheduling opportunity is problematic. This idea is an assumption that
> the underlying scheduling system in OS will work as WBS expects, but
> this assumption is not necessarily true. We have better idea to
> support aggressive finalization activities than WBS which is not in
> the patch yet.
>
> As I said, the native finalization implementation is still evolving. I
> would suggest to have some benchmarks to compare the Java thread
> implementation and the native one, which can help us to understand the
> design better.
>
> On 12/19/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
> > Hi
> >
> > Native finalizer threads really has following advantages:
> >
> >    - No java code should be called in vm_hint_finalaze. It's a main
> >    advantage. Potentially it's more secure.
>
> Right.
>
> >    - Less on 1% calls via native-java-native boundaries. ;)
>
> 1% is not the point. The point is, the implementation of those
> boundary crossings make the  code harder to maintain. Removing those
> crossings will help a lot to the reliability and security. It doesn't
> matter if those crossing calls have frequently or not.
>
> Thanks,
> xiaofeng
>
> > From other side java thread can be improved by "magic" technology in
> future,
> > for extra performance.
> >
> >
> >
> > Following native thread advantages is fake or disputable:
> >
> >    - "Extra java threads maps on native". Why it should be bad? Also
> >    finalizers of some objects can ask VM about current java thread. So
> mapping
> >    java threads to native should be done in any case.
> >    - "Common pool for VM native threads". In the case of java threads
> >    (maybe include GC java threads) VM will be able to have one common
> pool of
> >    the user and system threads. So I don't see any advantages here.
> >    - "Native threads easy can be scheduled". Current implementation of
> GC
> >    v5 finalization support doesn't use Work Balance Subsystem. The high
> >    priority for finalizer threads forever is not good example of
> scheduling.
> >    Also all java thread based on native, so priority for java thread can
> be
> >    changed too. It's not implemented now for java thread, but it's not
> >    advantage of native thread in any case. In current "temporary"
> >    implementation of GC v5 finalization support, the scheduling is worse
> than
> >    in "java thread" implementation. But is can be improved in future. So
> from
> >    this point of view native and java threads are equal.
> >    - "C++ interfaces is more natural for DRLVM". It's very disputable. I
> >    think that java interfaces is the best interface solution on this
> moment,
> >    especially for java machines and java applications.
> >    - "Potential circularity dependence with VM bootstrapping". Xiao-Feng
> >    could present a test which shows it or call path. If you mean Fake
> >    Circularity Error, that there are two "impossible" tests which shows
> that
> >    it's not finalization system faults (see HARMONY-1945), and
> additional check
> >    to avoid it was added to finalization system in HARMONY-2230. Maybe
> you mean
> >    that java thread is not so secure as native, because depends on the
> other
> >    components and can be affects by errors in them?
> >
> >
> >
> > I agree that support both native and java threads is a good solution.
> The
> > main target for "native" implementation is support of WBS (Work Balance
> > Subsystem), for "java" implementation is support of thread priority
> > changing. Both this implementation should be unified to one common
> > interface. Now this interface contains vm_hint_finalaze function only.
> >
> >
> >
> > Thanks.
> >
> > Pavel Afremov.
> >
> >
> > On 12/16/06, Xiao-Feng Li <xiaofeng.li@gmail.com> 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.
> > > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message