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 Tue, 19 Dec 2006 17:33:02 GMT
On 12/19/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:

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


I like it.  See comments below.

[snip]



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


Actually, I think this is the key issue.  Ideally there would be a clean,
simple gc/finalization interface.  One that all GCs would plug into
including MMTk.

[snip]


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


Good observation.  The messy native-java-native transitions have not been
completely removed in the GCV5 finalizer approach.  Reducing these
transitions is going in the right direction.  Removing them completely is
the end point.

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.


Another good observation.  In your opinion is this something that would help
the short term stability focus?  Should we try to do this now, or is it
something we should try at a later date?  My guess is that the gc/finalizer
interface is not impacted by the above internal finalizer design.  Basically
the GC hands objects to be finalized to the finalizer.  Once finalized, the
finalizer needs to simply not enumerate the object anymore.  Does this make
sense?

Thanks
> Pavel Afremov
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division

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