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 Wed, 20 Dec 2006 10:07:27 GMT
HI.
Read, my comments inline please.

On 12/19/06, Weldon Washburn <weldonwjw@gmail.com> wrote:

> ...
> 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?
> ...
>
I think, internal finalization system design can be improve in any time, if
interface will not be changed. But if interface changed, it can affect both
GC and finalization system. Also I'd like that GC v5 works good with both
finalization systems, "native" and "java".


>From my point of view, improvement of finalization system is not critical
now.  But if anyone would like to do this task, after design review on
Harmony, it is very good.



BR

Pavel Afremov.

On 12/19/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
>
> 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