Puis-je (et est-ce que je veux jamais) définir la taille maximale du tas dans .net?

Question

Venant d’un arrière-plan Java, j’ai l'habitude de dire à la machine virtuelle Java quelle devrait être la taille maximale du segment de mémoire. Si le programme en cours essaie d'avaler plus que ce qui est autorisé et que le ramasse-miettes ne peut plus libérer de ressources, alors OutOfMemoryError est renvoyé et tout se passe comme prévu. Il est donc important de définir la taille de tas maximale en Java.

Cela s'applique-t-il à .net? Pouvez-vous définir les limites de taille de segment de mémoire? Le CLR continue-t-il simplement à grossir jusqu'à atteindre les limites physiques de la machine? Ou n'est-ce pas un problème dans .net pour une raison subtile que mes clignotants Java m'empêchent de voir?

Answer 1

Vous ne pouvez pas définir la taille maximale de segment de mémoire dans .Net sauf si vous hébergez vous-même le CLR dans un processus.

Modifier: Pour contrôler les allocations de mémoire du CLR, y compris la taille maximale du segment de mémoire, vous devez utiliser l’API d’hébergement pour héberger la CLR et utiliser plus particulièrement les "interfaces du gestionnaire de mémoire". Vous trouverez quelques informations de base ici Magazine MSDN, colonne CLR Inside Out: API d’hébergement CLR

Modifier: pour répondre à votre question, pourquoi voudriez-vous contrôler l'allocation de mémoire ou plus précisément la taille maximale de segment de mémoire, vous ne voulez généralement pas, mais si vous écrivez une application qui est comme SQL Server ou IIS ou une application en temps réel, vous auriez une très bonne raison de contrôler la mémoire et d'éviter la pagination, sinon le CLR et le système d'exploitation font déjà un très bon travail pour vous, et ce qu'il en reste est de veiller à ce que votre application utilise un minimum de ressources pour que tout fonctionne correctement.

Answer 2

Non, cela ne s'applique pas à .NET. Le tas continue en effet de croître jusqu'à ce qu'il ne puisse plus grandir. (Évidemment, c’est "après avoir tenté de récupérer de la mémoire via GC, développez le tas"). En gros, il n’existe pas autant de réglages possibles dans le GC .NET que dans Java. Vous pouvez choisir le serveur GC ou le client, et je pense qu’il existe une option pour activer / désactiver le GC simultané (je trouverai des liens dans une minute), mais c’est tout.

EDIT: Il semble y avoir un peu plus, mais pas beaucoup. Entrée de blog de Rick Minerich sur les paramètres du GC et le suivant semble connaitre un peu plus que moi à ce sujet. C’est probablement un bon point de départ pour toute enquête ultérieure, mais ce sont surtout des drapeaux plutôt que le type de limites de mémoire disponibles dans les machines virtuelles.

EDIT: La réponse de Pop soulève un bon point: je suppose un "normal". Modèle d'hébergement CLR (c'est-à-dire non sous votre contrôle). Si vous souhaitez vous-même héberger vous-même, vous aurez probablement beaucoup plus de contrôle, au détriment du travail supplémentaire nécessaire. Je ne peux pas dire que j'ai déjà regardé de ce côté.

Answer 3

Vous pourriez vouloir consulter System.Runtime.MemoryFailPoint .

Answer 4

D'après ce que j'ai trouvé, il n'y a pas de moyen simple de contrôle la taille du segment de mémoire d'une application .Net à l'aide du CLR.

Le lien ci-dessus ne répond que partiellement à la question. Lorsque j'ai étudié le même problème, la réponse est "Le segment de mémoire grandit pour utiliser toute la mémoire disponible". comme si c’était la seule raison pour laquelle vous souhaitiez contrôler la taille maximale du tas.

Sur les environnements de serveur (généralement Java), vous ne voulez pas qu'une application qui se comporte mal puisse conserver de la mémoire au détriment des autres applications hébergées. Une solution simple consiste à limiter la quantité de mémoire que l'application peut utiliser pour son tas. Ceci est accompli avec l'argument -Xmx de Java afin que vous puissiez garantir que l'application n'en utilisera pas plus que ce qui est prévu, par exemple. -Xmx256M. Étant donné que l'allocation de mémoire sur le segment de mémoire pendant l'initialisation peut ralentir le démarrage des applications, Java utilise l'argument -Xms pour permettre aux applications qui créent beaucoup d'objets lors de l'initialisation de démarrer avec un bloc de segment important au lieu de la JVM redimensionnant en continu le segment va.

Le CLR de .Net n’a pas cette capacité. Je suppose que c'est parce que le CLR de .Net n'est pas une machine virtuelle. Le CLR se trouve être une API (très complète, pourrais-je ajouter) qui sert d’adaptateur aux fichiers .dll natifs, ce qui équivaut à une approche beaucoup plus semblable à un exécutable en matière de gestion de la mémoire.

J'ai posé cette question sur le développement de SharePoint et entendu qu'il était peut-être possible de contrôler la taille énorme en utilisant des modules IIS appelés Web Apps, ce qui vous permet d'indiquer à IIS de limiter la mémoire d'une application Web donnée. Je me demande si cela est dû au fait que IIS a des routines personnalisées qui remplacent / annulent new () / malloc () / etc et peuvent donc fournir ce type de contrôle aux applications clientes. Cela signifie que les applications .Net autonomes n’ont plus de chance, sauf si vous souhaitez écrire un gestionnaire de mémoire personnalisé en C ++ et créer une interface pour .Net