Unloading LambdaForm bytecode
Martin Traverso
mtraverso at gmail.com
Mon Sep 8 23:54:41 UTC 2014
Do the generated bytecodes for LambdaForms ever get unloaded? In Presto (a
distributed SQL engine) we generate bytecode on the fly for each query and
use invokedynamic in a number of places as a way to link constants. We
recently ran into a permgen leak (we run 7u45). Looking at the output of
-verbose:class, I noticed a bunch of lines like these:
[Loaded java.lang.invoke.LambdaForm$MH227/995942612 from
java.lang.invoke.LambdaForm]
[Loaded java.lang.invoke.LambdaForm$MH228/489675590 from
java.lang.invoke.LambdaForm]
[Loaded java.lang.invoke.LambdaForm$MH229/2095286826 from
java.lang.invoke.LambdaForm]
[Loaded java.lang.invoke.LambdaForm$MH230/538456879 from
java.lang.invoke.LambdaForm]
[Loaded java.lang.invoke.LambdaForm$MH231/1550961803 from
java.lang.invoke.LambdaForm]
...
We load our generated bytecode in standalone classloaders and it eventually
gets unloaded. I never see an unload message for the LambdaForm classes,
though.
This is what’s inside one of those classes. They all look similar:
> javap -c 'LambdaForm$MH499.class'
Compiled from "LambdaForm$MH499"
final class java.lang.invoke.LambdaForm$MH499 extends
java.lang.invoke.LambdaForm {
static java.lang.Object identity(java.lang.Object);
Code:
0: aload_0
1: checkcast #12 // class
java/lang/invoke/BoundMethodHandle$Species_L
4: getfield #16 // Field
java/lang/invoke/BoundMethodHandle$Species_L.argL0:Ljava/lang/Object;
7: astore_1
8: ldc #18 // String
CONSTANT_PLACEHOLDER_0 <<MethodHandle(Object)Object>>
10: checkcast #20 // class
java/lang/invoke/MethodHandle
13: aload_1
14: invokevirtual #23 // Method
java/lang/invoke/MethodHandle.invokeBasic:(Ljava/lang/Object;)Ljava/lang/Object;
17: areturn
static void dummy();
Code:
0: ldc #27 // String
identity=Lambda(a0:L)=>{\n t1:L=Species_L.argL0(a0:L);\n
t2:L=ValueConversions.identity(t1:L);t2:L}
2: pop
3: return
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20140908/5e04e057/attachment.html>
More information about the mlvm-dev
mailing list