Identification of Long-Living (Potential Not-DPI-Updated) GCs

[HeikoKlare]

A GC is usually short living, but there is neither a necessity nor any enforcement of that. With multi-monitor HiDPI support, long-living GCs might become a problem, since their zoom value is only initialized once and never updated.

In order to support developers in finding long-living GCs, whose zoom value might need to be updated or whose consumers should be reimplemented using rather short-living GCs, adding some validation logic could be beneficial. With multi-monitor HiDPI support, an option could be to reevaluate once in a while (e.g., upon specific operation calls on the GC) whether the GC's Drawable still has the same zoom as currently stored in the GC's GCData.

On a more technical level (since Drawables do not expose their zoom values), it might be possible to have the GC create a new GC for the drawable and compare it's GCData's zoom value with the current one. In any way, this feature should be something that can be enabled (usually in development mode) by something like a flag / VM argument, as it should not be enabled in productibe use. Maybe the enablement can be combined with the one for #88 (i.e., some kind of "strict mode" for GC).

[fedejeanne]

Is there any such "long-living" GCs that you can mention, @HeikoKlare ? I would like to get a better understanding of the situation here by looking at the code.

Would it be correct to assume that GCs that implement AutoCloseable might be "short living GCs "? I mention this because I found a similar topic in eclipse-platform/eclipse.platform.swt#955 and a possible solution in eclipse-platform/eclipse.platform.swt#1063. The discussion hasn't progressed in months but if we think such approach is valuable and helps the developers use "better" GC's then maybe we can continue the discussion.

[HeikoKlare]

We would like to be able to find GC in our RCP application that are unintentially long-living. The reason is that with the introduction of multi-zoom support, a GC may outlive the context in which it is valid (i.e., the zoom may change as the context control was moved to another monitor). Since we do not know whether we have such GCs, such a setting can help us.

As a comparison to the mentioned discussions: they are rather targeted at properly implementing GCs that are closed again timely, while this one is about detecting ones that are not closed timely in existing code.

[akoch-yatta]

In PaintExample you find an example of a long living GC, although I'm not sure, if it is a very good example.