Discussion :

[anemol]

Bonjour,

Dans le cadre d'un projet personnel, une "AI" pour un jeu, j'avais besoin d'embarquer Mono dans une librairie dynamique C++, sous Linux (Ubuntu 14.04).
J'ai utilisé SWIG pour avoir un wrapper C++/C#. Le projet fonctionne très bien mais l'occupation mémoire devient trop importante au bout d'un moment car le ramasse-miette ne semble pas faire son travail.
J'ai testé avec le simple remplissage d'une liste, et effectivement, la mémoire n'est pas libérée au fil des appels.
J'ai cru comprendre que Mono-Embed avait un problème récurrent du côté du ramasse-miette?

Pour le process:
Le jeu démarre et ensuite charge pour chaque AI, la librairie C++

Comme il peut y avoir plusieurs instances de mon AI, j'ai créé un gestionnaire (une classe):
La première instance d'AI initialise créé ce gestionnaire et l'initialise:
- mono_jit_init()
- création d'un object et init (callback,etc). pour l'AI avec mono_gchandle_new() (sinon l'objet est détruit entre les appels)

Puis les autres AI (s'il y en a):
- création d'un object et init (callback,etc). pour l'AI avec mono_gchandle_new()

Durant le jeu:
Chaque AI est appelé au fil des événements:
Appels avec mono_runtime_invoke() pour l'object mono concerné.
La librairie Mono peut communiquer au jeu également via le callback.

A la fermeture du jeu, la dernière AI ferme le gestionnaire:
mono_jit_cleanup() etc



Si je n'utilise pas mono_gchandle_new() pour punaiser ("pinned") mes objets, ils sont rapidement détruits par Mono.
J'ai essayé avec mono_gchandle_new_weakref() mais même problème.

J'ai essayé également en appelant directement et régulièrement le GC depuis le C++ avec mono_gc_collect (mono_gc_max_generation ()) mais rien y fait.

Du coup, est ce que le ramasse miette fonctionne sur les objets punaisés?

[Graffito]

Essaie de remplacer l'appel au garbage collector par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

GC.Collect() ; GC.WaitForPendingFinalizers() ; GC.Collect()

en sachant qu'il y a/avait une bug dans la version 3.4.0/3.8.0 de Mono : https://bugzilla.xamarin.com/show_bug.cgi?id=20503

[anemol]

J'avais déjà essayé de forcer la collecte côté C# également (celle côté C++ est limitée à une fonction)

J'ai retesté avec:

GC.Collect() ; GC.WaitForPendingFinalizers() ; GC.Collect()

au lieu de:

GC.Collect() ; GC.WaitForPendingFinalizers() ;

La collecte ne se fait toujours pas pour autant. A croire que les objets créés par un objet punaisé sont également punaisés et donc non-collectables?

[anemol]

Finalement, j'utilise le handle d'un objet pour rappeler un objet par la suite et appeler ses méthodes. J'ai remarqué qu'il n'était pas nécessaire de les punaiser

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
Objects[team].Instance  = mono_object_new (Domain, Class); // Create instance (memory)
mono_runtime_object_init (Objects[team].Instance); //Call constructor

Je garde la mains sur mes objets (mais toujours le problème du GC) si je récupère le handle ainsi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Objects[team].handle = mono_gchandle_new (Objects[team].Instance, false);  // (true ou false ne change rien)

Par contre si je récupère le handle de cette manière:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Objects[team].handle = mono_gchandle_new_weakref (Objects[team].Instance, false);  //(true ou false ne change rien)

je garde la main sur un seul objet et les autres sont nettoyés entre les appels.

[Graffito]

Bravo pour ta résolution du problème .

Comme le garbage collector est gourmand en CPU, on peut éviter de l'appeler si il y a suffisament de mémoire libre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 long [,] TheArray ;
 try   { TheArray = new long[SizeToAllocateInMo,125000] ; } 
 catch { TheArray = null ; /* ... appel au garbage collector */ ; }

[anemol]

Hélas, non, le problème n'est pas résolu. C'est juste que les objets ne sont plus punaisés maintenant ("pinned"). Le GC continue à bouder la partie C#.

[Graffito]

As-tu bien vérifié les problèmes potentiels liés à des liens Parent ou Child impliquant les objets à libérer, ainsi que les éventuelles inscriptions sur des events ?

[anemol]

Merci pour tes réponses.

Oui, il y a sûrement des fuites dues à une mauvaise gestion de mes objets (dés-allocations) dans mon code, mais le GC n'est vraisemblablement pas actif sur mes objets puisque le fait de remplir uniquement un tableau comme dans ton exemple, fait que la mémoire ne jamais désemplie. Donc il apparaît qu'utiliser mono_gchandle_new() fait que l'objet n'est pas ramassé côté C++ mais qu'il n'en occupe pas du tout. (côté C# aussi du coup). C'est assez logique finalement avec le recul.

Du coup, pour contourner mon problème, au lieu de créer un objet par AI, je vais créer un seul objet qui va gérer (créer et aiguiller les appels vers les AI). Avec un seul objet je peux utiliser mono_gchandle_new_weakref()


Mes premiers tests rapides avec 3 AI semblent prometteurs car la mémoire plafonne rapidement et oscille entre 500 et 600Mo ce qui indique bien qu'il y a ramassage en cours de route.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
namespace Embed 
{
	static public class Loader
	{
		static Dictionary<int,IA> test=new Dictionary<int, IA>();
 
		public static void AddIA(ref int teamid)
		{
			test.Add(teamid,new IA());
		}
 
		public static void Update(ref int teamid,ref int frame)
		{
			test[teamid].Update(frame);
		}
	}
 
 
	public class IA
	{
		public void Update(int frame)
		{
			long [,] TheArray ;
			try   { TheArray = new long[40,125000] ; } 
			catch { TheArray = null ;  ; }
		}
	}
}

Je vais continuer à modifier mon code avec cette nouvelle approche et voir qu'il n'y a pas de mauvaises surprises plus loin.

Edit:

Au bout d'un moment, l'objet est ramassé sans aucune raison vu que je fais des appels (en utilisant son handle);

Si je n'utilise pas de handle mais directement son pointeur, l'objet n'est pas ramassé. (a priori)
Le ramassage est plus tardif mais a lieu.

Edit:
Le moindre appel à la librairie C++ nécessite de devoir disposer les ressources ensuite. Je pensais que le ramasse miette le ferait, mais que nenni.

[anemol]

En se limitant à un seul objet, le punaisage et la gestion par handle ne sont plus nécessaires (le pointeur sur l'objet suffit). Le GC semble fonctionner correctement maintenant que les ressources sont libérées après leur utilisation. Je considère comme résolu le sujet.