Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

204
Visualizações
JVM garbage collection - tracing live objects in young generation

While collecting the young generation memory, JVM collectors scan only those root objects (obejcts in the heap directly accessible from the root set) that belong to the young generation and also use a write barrier backed card table/remembered set to determine regions of the old generation which could possibly contain objects that contain references to objects in the young generation.

The question that I have is that if the young collector determines that a particular object in the young generation only has a single external reference from an object in the old generation, how does it know if the old generation object itself is not garbage and thus making the young generation object 'live' and not eligible for collection? For example, there could be a path from the root set directly to this object in the old generation that in turn has a reference to the said young generation object. Does the young collector typically consider this young generation object as live or does it some how determine whether the old generation object pointing to it is live/garbage before deciding to ignore/collect it?

about 4 years ago · Santiago Trujillo
2 Respostas
Responde à pergunta

0

how does it know if the old generation object itself is not garbage?

It doesn't that is what a major/full collection is for. The assumption is that old gen object doesn't die often.

When a full collection is performed it checks all the objects, but when a minor/young collection is performed only the objects in the young collection are cleaned up.

about 4 years ago · Santiago Trujillo Relatório

0

The question is “how to you get to such a scenario?”

To create a reference from an old object to a young object, the old object must be reachable, as otherwise we can’t store a reference to the young object in it. In order to become unreachable afterwards, we have to modify at least either, a root reference or another old object that previously referenced the old object in question.

As you already mentioned, these kind of writes are tracked by the JVM, which is crucial, as in order to detect that an old object now references a young object, it must know that the memory area of the old object (aka card) has been modified. In principle, since card marking also implies remembering the incoming references, the gc is now capable of detecting that the old object became unreachable, even without a major gc. It only has to consider the modified card (or the root set) to learn about it. Whether it does, depends on environmental factors, like the chosen gc algorithm, i.e. whether you use CMS (won’t) or G1 (might), and how “mixed collections” are configured or the actual memory pressure.

Of course, if you use a concurrent collector, there is the possibility that the modification that will make the old object unreachable happens while a collection cycle is already ongoing. In this situation, it is possible that the young object is considered reachable during this gc cycle, even if it wasn’t if the modification happened just a nanosecond earlier.

about 4 years ago · Santiago Trujillo Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda