Mercurial > hg > graal-compiler
diff graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotGraphCache.java @ 7530:5e3d1a68664e
applied mx eclipseformat to all Java files
author | Doug Simon <doug.simon@oracle.com> |
---|---|
date | Wed, 23 Jan 2013 16:34:57 +0100 |
parents | 2463eb24b644 |
children | 063a712fe8d8 |
line wrap: on
line diff
--- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotGraphCache.java Wed Jan 23 16:34:38 2013 +0100 +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotGraphCache.java Wed Jan 23 16:34:57 2013 +0100 @@ -34,22 +34,24 @@ /** * This class implements the graph caching system for the HotSpot platform. - * - * This implementation does not use a map to store the actual cached graphs. The problem is that such maps keep the - * graph, and therefore the {@link ResolvedJavaMethod} referenced from the graph, alive. For some applications and benchmarks this - * is a problem, e.g., the DaCapoScala "scalatest" benchmark will quickly run out of perm gen because of this. - * - * This cannot be solved with a {@code WeakHashMap<ResolvedJavaMethod, Graph>}, since the values within the map will keep the keys - * alive. In order for this to work we would require a weak map in which the "strongness" of the value references - * depends upon the reachability of the keys. - * - * Therefore the graph cache is implemented in such a way that it stores its cache entries within the {@link ResolvedJavaMethod}. - * It uses the {@link ResolvedJavaMethod#getCompilerStorage()} map with the HotSpotGraphCache instance as key. - * The cached graph will be kept alive as long as the {@link ResolvedJavaMethod} is alive, but does not prevent the method, and - * therefore the class, from being unloaded. - * - * The {@link #cachedGraphIds} map is used to find the graphs that should be removed because of deoptimization, and to - * enforce the graph cache size restriction. + * + * This implementation does not use a map to store the actual cached graphs. The problem is that + * such maps keep the graph, and therefore the {@link ResolvedJavaMethod} referenced from the graph, + * alive. For some applications and benchmarks this is a problem, e.g., the DaCapoScala "scalatest" + * benchmark will quickly run out of perm gen because of this. + * + * This cannot be solved with a {@code WeakHashMap<ResolvedJavaMethod, Graph>}, since the values + * within the map will keep the keys alive. In order for this to work we would require a weak map in + * which the "strongness" of the value references depends upon the reachability of the keys. + * + * Therefore the graph cache is implemented in such a way that it stores its cache entries within + * the {@link ResolvedJavaMethod}. It uses the {@link ResolvedJavaMethod#getCompilerStorage()} map + * with the HotSpotGraphCache instance as key. The cached graph will be kept alive as long as the + * {@link ResolvedJavaMethod} is alive, but does not prevent the method, and therefore the class, + * from being unloaded. + * + * The {@link #cachedGraphIds} map is used to find the graphs that should be removed because of + * deoptimization, and to enforce the graph cache size restriction. */ public class HotSpotGraphCache implements GraphCache { @@ -62,8 +64,9 @@ private volatile long putCounter; /** - * An ordered hash map for looking up the methods corresponding to a specific graph id. It enforces the maximum - * graph cache size by removing the oldest (in insertion-order) element if the cache gets too big. + * An ordered hash map for looking up the methods corresponding to a specific graph id. It + * enforces the maximum graph cache size by removing the oldest (in insertion-order) element if + * the cache gets too big. */ private final class LRUCache extends LinkedHashMap<Long, WeakReference<ResolvedJavaMethod>> {