>> >> > If only finalize() would be reliable. finalize is reliable, you just have to understand how it's implemented.
>> For fun we reimplemented the "A lot of garbage objects" version using >> Swing. It actually performed very different than the Jambi version >> because the objects are collected more often in that version. From the >> results of the performance profiler it seamed that when using Swing >> the garbage collector collects the objects every x milliseconds so >> there was never the huge pile of objects which resulted in the freeze. >> >> Sadly we never investigated that further. And I never had a look on >> how Swing influences garbage collection. >> >> > Swing might do the occasional System.gc() call or similar stunts. But it > might also just be the fact that the Qt objects have a finalizer, which > can hurt performance of the garbage collector in many ways, starting > with the time the method needs itself. > 1) allocation can't be completed with a simple pointer bump as it must also be specially registered to ensure finalization (ie, not a fast-path allocation) 2) objects will need to be allocated in the heap as there is no possibility for on stack or register allocation (escape analysis) 3) object must be "GC'ed" to the finalization queue. Results in object surviving eden 4) finalize must be run and until then, the object survives further gc attempts resulting in more copying or promotion 5) final GC attempt will need to deal with phantom references 6) finalize won't be run it vm shuts down before finalize thread gets to it. My guess as to why the game experienced a reduction in stutter when you started to reuse objects is that resued objects would be moved to tenured very early on. From that point forward, the temp objects most likely would be collected in eden resulting in very very short GC cycles. This only works so far. If you fill tenured with cached objects you will fail the young generational guarantee on every subsequent collection. This will result in back to back full GCs which will be much slower resulting in more GC pause time. The cure is a completely different heap configuration that favors quick promotion. Summary: 1) allocation can't be completed with a simple pointer bump as it must also be specially registered to ensure finalization (ie, not a fast-path allocation) 2) objects will need to be allocated in the heap as there is no possibility for on stack or register allocation (escape analysis) 3) object must be "GC'ed" to the finalization queue. Results in object surviving eden 4) finalize must be run and until then, the object survives further gc attempts resulting in more copying or promotion 5) final GC attempt will need to deal with phantom references. Collecting alternate reference types (weak, soft, phantom) is more expensive as the collector has to analyze the paths back to the gc root to determine the strongest linkage to understand if it can collect or not. 6) if vm shuts down before finalize thread won't get a chance to run. Regards, Kirk --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
