On 12/19/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
Hi See my comments inline, please. On 12/19/06, Xiao-Feng Li <[EMAIL PROTECTED]> 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
