15 postagens marcadas com "memória"

Esta postagem no blog foi escrita por José Dapena Paz (Igalia), com contribuições de Jason Williams (Bloomberg), Ashley Claymore (Bloomberg), Rob Palmer (Bloomberg), Joyee Cheung (Igalia) e Shu-yu Guo (Google).

Nesta postagem sobre snapshots do heap do V8, falarei sobre alguns problemas de desempenho encontrados por engenheiros da Bloomberg e como os corrigimos para tornar a análise de memória do JavaScript mais rápida do que nunca.

O problema​

Engenheiros da Bloomberg estavam trabalhando no diagnóstico de um vazamento de memória em uma aplicação JavaScript. A aplicação estava falhando com erros de Out-Of-Memory. Para a aplicação testada, o limite do heap do V8 foi configurado para cerca de 1400 MB. Normalmente, o coletor de lixo do V8 deveria ser capaz de manter o uso do heap abaixo desse limite, então as falhas indicavam que provavelmente havia um vazamento.

É absolutamente idiota ter ponteiros de 64 bits quando eu compilo um programa que utiliza menos de 4 gigabytes de RAM. Quando esses valores de ponteiros aparecem dentro de uma estrutura, eles não apenas desperdiçam metade da memória, mas também efetivamente descartam metade do cache.

– Donald Knuth (2008)

Segurança da memória no Chrome é um esforço contínuo para proteger nossos usuários. Estamos constantemente experimentando diferentes tecnologias para nos manter à frente de agentes maliciosos. Sob esse espírito, esta publicação fala sobre nossa jornada no uso de tecnologias de varredura de heap para melhorar a segurança de memória no C++.

No passado, já falamos muito sobre coleta de lixo para JavaScript, o modelo de objetos de documentos (DOM) e como tudo isso é implementado e otimizado no V8. No entanto, nem tudo no Chromium é JavaScript, já que a maior parte do navegador e de seu mecanismo de renderização Blink, onde o V8 está embutido, são escritos em C++. O JavaScript pode ser usado para interagir com o DOM, que é então processado pelo pipeline de renderização.

Há uma batalha constante entre memória e desempenho. Como usuários, gostaríamos que as coisas fossem rápidas e consumissem o menor espaço de memória possível. Infelizmente, normalmente melhorar o desempenho tem um custo no consumo de memória (e vice-versa).

No final de 2018, começamos um projeto chamado V8 Lite, com o objetivo de reduzir drasticamente o uso de memória do V8. Inicialmente, este projeto foi concebido como um modo Lite separado do V8, focado especificamente em dispositivos móveis com pouca memória ou em cenários de uso que priorizam uma menor utilização de memória em vez da velocidade de execução. No entanto, durante o desenvolvimento, percebemos que muitas das otimizações de memória feitas para este modo Lite poderiam ser implementadas no V8 regular, beneficiando todos os seus usuários.

Ao longo dos últimos anos, o coletor de lixo (GC) do V8 mudou bastante. O projeto Orinoco transformou um coletor de lixo sequencial e de pausa total em um coletor em grande parte paralelo e concorrente com fallback incremental.

Este post descreve a técnica de coleta de lixo chamada marcação concorrente. A otimização permite que uma aplicação JavaScript continue a execução enquanto o coletor de lixo escaneia o heap para encontrar e marcar objetos vivos. Nossos benchmarks mostram que a marcação concorrente reduz o tempo gasto marcando na thread principal em 60%–70%. A marcação concorrente é a última peça do projeto Orinoco — o projeto para substituir incrementalmente o antigo coletor de lixo pelo novo coletor de lixo principalmente concorrente e paralelo. A marcação concorrente está habilitada por padrão no Chrome 64 e Node.js v10.

Depurar vazamentos de memória no Chrome 66 ficou muito mais fácil. As DevTools do Chrome agora podem rastrear e fazer snapshot de objetos DOM C++ e exibir todos os objetos DOM alcançáveis a partir do JavaScript com suas referências. Este recurso é um dos benefícios do novo mecanismo de rastreamento em C++ do coletor de lixo V8.

Os objetos JavaScript no V8 são alocados em um heap gerenciado pelo coletor de lixo do V8. Em postagens anteriores no blog, já falamos sobre como reduzir os tempos de pausa na coleta de lixo (mais de uma vez) e o consumo de memória. Nesta postagem, apresentamos o Scavenger paralelo, um dos últimos recursos do Orinoco, o coletor de lixo majoritariamente concorrente e paralelo do V8, e discutimos decisões de design e abordagens alternativas que implementamos ao longo do caminho.