Posso (e eu sempre quero) definir o tamanho máximo da pilha no .NET?

Question

Vindo de um fundo Java, uma das coisas com as quais estou acostumada é dizer à JVM qual deve ser o tamanho máximo da pilha. Se o programa em execução tentar engolir mais do que é permitido, e o coletor de lixo não puder liberar mais recursos, o OutfMemoryError será jogado e tudo vai bater. Portanto, definir o tamanho máximo da pilha é importante em Java.

Isso se aplica no .NET? Você pode definir os limites de tamanho de heap? O CLR continua crescendo até chegar aos limites físicos da máquina? Ou não é um problema no .NET por algum motivo sutil que meus piscos de java me impedem de ver?

Answer 1

Você não pode definir o tamanho máximo da pilha no .NET, a menos que hospede o CLR em um processo.

EDIT: Para controlar as alocações de memória do CLR, incluindo o tamanho máximo da pilha, você precisa usar a API de hospedagem para hospedar o CLR e usar especificamente as "interfaces do gerenciador de memória", algumas informações iniciais podem ser encontradas aqui Revista MSDN, coluna CLR Inside Out: CLR Hosting APIs

Editar: Para responder à pergunta, por que você deseja controlar a alocação de memória ou especificamente o tamanho da pilha, geralmente não quer, mas E se Você está escrevendo um aplicativo como o SQL Server ou o IIS ou algum aplicativo em tempo real, então você terá um bom motivo para ter controle sobre a memória e, especificamente O trabalho para você e o que resta é garantir que você use o aplicativo mínimo para que as coisas funcionem bem.

Answer 2

Não, ele não se aplica ao .NET. O heap realmente continua crescendo até que não possa mais crescer. (Obviamente, isso é "depois de tentar recuperar a memória através do GC, crescer a pilha".) Basicamente, não há quase tanta afinação disponível no .NET GC como em Java. Você pode escolher o servidor GC ou o cliente, e acho que há uma opção para ligar/desligar o GC simultâneo (encontrarei links em um minuto), mas é basicamente isso.

EDIT: Parece que há um pouco mais, embora não seja uma quantidade enorme. Entrada no blog de Rick Minerich nas configurações do GC e o subsequente Parece saber mais do que eu sobre o assunto. Eles provavelmente são um bom ponto de partida para qualquer investigação adicional - mas são principalmente sinalizadores e não o tipo de limites de memória disponíveis no JVMS.

EDIT: A resposta do pop levanta um bom ponto - eu tenho assumindo um modelo de hospedagem CLR "normal" (ou seja, não sob seu controle). Se você quiser se esforçar para hospedá -lo, provavelmente terá muito mais controle - com o custo do trabalho extra de hospedá -lo. Não posso dizer que já olhei para esse lado das coisas.

Answer 3

Você pode querer olhar para System.Runtime.MemoryFailPoint.

Answer 4

Tanto quanto eu descobri, não há maneira simples de Controle o tamanho da pilha de um aplicativo .NET usando o clr.

O link acima apenas metade responde à pergunta. Quando pesquisei esse mesmo problema, a resposta é "o pilheiro cresce para usar toda a memória disponível" como se esse fosse o único motivo pelo qual você deseja controlar o tamanho máximo da pilha.

Em ambientes de servidores (normalmente Java), você não deseja que um aplicativo com se comportar muito para HOG Memory às custas de outros aplicativos hospedados. Uma solução simples é limitar a quantidade de memória que o aplicativo pode usar para sua pilha. Isso é realizado com o argumento -xmx do Java, para que você possa garantir que o aplicativo não use mais do que o planejado, por exemplo, xmx256m. Como alocar a memória na pilha durante a inicialização pode retardar a startup de aplicativos, o Java usa o -xms arg para permitir aplicativos que façam muita criação de objetos durante a inicialização para começar com um grande bloco de heap em vez da JVM que redimensiona o heap à medida que ele vai.

O CLR do .NET não tem essa capacidade. Suspeito que seja porque o CLR da .NET não é uma máquina virtual. O CLR é uma API (bastante abrangente, devo acrescentar), que serve como um adaptador para .dlls nativos que equivalem a uma abordagem muito mais como um executável quando se trata de gerenciamento de memória.

Fiz essa pergunta sobre o desenvolvimento do SharePoint e ouvi dizer que seria possível controlar o aumento do uso do uso de módulos do IIS chamados aplicativos da Web, nos quais você pode dizer ao IIS para limitar a memória de um determinado aplicativo da Web. Gostaria de saber se isso ocorre porque o IIS possui rotinas personalizadas que substituem/substituem novos ()/malloc ()/etc e, portanto, podem fornecer esse tipo de controle aos aplicativos do cliente. Isso significa que os aplicativos .NET independentes estão sem sorte, a menos que você queira escrever um gerenciador de memória personalizado no C ++ e criar uma interface para .NET