VT2018 GCeasy-synthese

Auteur

• Nom : GENTILLON Loris
• Mail : gentillon.loris@gmail.com
• Sujet : GCeasy - Java Garbage Collector

Résumé

Afin de détecter des problèmes de performances et de taille mémoire, une analyse des fichiers de log que génère une JVM lors de son exécution peut se révéler intéressant. GCeasy permet cette analyse, en local comme en SaaS, sur un fichier de log comme sur plusieurs via son API REST.

Abstract

In order of detecting perfomance and memory issues of a Java JVM, one can use a log analyzer on the java garbage collector log. GCeasy allows that in a fancy, shiny way. You can either use their webpage as a SaaS, or download your own instance of GCeasy (neither free nor libre). And, you can handle one file at a time, to get some graphics, or you can use their API to analyze hundreds of file and gather useful informaiton through json.

Key words

Java, JVM, Garbage Collector

Synthèse

GCeasy présente l'énorme avantage d'être très simple d'utilisation. Son interface web est claire et directe, et son API REST est très bien documentée. Cependant, l'utilisation de l'api nécessite de s'enregistrer au préalable sur leur site.

Objectifs

GCeasy vise à détecter différents problèmes que peuvent rencontrer l'exécution de programme Java :

• fuites mémoires (même si à proprement parler Java ne peut pas subir de fuites mémoires, on parlera ici d'objets que le GC ne peut nettoyer)
• lenteurs (dues au GC qui s'exécute trop souvent, suite à des tentatives d'allocation mémoire infructueuse)

Simulations

Simulation 1

https://gist.github.com/dpryden/b2bb29ee2d146901b4ae

L'objectif de cette simulation est de générer une fuite mémoire, en utilisant un ClassLoader défectueux.

Pour utiliser le code et constater la fuite :

• Créer un fichier ClassLoaderLeakExample.java, n'importe ou sur le système et c/c le code du lien ci dessus
• Compiler le fichier : javac ClassLoaderLeakExample.java
• Executer le bytecode (en enregistrant les logs du GC) : java -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:LOGFILE.log ClassLoaderLeakExample
• (eventuellement rajouter un petit top/htop/gtop en parallèle pour constater les dégâts)

import java.io.IOException;
import java.net.URLClassLoader;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.nio.file.Path;

/**
 * Example demonstrating a ClassLoader leak.
 *
 * <p>To see it in action, copy this file to a temp directory somewhere,
 * and then run:
 * <pre>{@code
 *   javac ClassLoaderLeakExample.java
 *   java -cp . ClassLoaderLeakExample
 * }</pre>
 *
 * <p>And watch the memory grow! On my system, using JDK 1.8.0_25, I start
 * getting OutofMemoryErrors within just a few seconds.
 *
 * <p>This class is implemented using some Java 8 features, mainly for
 * convenience in doing I/O. The same basic mechanism works in any version
 * of Java since 1.2.
 */
public final class ClassLoaderLeakExample {

  static volatile boolean running = true;

  public static void main(String[] args) throws Exception {
    Thread thread = new LongRunningThread();
    try {
      thread.start();
      System.out.println("Running, press any key to stop.");
      System.in.read();
    } finally {
      running = false;
      thread.join();
    }
  }

  /**
   * Implementation of the thread. It just calls {@link #loadAndDiscard()}
   * in a loop.
   */
  static final class LongRunningThread extends Thread {
    @Override public void run() {
      while(running) {
        try {
          loadAndDiscard();
        } catch (Throwable ex) {
          ex.printStackTrace();
        }
        try {
          Thread.sleep(100);
        } catch (InterruptedException ex) {
          System.out.println("Caught InterruptedException, shutting down.");
          running = false;
        }
      }
    }
  }
  
  /**
   * A simple ClassLoader implementation that is only able to load one
   * class, the LoadedInChildClassLoader class. We have to jump through
   * some hoops here because we explicitly want to ensure we get a new
   * class each time (instead of reusing the class loaded by the system
   * class loader). If this child class were in a JAR file that wasn't
   * part of the system classpath, we wouldn't need this mechanism.
   */
  static final class ChildOnlyClassLoader extends ClassLoader {
    ChildOnlyClassLoader() {
      super(ClassLoaderLeakExample.class.getClassLoader());
    }
    
    @Override protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException {
      if (!LoadedInChildClassLoader.class.getName().equals(name)) {
        return super.loadClass(name, resolve);
      }
      try {
        Path path = Paths.get(LoadedInChildClassLoader.class.getName()
            + ".class");
        byte[] classBytes = Files.readAllBytes(path);
        Class<?> c = defineClass(name, classBytes, 0, classBytes.length);
        if (resolve) {
          resolveClass(c);
        }
        return c;
      } catch (IOException ex) {
        throw new ClassNotFoundException("Could not load " + name, ex);
      }
    }
  }
  
  /**
   * Helper method that constructs a new ClassLoader, loads a single class,
   * and then discards any reference to them. Theoretically, there should
   * be no GC impact, since no references can escape this method! But in
   * practice this will leak memory like a sieve.
   */
  static void loadAndDiscard() throws Exception {
    ClassLoader childClassLoader = new ChildOnlyClassLoader();
    Class<?> childClass = Class.forName(
        LoadedInChildClassLoader.class.getName(), true, childClassLoader);
    childClass.newInstance();
    // When this method returns, there will be no way to reference
    // childClassLoader or childClass at all, but they will still be
    // rooted for GC purposes!
  }

  /**
   * An innocuous-looking class. Doesn't do anything interesting.
   */
  public static final class LoadedInChildClassLoader {
    // Grab a bunch of bytes. This isn't necessary for the leak, it just
    // makes the effect visible more quickly.
    // Note that we're really leaking these bytes, since we're effectively
    // creating a new instance of this static final field on each iteration!
    static final byte[] moreBytesToLeak = new byte[1024 * 1024 * 10];
  
    private static final ThreadLocal<LoadedInChildClassLoader> threadLocal
        = new ThreadLocal<>();
    
    public LoadedInChildClassLoader() {
      // Stash a reference to this class in the ThreadLocal
      threadLocal.set(this);
    }
  }
}

Simulation 2

https://github.com/Gazeka74/VT2018

Petit projet Eclipse, qui créé un certains nombre de threads, et chacun alloue un certain nombre de ressources qu'il ne libère pas.

Ne pas oublier de renseigner dans Eclipse les informations concernant la génération du fichier de log : (clic droit sur le projet - run as - run configuration - argument - jvm arguments)

• -XX:+PrintGCDetails
• -XX:+PrintGCDateStamps
• -Xloggc:LOGFILE.log

Exemple d'un rapport généré par GCeasy

(Le rapport, enregistré en pdf ne rend pas super bien, la version live via le site web de GCeasy est bien plus interractive) https://air.imag.fr/images/6/66/GCeasy-report-3.pdf