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

Non, il ne s'applique pas dans .NET. Le tas, en effet, continuer de croître jusqu'à ce qu'il ne peut pas croître de plus. (Évidemment, c'est "après avoir tenté de récupérer la mémoire par le biais de GC, pousser le tas".) Fondamentalement, il n'y a pas presque autant de précision disponibles dans le .NET GC comme en Java. Vous pouvez choisir le serveur le GC ou le client, et je pense qu'il y a une option pour activer/désactiver la simultanées GC (je vais trouver des liens dans une minute), mais c'est principalement ça.

EDIT: Il semblerait qu'il y ait un peu plus à elle, bien que n'étant pas une somme énorme. Rick Minerich de l'entrée de blog sur GC paramètres et le suivant semblent en savoir plus que moi sur la question. Ils sont probablement un bon point de départ pour tout complément d'enquête - mais ils sont pour la plupart des drapeaux plutôt que le type de limites de la mémoire disponible dans la Jvm.

EDIT: Pop réponse soulève un bon point, j'ai été en supposant un "normal" CLR modèle d'hébergement (c'est à dire pas sous votre contrôle). Si vous voulez aller à l'effort de l'hébergement vous-même, vous êtes susceptible d'obtenir beaucoup plus de contrôle sur le coût de la surcharge de travail de l'hébergeant. Je ne peux pas dire que je n'ai jamais regardé ce côté des choses.

Autant que je l'ai trouvé, il n'y a pas de moyen simple de contrôle de la taille du segment de mémoire de un .Net application à l'aide de la CLR.

Le lien ci-dessus, la moitié seulement des réponses à la question. Quand j'ai recherché cette même question, la réponse est "Le tas pousse à utiliser toute la mémoire disponible", comme si c'est la seule raison pour laquelle vous voulez contrôler le max de la taille du segment.

(Habituellement Java) les environnements de serveur, vous ne voulez pas un mauvais fonctionnement d'application de porc de la mémoire au détriment d'autres applications hébergées. Une solution simple consiste à limiter la quantité de mémoire que l'application peut utiliser pour cela des tas de. Ceci est accompli avec de Java -Xmx argument de sorte que vous pouvez garantir l'application ne pas utiliser plus que ce qui est prévu, par exemple -Xmx256M. Depuis allouer de la mémoire sur le tas au cours de l'initialisation peut ralentir les applications de démarrage, Java utilise l'-Xms arg pour permettre à des applications qui fais beaucoup de création de l'objet lors de l'initialisation de commencer avec un gros bloc de mémoire au lieu de la JVM de l'ensemble de redimensionnement le tas comme il va.

.Net CLR n'ont pas cette capacité. Je soupçonne que c'est parce que .Net CLR n'est pas une machine virtuelle. Le CLR arrive à être une API (tout à fait complet, je pourrais ajouter) qui sert de carte de maternelle .dll qui correspond à une approche beaucoup plus comme un exécutable quand il s'agit de la gestion de la mémoire.

J'ai posé cette question sur le développement SharePoint et n'entendre qu'il pourrait être possible de contrôler la heapsize grâce à l'utilisation de modules IIS Web Apps, qui permet de dire IIS pour limiter la mémoire d'une application web. Je me demande si c'est parce que IIS a personnalisé des routines qui remplacer/remplacer new()/malloc()/etc et peut donc fournir ce type de contrôle pour applications client. Cela signifie que de manière autonome .Net applications sont hors de la chance, sauf si vous voulez écrire un personnalisé du gestionnaire de mémoire en C++ et de créer une interface pour .Net