Algumas questões que coloco abaixo foram resolvidas, outras não, mas são menos i · maniero

Em resposta a Entender memória é o próximo passo (e o mais importante)

Algumas questões que coloco abaixo foram resolvidas, outras não, mas são menos importantes.

Eu levei um susto quando vi o exemplo que estava comentando como BOM. Depois eu vi que explica que é o que o pessoal posta e de fato é uma solução pior em quase todos critérios, especialmente no gerenciamento de memória. O BOM faz zero alocações dinãmicas, e uma automática (o parâmetro) e algumas alocações estáticas. O RUIM faz como extra uma alocação dinâmica.

O artigo é interessante, parabéns por levantar a questão.

Mas tenho que corrigir o que está falho ou pode ser mal interpretado. Propositalmente não vou falar de todos os detalhes, o assunto é vasto.

Boa parte das linguagens não precisam ter conhecimento do tamanho do objeto para alocar na pilha. Java precisa, no momento, isso pode ser mudado. Se a intenção era falar especificamente de Java, está certo, mas não ficou claro. Todas as linguagens que alcançam um nível um pouco mais baixo, até mesmo C#, consegue alocar na stack sabendo o tamanho apenas no momento.

Quando fala em requisito e diz que "de preferência", não é requisito. E na verdade, não só não é um requisito como muito objeto na pilha tem um tempo de vida bastante longo, até mesmo por toda aplicação, especialmente na função de entrada. O requisito é sobre o objeto precisar sobreviver ao fim do escopo. Vou deixar links onde explico todos esses conceitos.

Em "na memória liberada" dito ali acho que queria dizer memória alocada.

Há uma confusão sobre tipos por valor serem liberados quando saem de escopo. Existem tipos por valor que são liberados pelo GC, afinal se um objeto está no heap e ele contém objetos por valor dentro dele, é o GC que o libera, não é sobre o escopo. Tipo por valor é diferente de objeto alocado na stack. Tipos por valores podem estar nas duas áreas.

Tipos por referência também podem estar nas duas áreas, não só no heap. Algumas linguagens limitam ao heap. Java não limita, mas favorece muito. Tanto não limita que tem implementações que o JITter é capaz de alocar uma classe, portanto um tipo por referência, na stack, como otimização. Isso não acontece muito, mas é possível. O programador não tem controle sobre isso. C#/.NET ainda não faz isso por gerar bem menos lixo e ter mais controle sobre a alocação de memória do que Java, mas nada impede de um dia ter.

Objetos alocados na stack são liberados quando sai do escopo. Objetos no heap duram até que o código ou o runtime (GC) mande liberar. Então eles podem até ter o tempo de vida definido de acordo com a execução, por isso chama-se memória dinâmica.

Como adendo, a memória das strings fixas, como as usadas nos códigos exemplo, não ficam nem no heap, nem na stack, ficam em memória estática e duram por toda a aplicação, a alocação é feita já na carga do executável.

Não sei se entendi bem o que quis dizer com "chamadas de função ocupam espaço na memória". Pelo que entendi, isso não é verdade. A chamada em si não ocupa espaço de memória algum (a não ser a memória para o código que faz a chamada, uma instrução), o que vai ocupar memória é a alocação dos objetos que estão no escopo da função chamada, e só assim pode acontecer o stack overflow, uma função que não aloca não tem esse problema. Pelo menos é assim em quase todas as linguagens.

Em geral os sistemas operacionais não impõem limite de tamanho para a stack de cada thread e todas podem ser configuradas durante a sua criação (a principal na carga). No Windows, até a última vez que eu vi, o padrão era 1MB, mas nada impede de criar com 4KB ou 4GB. É possível até ultrapassar esse limite.

Para alocar no heap, que costuma na maioria das linguagens, mas não necessariamente precisa ser compartilhado pelas threads, os objetos precisam ter tamanho conhecido no momento da alocação e não podem variar (sendo pedante). Seria fisicamente muito complicado dar variabilidade no tamanho do objeto. Pense em um caminhão onde os pacotes dentro dele podem mudar de tamanho, para onde vão os pacotes que estão do lado dele? É uma questão bem concreta. Por isso não pode encher até a boca caminhão tanque. E assim os motoristas roubam(vam) combustível, tirando uma parte e deixando o caminhão no sol para dar o mesmo volume (por isso hoje se mede a temperatura quando vai descarregar). Objetos na memória não são líquidos.

