Static sequence javafx.stage.Stage.stages[] leads to OOM

Stages are not garbage collected because all of them I referenced from
 javafx.stage.Stage: Sequence<Stage> stages = FXCollections.<Stage>sequence();

The reason is in javafx.stage.Stage: storeVisible(boolean value)
which does:

       if (value && (impl_peer == null)) {
            ...
            // Insert this into stages so we have a references to all created stages
            stages.add(this);
       }

       if (!value && (impl_peer != null)) {
            // Remove form active stage list
            stages.remove(this);
            peerListener = null;
            impl_peer = null;
       }


This could lead to OOM. In particular it could be the case for running FX in
browser environment/applets.
This is also easy observed when running performance benchmarks (based on FXBenchmark)
which do create new Stage on each iteration.


From another side these static list of stages is used by automated tests.

So, need to refactor this to avoid potential OOM and make testing harness happy as well.

See more details in comments below.

---
Stage.stages[] has been there since before 1.0, but over time I've become less and less comfortable with it. Now that we have an Application class and an upcoming full-fledged application framework, it seems wrong to have this static list. Personally I'd be happy if we just yanked it...

Richard
---
IMHO, if something like this needed for testing then better approach would be to have "stage creation/removal" listener
that will be null all the time except if run from inside the tests (and there could be test helper classes to accumulate list of stages, etc.)

Supporting static lists of stages (or any other resources) in the runtime is asking for troubles with memory leaks in the browser environment.

-igor

On 1/31/11 1:10 AM, Alexandre (Shura) Iline wrote:
> Guys,
>
> Stage.getStages() method is the start point for node lookup from automated tests.
>
> First thing test do, it looks through the list of scenes to find the one (by whatever criteria) and then walk through the hierarchy to find whatever node it needs to do something with.
>
> It would not be impossible to write tests without the method, of course, only by not providing the method you force to hack an application to allow its testing.
>
> A tested application would need to have some kind of hook to let know about its stages or run test code or whatever. While, with this method, tests could be executed on an application with no change. The only requirement is being able to run code in the same VM.
>
> Such as JavaFX Authoring Tool, for example - they've been using Jemmy for testing the Tool unchanged - now they will have to hack it.
>
> All-in-all, it would be really great to keep it until there is some other way to obtain the list of changes, which as far as I can understand, Richard is referring to as "an upcoming full-fledged application framework".
>
> Anyhow, removing the method would involve some test rework. Not as big if there is a replacement, quite significant if there is not.
>
> Shura.
---