Description
I am using the 3.02 android library.
I have 2 android.app.Activity subclasses, each of which embeds a different processing.core.PApplet fragment subclass. Those fragments extend my own subclass MyPApplet intermediate shown partially below, and MyTroublesomeProcessingFragment overrides the settings() method with a 3D setup:
public abstract class MyPApplet extends PApplet {
@Override
public void exit() {
super.dispose();
}
...
}
public class MyTroublesomeProcessingFragment extends MyPApplet {
@Override
public void settings() {
size(width, height, PConstants.P3D);
smooth();
}
...
}
I intentionally override exit() in a common intermediate fragment subclass since the default behaviour in PApplet.exit() is to ultimately call [not-overridable, package protected method] exit2() which calls System.exit(). Nasty. onBackPressed() in PApplet calls exit().
In both cases rendering is ok and does not produce any errors. In one case there are no memory issues whatsoever, but in the other case there is a significant issue where the Activity can never be GC'd.
In that problematic case, the Activity instance is never GC'd even after finish() and onDestroy() have been called on that activity instance (as observed by sitting on the debugger).
When I look through the hprof capture (using IntelliJ), I can see that my activity instance is still held as a reference by the activity field in the PApplet superclass of the fragment:
LIVE REFERENCE TREE:
mpkg.processing.MyProcessingActivity@315940896 (0x12d4e020)
----(*PApplet.activity* field in) mypkg.processing.MyTroublesomeProcessingFragment@317768448 (0x12f0c300)
Of course I expect that the Activity and its dependants will have been marked for GC, but they are definitely not since the PApplet subclass fragment instance remains in memory and holds the ref to the activity.
Is it possible that I am somehow leaving the PApplet in a state such that it does not release the Activity reference that is held in (private) field activity ? Could these subtle changes
- to avoid System.exit(), and
- to set a 3D canvas
be somehow responsible for this ?
I have no console errors or exceptions.
The troublesome fragment's draw() consist of a set of calls to translate(), stroke(), line(), ellipse(), fill().
My subclass fragment MyTroublesomeProcessingFragment does not hold any additional Activity refs.