O tempo de vida do objeto no heap pode ser conhecido, o ideal até é que seja em tempo de compilação, e por sorte a maioria é. É mais complicado ainda quando só se conhece no momento da execução. Por isso o GC existe, ele facilita muito isso, e de forma segura. Quando há um GC não determinístico, caso da maioria das linguagens, então o tempo de vida importa menos, mas ainda importa. Em um GC determinístico, ou se sabe quando vai liberar a memória, ou tem um controle bem mais estrito de quando vai liberar (usa uma contagem de referência - algumas pessoas consideram esse tipo de GC como semi determinístico).

A única forma do tipo ter um tamanho determinado apenas no momento da alocação é ser uma coleção (um array). Em algumas linguagens é possível ter um array dentro de um outro tipo (uma classe por exemplo), o que fará que esse novo tipo tenha o tamanho variável em relação à sua criação, nunca depois. Pelo menos nunca vi linguagem que fugisse disso.

Alocar no heap é pior para a eficiência da execução e consumo de memória, sempre, até mesmo com gerenciamento manual de memória. Em alguns casos, ao contrário da crença popular, é possível ser pior fazendo manual do que com GC. O GC não pode ser sempre culpado pela ineficiência. Em muitos casos o GC piorará, e provavelmente gerará pausa de forma não determinística, que pode ser ruim em certos cenários.

O GC não manipula a tal da memória privada (não gosto do nome já que o heap também pode ser privado), ele só é necessário no heap se não quiser o gerenciamento manual. Na pilha o gerenciamento é sempre automático, por isso essa memória chama-se automática.

Existem GCs que pausam por tempo limitado, e o programador consegue minimizar isso também se ele souber usar corretamente todas essas coisas que estamos falando aqui.

Linguagens com GC são usadas em jogos de "tempo real", em locais de alta eficiência como o site Stack Overflow. Basta saber fazer. Nem todo mundo sabe, aí precisa achar outro tipo de solução. É tipo microsserviço, a pessoa não sabe fazer eficiente, então ela resolve quebrar em vários serviços para dar conta, ficando absurdamente mais caro e mais difícil de gerenciar e manter. O site SO não sofre com pausas, inclusive porque o GC avisa que vai coletar e pode tirar aquele nó do load balancer durante a pausa, que costuma ser de poucos milissegundos, nos piores casos, a maioria fica na casa dos poucos microssegundos.

Sem o GC não é de graça, ele não costuma dar pausas grandes, mas na soma total tem casos que consome mais tempo que o garbage collector.

Alocações no heap desnecessárias podem destruir a performance da aplicação. O GC pode agravar isso, mas nem sempre. Java e C# têm GCs muito modernos que são melhores em alguns cenários do que fazer em C, C++ ou Rust (ele aloca essencialmente no mesmo tempo que na stack que é muito rápida - só move um ponteiro, enquanto nas linguagens de mais baixo nível a alocação pode custar bem caro por ter que buscar um lugar para alocar). Claro que é possível fazer essas linguagens baterem C#, mas dá muito mais trabalho, você praticamente escreve um GC no seu código.

A explicação sobre as gerações do GC é sobre o .NET. Java é ligeiramente diferente, outras linguagens são bem diferentes, e não possuem gerações.

A Gen0 costuma levar microssegundos, a Gen1 não costuma passar de 1 milissegundo, e a Gen2 pode demorar bastante, mas a maior parte do tempo é feito em background e a pausa costuma ser bem pequena. As duas primeiras fazem uma cópia dos objetos sobreviventes para a próxima geração e a Gen2 faz o chamado mark & sweep (pelo menos algo muito parecido).

Todos os objetos precisam ser coletados pelo GC quando o heap é gerenciado por ele. Até existem linguagens que tem heap gerenciado e não gerenciado, mas é raro e não popular.

Chegando ao fim, quando a pessoa descobre o StringBuilder ela tende a abusar dele e fazer o código ficar ineficiente quando ele não é a melhor opção.

