Fuite de mémoire fuit

Question

J'ai essayé de localiser les fuites de mémoire dans notre application, et je continue de me retrouver à regarder les composants Spark comme le coupable.

Je pense que j'ai trouvé la cause, mais ma compréhension de balayage de Garbage Collection/mark & n'est pas trop chaud, donc je voudrais vérifier mes conclusions.

De nombreuses classes dans Spark utilisent RichEditableText pour afficher leurs propriétés de texte (ComboBox, TextInput).

RichEditableText possède une propriété locale textContainerManager et appelle fréquemment compose() à ce sujet.

est ici l'extrait abrégé correspondant de TextContainerManager

// Line 282 - 292: 
    static private var stringFactoryDictionary:Dictionary = new Dictionary(true); 
    static private function inputManagerStringFactory(config:IConfiguration):StringTextLineFactory 
    { 
     var factory:StringTextLineFactory = stringFactoryDictionary[config]; 
     if (factory == null) 
     { 
      factory = new StringTextLineFactory(config); 
      stringFactoryDictionary[config] = factory; 
     } 
     return factory; 
    } 
// Line 1204: 
public function compose() { 
    // Line 1238: 
    var inputManagerFactory:TextLineFactoryBase = (_sourceState == SOURCE_STRING) ? inputManagerStringFactory(_config) : _inputManagerTextFlowFactory; 
    // Line 1242: 
    inputManagerFactory.swfContext = Configuration.playerEnablesArgoFeatures ? this : _swfContext; 
} 

ligne 1242 est la ligne cruciale ici, car il donne le dictionnaire statique une référence à notre composant.

(Note - J'ai vérifié ceci avec le débogueur pour confirmer quelle branche du ternaire est exécutée.) Cela empêcherait l'instance d'être jamais récupérée. Par exemple: Le dictionnaire statique a une valeur avec une référence à l'instance - l'instance ne peut pas être GC'd.

À son tour, cela empêcherait toutes les instances qui ont une référence à l'instance de TextContainerManager d'être également GC'd.

Alors que cette théorie correspond certainement à ce que je vois dans notre application, je ne peux pas croire qu'il y ait vraiment une fuite de mémoire dans un tel composant d'étincelle de bas niveau.

Quelqu'un pourrait-il nous éclairer à ce sujet?

BTW - J'ai ouvert un défaut sur bugs.adobe.com de suivre cette question, devrait-il se révéler être un véritable bug: https://bugs.adobe.com/jira/browse/SDK-29531

Answer 1

J'ai entendu dire qu'il ya plusieurs problèmes de mémoire liés à TLF . Cela devrait être corrigé dans le SDK Flex 4.5.

En attendant, vous pouvez toujours ouvrir un ticket sur http://bugs.adobe.com/jira/