1312 2016-06-09 09:13:35 +0200 GLContextShareSet memory leak when repeatedly creating and removing GLDrawables 2019-12-31 05:50:44 +0100 1 1 3 JogAmp Jogl opengl 2.4.0 All all RESOLVED FIXED P4 normal --- 1 tom.nuydens sgothel gouessej sgothel DEFECT gluegen 5979d66fb0c619be32ebcf9fbe644cf6d757345f gluegen c6fabb0ac94000afe29156f170c63080a37c034b gluegen 178c7b9d40e06a04790542241912ca21d2c7b92f gluegen add34060fde735ea932ca49fbe79e473c5a4f40b jogl 658e25429aa150fad45a7c81a5a08f9ca35c4479 jogl 79833c9e4741bec9d1f56ea8b322679756b16f70 --- oldest_to_newest 5641 0 tom.nuydens 2016-06-09 09:13:35 +0200 My use case is an application that has one "main" GLDrawable which is always visible, and one or more "secondary" GLDrawables that can be opened and closed any number of times (e.g. in a separate window). I want all these drawables to do GL context sharing. As long as the main drawable exists, however, GLContextShareSet seems to keep strong references to all the secondary ones that I have ever created. Hence, even though they have been destroyed, the secondary ones cannot be GC'ed. I couldn't see a good reason for this, and was able to work around it by replacing the maps in GLContextShareSet with "weak key" maps. 5648 1 tom.nuydens 2016-06-13 11:36:40 +0200 I submitted my workaround in a pull request: https://github.com/sgothel/jogl/pull/101 5653 2 gouessej 2016-07-06 09:01:46 +0200 Hi I agree with your main statement, GLContextShareSet shouldn't keep strong references on objects that could become useless, it shouldn't prevent their garbage collection. I just wonder if there is a more simple solution to fix this bug. I have looked at your pull request. 6070 3 sgothel 2018-01-16 07:14:25 +0100 Hi Tom, 1st of all I would like to see a specific unit test for this, we should have some already available - maybe we can fine tune them. The actual bug you are hinting would be (using our terminology): "GLContextShareSet seems to keep strong references to all the shared ones that I have ever created. Hence, even though they have been destroyed, the shared ones cannot be GC'ed" 'GLContextShareSet.unregisterSharing(this)' never gets called? Which points us to the logic in GLContextImpl.destroy() #498: +++ if( GLContextShareSet.contextDestroyed(this) && !GLContextShareSet.hasCreatedSharedLeft(this) ) { GLContextShareSet.unregisterSharing(this); } +++ I will investigate this one now. The 'hard lifecycle' with strong references is intended to enforce a proper user lifecycle call hierarchy, e.g. calling 'destroy()'. Let's see what we can do here .. 6485 4 sgothel 2019-12-31 05:50:44 +0100 Introducing WeakIdentityHashMap: gluegen 5979d66fb0c619be32ebcf9fbe644cf6d757345f gluegen c6fabb0ac94000afe29156f170c63080a37c034b gluegen 178c7b9d40e06a04790542241912ca21d2c7b92f gluegen add34060fde735ea932ca49fbe79e473c5a4f40b +++ jogl 658e25429aa150fad45a7c81a5a08f9ca35c4479 jogl 79833c9e4741bec9d1f56ea8b322679756b16f70 Bug 1312: GLContextShareSet: Utilize WeakIdentityHashMap for shareMap and its destroyedShares Picking up Tom Nuydens suggestion to utilize a WeakIdentityHashMap instead of a IdentityHashMap, allowing destroyed GLContext to be removed from the GLContextShareSet through the GC. TestSharedContextVBOES2NEWT5 demonstrates the use-case, having one master context and several slaves being spawn off, killed and new sets to be spawn off. Here the GLContextShareSet shall not hard-reference the destroyed and user-unreferenced context, but allowing the system to GC 'em. +++ Thank you Tom. I kept the createdShares as hard-references on purpose. TestSharedContextVBOES2NEWT5 passes the test.