Usar algo que tem tamanho suficiente ajuda porque se precisar aumentar o tamanho do objeto, não pode, então a solução é criar um outro objeto maior em outro lugar e copiar os dados para esse novo lugar, e depois o GC terá que coletar o objeto velho. Isso pode gerar uma progressão geométrica e te destruir.

Depois veremos se o problema no exemplo que eu achei é o mesmo que outros acharam.

Se você não seguir todos os links (em recursão) não vai aprender. Eu sei que dá trabalho, mas é assim que evolui. Eu percebo que as pessoas clicam só no primeiro link. Essa é a diferença de que aprende e que patina (os que já sabem disso tudo são os que mais vão clicar, tô certo kht? Foi uma total perda de tempo ler isso mesmo já sabendo?).

Faz sentido para você?

Espero ter ajudado.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

tenshizer0

1 ano atrás

Muito bom os dois posts! Mas gostaria de corrigir um único ponto na resposta do maniero, onde ele fala sobre objetos não mudarem de tamanho na heap:

Para alocar no heap, que costuma na maioria das linguagens, mas não necessariamente precisa ser compartilhado pelas threads, os objetos precisam ter tamanho conhecido no momento da alocação e não podem variar (sendo pedante). Seria fisicamente muito complicado dar variabilidade no tamanho do objeto. Pense em um caminhão onde os pacotes dentro dele podem mudar de tamanho, para onde vão os pacotes que estão do lado dele? É uma questão bem concreta. Por isso não pode encher até a boca caminhão tanque. E assim os motoristas roubam(vam) combustível, tirando uma parte e deixando o caminhão no sol para dar o mesmo volume (por isso hoje se mede a temperatura quando vai descarregar). Objetos na memória não são líquidos.

Na realidade, em C, é possível alterar o tamanho de objetos alocados na heap em tempo de execução com o comando realloc().

void *realloc(void *ptr, size_t new_size);

O realloc recebe o endereço do objeto a ser redimensionado e o novo tamanho pra esse objeto. Caso consiga alterar o tamanho do objeto, ele retornará o mesmo endereço de memória, caso contrário, ele executará os passos a seguir:

Alocará um novo espaço de memória para o objeto;
Copiará o conteúdo atual do objeto para o novo espaço de memória;
Desalocará o espaço de memória anterior; e
Retornará o endereço do novo espaço de memória.

É bem mais fácil visualizar seu funcionamento com arrays, mas em C, essa operação pode ser feita com qualquer tipo de dados. Por exemplo, se alocarmos um array de int de 10 posições (40 bytes) e depois quisermos reduzir seu tamanho para 5 posições (20 bytes), é bem provável (uma "quase-certeza") que o endereço de memória retornado seja o mesmo, o array só ficou menor e deixou um espaço livre de 5 posições (20 bytes) ao seu lado.

Exemplo 1:

#include <stdio.h>
#include <stdlib.h>

int main() {
  int *array = malloc(10 * sizeof(int));
  printf("endereço anterior: %p\n", array);
  array = realloc(array, 5 * sizeof(int));
  printf("novo endereço:     %p\n", array);
  return 0;
}

Output do Exemplo 1:

endereço anterior: 0x1ccf2a0
novo endereço:     0x1ccf2a0

Obs: os endereços mudam em cada execução

Mas e se quisermos aumentar o tamanho do nosso array? Bom, às vezes ele vai alocar um novo espaço de memória, realizando toda a etapa de cópia do objeto pro novo espaço, como dito anteriormente, quando não houver espaço disponível ao seu redor. No exemplo a seguir, alocamos um array de 5 posições e depois tentamos redimensioná-lo para 10 posições, como "não existe" espaço livre ao seu redor, será retornado um novo endereço de memória.

Obs: usei "não existe" entre aspas porque existem detalhes sobre como o SO aloca esses espaços e como eles são expostos para o processo que não tenho conhecimento aprofundado pra explicar aqui

Exemplo 2:

#include <stdio.h>
#include <stdlib.h>

int main() {
  int *array = malloc(5 * sizeof(int));
  printf("endereço anterior: %p\n", array);
  array = realloc(array, 10 * sizeof(int));
  printf("novo endereço:     %p\n", array);
  return 0;
}

Output do Exemplo 2:

