Estamos trabalhando em um aplicativo de negócios (1 milhão + LOC) desenvolvido há mais de 10 anos. Ao mudar para o JDK8, temos um problema com o metasspace do JDK8. Isso parece estar relacionado à versão JaxB mencionada em com.sun.xml.ws:webservices-rt:1.4 (Metro 1.4). Devido ao intenso vínculo no aplicativo e à criação herdada de classes / instâncias via JaxB, não é fácil alternar rapidamente as bibliotecas antigas.

Atualmente, estamos pesquisando esse problema. Criamos um programa de exemplo que reproduz esse comportamento:

import java.io.ByteArrayInputStream;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Unmarshaller;
import javax.xml.bind.annotation.XmlAttribute;
import javax.xml.bind.annotation.XmlRootElement;

@XmlRootElement
public class X
{
  private static final String XML = "<?xml version=\"1.0\" encoding=\"UTF-8\"?><x test=\"test\" />";

  @XmlAttribute
  String test;

  public static void main( String[] args ) throws JAXBException, InterruptedException
  {
    System.out.println("start");

    while ( true )
    {
      JAXBContext jc = JAXBContext.newInstance( X.class );
      Unmarshaller unmarshaller = jc.createUnmarshaller();
      X object = (X) unmarshaller.unmarshal( new ByteArrayInputStream( XML.getBytes() ) );
      System.out.println( object.test );
    }
  }
}

O JDK7 mantém o PermGenSpace limpo. (Simulado com 16M PermGen)Memória de execução com JDK7

Usando JDK8, o aplicativo é executado lentamente para a exceção OOM. O VisualVM captura a exceção e mantém o processo em execução no máximo de Metaspace disponível. Mesmo aqui, ele fica preso depois de um bom tempo rodando no max. (Simulado com 16M Metaspace)Memória de execução com JDK8

Alguém tem alguma idéia de como obter o comportamento herdado dos coletores de lixo, para não encontrarmos problemas de falta de memória? Ou você tem outras idéias de como lidar com esse problema?

Obrigado.

edit1:Execute os parâmetros JDK7:

-XX:+TraceClassLoading -XX:+TraceClassUnloading -XX:MaxPermSize=16M -XX:PermSize=1M -XX:+UseParallelOldGC -XX:+HeapDumpOnOutOfMemoryError

=> Nenhum dump de pilha é criado

Execute os parâmetros JDK8:

-XX:+TraceClassLoading -XX:+TraceClassUnloading -XX:MaxMetaspaceSize=16M -XX:MetaspaceSize=1M -XX:+UseParallelOldGC -XX:+HeapDumpOnOutOfMemoryError

=> despejos de pilha são gerados durante a execução.

A memória disponível do VisualVM não mostra o valor máximo real do metasspace. Se não limitado, o metasspace está aumentando constantemente até que a memória seja excedida.

editar 2:

Eu tentei todos os coletores de lixo disponíveis para o JDK8. Todos eles têm o mesmo problema.

editar 3:

Resolver trocando as bibliotecas é difícil em nossa aplicação real devido ao forte acoplamento entre JAXB e vários módulos de nossa aplicação. Portanto, é necessária uma correção para o comportamento do coletor de lixo a curto prazo. A longo prazo, a correção do suporte já está planejada.