endereço anterior: 0x229c2a0
novo endereço:     0x229c6d0

Mas ele também pode reaproveitar espaços liberados por objetos que estavam na heap mas foram desalocados. Nesse caso, ele vai simplesmente alterar o tamanho do objeto e retornar o mesmo endereço. No próximo exemplo, são alocados dois arrays de 10 posições, depois o primeiro array é desalocado e, quando o segundo é redimensionado para 20 posições, o realloc() reaproveitará o espaço livre deixado pelo array desalocado.

Exemplo 3:

#include <stdio.h>
#include <stdlib.h>

int main() {
  puts("Alocação inicial");
  int *array1 = malloc(10 * sizeof(int));
  int *array2 = malloc(10 * sizeof(int));

  printf("array1: %p\n", array1);
  printf("array2: %p\n", array2);
  puts("");

  puts("Removendo array1 e realocando array2");

  free(array1);  // liberando o array1
  array1 = NULL; // atribuindo o ponteiro nulo pra ficar mais bonito no print :D
  array2 = realloc(array2, 20 * sizeof(int));

  printf("array1: %p\n", array1);
  printf("array2: %p\n", array2);

  return 0;
}

Output do Exemplo 3:

Alocação inicial
array1: 0x16836b0
array2: 0x16836e0

Removendo array1 e realocando array2
array1: (nil)
array2: 0x16836e0

Obs: se analisarem os endereços retornados, verão que eles não se crusam, mas novamente, isso é por conta de detalhes de como o SO expõe esses endereços da heap para o processo, que não tenho conhecimento suficiente pra explicar como funciona

Acredito que a maioria das linguagens não adota a estratégia do realloc por ser bem complicada de gerenciar. Acho que é como a herança múltipla em OOP, onde a maioria das linguagens prefere não permitir para mitigar possíveis problemas.

Espero que eu tenha contribuído pra discussão e que tenham gostado da explicação. Gostaria de saber onde estou errado também e, principalmente, sobre esses detalhes de como o SO expõe os endereços de memória pro processo.

maniero

Autor

1 ano atrás

Essa explicação cabe e está correta.

Vou tentar deixar mais claro o que eu disse. De fato existe uma situação que você pode interpretar que o objeto pode aumentar de tamanho, mas nada garante que isso vai acontecer.

Como o nome diz, o realloc() realoca o espaço onde estava o objeto, conforme meu texto expllica. Inclsuive essa função sequer modifica o objeto, só trata da alocação de memória. Ele copiará o dado para outro local, portanto terá um novo objeto. Em certo momento haverá os dois objetos na memória. Ele não mexe no objeto antigo de forma alguma.

Como agora provavelmente tem mais espaço (no exemplo que pediu para realocar para um espaço maior) então poderá fazer com que o novo objeto colocado ali será maior que o anterior. Mas é outro objeto, não é o mesmo. Pode ser idêntico, mas a cópia já garante que será outro objeto.

Conforme eu falei, é concreto. Se você tem um monte de caixas no caminhão, todas adjacentes às outras sem espaço algum sobrando entre elas, só tem espaço no fim do baú, se elas tinham 10cm3 e passa ter 12cm3, como isso é possível? O único jeito é pegar um outro espaço em local vazio para colcoar essa caixa maior, não dá para colocar onde estava aquele objeto, não tem espaço. Você pode até tirar a caixa menor de lá, mas o espaço ficará lá, até que alguém coloque outra caixa no mesmo lugar, mas essa nova caixa terá 10cm3 ou menos.

O realloc() realoca em todas as situações? Não tem nada que mande ele fazer isso, e de fato algumas implementações não mudam de lugar quando o que está pedindo de alocação tem o mesmo tamanho ou menor. Para tamanhos maiores é impossível fisicamente não mudar de lugar, a não ser que se saiba que tem um espaço sobrando ali. Nem sempre se sabe, mas se souber também é uma situação que poderá não mudar de lugar.

Só note que isso é uma otimização, não é garantido que aconteça. Se você pediu um espaço maior e conseguiu deixar no mesmo lugar você já tinha o espaço maior.

Então se você tiver espaço entre as caixas é possível colocar uma caixa maior que caiba no espaço deixado ali. Sempre será feito assim? Não. Não é problema seu se vai acontecer ou não, não conte com isso, interprete que sempre haverá a relocação da caixa. Nunca conte que seja assim só porque fez um teste e deu esse resultado.

Fiat 147 todo detonado andando pelas ruas

O realloc() sequer é sobre o objeto e sim sobre a alocação. Em C a alocação e o objeto quase se confudem. Se você tem o espaço para aumentar o objeto pode interpretar que o tamanho real do objeto é todo o espaço disponível e ele não é aumentado. O aumento real só ocorre quando se cria uma nova alocação/objeto.

Inclusive nada impede de você aumentar o tamanho do objeto sem o realloc(). C tem dessas. Só que eu não considero isso porque você está corrompendo a memória e potencialmente está sobrescrevendo em cima de outro objeto.

Se eu não posso garantir que será sempre assim, eu prefiro considerar que o aumento só ocorre, garantidamente, criando um novo objeto, o resto é lucro.

tropicalmewtwo

1 ano atrás

Boa parte das linguagens não precisam ter conhecimento do tamanho do objeto para alocar na pilha. Java precisa, no momento, isso pode ser mudado. Se a intenção era falar especificamente de Java, está certo, mas não ficou claro. Todas as linguagens que alcançam um nível um pouco mais baixo, até mesmo C#, consegue alocar na stack sabendo o tamanho apenas no momento.

Boa, aqui estava querendo falar de "tempo de alocação", vou corrigir.

Há uma confusão sobre tipos por valor serem liberados quando saem de escopo. Existem tipos por valor que são liberados pelo GC, afinal se um objeto está no heap e ele contém objetos por valor dentro dele, é o GC que o libera, não é sobre o escopo

Boa, não tratei de casos em que os tipos de valor estão atrelados a um tipo de referência e tem um lifetime maior. Nesse caso realmente é o GC que trata de liberá-los.

No post tentei dissociar completamente os dois tipos de tipos, por brevidade.

Como adendo, a memória das strings fixas, como as usadas nos códigos exemplo, não ficam nem no heap, nem na stack, ficam em memória estática e duram por toda a aplicação, a alocação é feita já na carga do executável.

Boa, isso é algo que não tratei no artigo, infelizmente não dá pra entrar em todos os detalhes.

No C#, e outras linguagens, além da memória estática existe a string pool, que evita a alocação desnecessária de strings quando possível.

O tempo de vida do objeto no heap pode ser conhecido, o ideal até é que seja em tempo de compilação, e por sorte a maioria é

De fato, como exemplo tipos de referência que não tem a referência propagada e perdem escopo ao sair do local que o instanciou. Não queria dar a entender que objetos no heap nunca vão ter um lifetime definido.

Em geral os sistemas operacionais não impõem limite de tamanho para a stack de cada thread e todas podem ser configuradas durante a sua criação (a principal na carga). No Windows, até a última vez que eu vi, o padrão era 1MB, mas nada impede de criar com 4KB ou 4GB. É possível até ultrapassar esse limite.

Isso é outra coisa em que falhei em dizer que o limite padrão, mas como disse, pode ser configurado. Falhei também nos 2MB, para processos de 64bit está em 4MB.

Linguagens com GC são usadas em jogos de "tempo real", em locais de alta eficiência como o site Stack Overflow. Basta saber fazer.

Com certeza, o intuito aqui não é criticar o GC ou implementação específica de algum GC. Mas é evidente que, em busca de performance, é necessário facilitar seu trabalho

Usar algo que tem tamanho suficiente ajuda porque se precisar aumentar o tamanho do objeto, não pode, então a solução é criar um outro objeto maior em outro lugar e copiar os dados para esse novo lugar, e depois o GC terá que coletar o objeto velho. Isso pode gerar uma progressão geométrica e te destruir.

Assumo que isso ainda seja sobre o StringBuilder. É verdade, e o benefício dele começa a vir quando o custo de "gerar" a string final e seu processo é maior que o custo do SB em si.

Concordo que o post ficou muito específico para o C#, e não evidencio isso o suficiente, outra alteração que vou fazer.

Valeu por entrar mais em detalhes sobre as especificidades de stack e heap, e também sobre os tempos de execução e algoritmos do GC