java8 metaspace issue

[Brian Harris]

This toy example was meant to be a reproduction of real OOME we're getting
in JVM where MaxMetaspaceSize is not set and heap dumps suggest uncleared
soft references to objects in metaspace as being the cause.
If you're right and this really only happens when metaspace is capped super
low, then it's a false reproduction. But if there's a deeper problem and
the metaspace cap simply reveals in the toy example the same underlying
issue we're hitting in prod, I'd hope that could be investigated.

On Thu, May 14, 2015 at 5:41 PM, Bernd <ecki at zusammenkunft.net> wrote:

> You can try to turn on tracing of inlining and compilation. The JITed code
> can need space in the meta generation and can be caused by repeating code
> till it becomes hot enough. And 10mb is really small, anyway.
>
> Gruss
> Bernd
> Am 15.05.2015 02:35 schrieb "Brian Harris" <brianfromoregon at gmail.com>:
>
>> Yes I should have said OOME instead of 'crash'. Indeed when setting
>> -XX:MaxMetaspaceSize=20m the program does not throw OOME.
>>
>> Appears to be a boundary case jvm bug that this will throw OOME when -XX:MaxMetaspaceSize=10m
>> after going through the loop 890 times. Otherwise, how else can the OOME be
>> explained given we're using soft refs?
>>
>> On Tue, May 5, 2015 at 2:05 AM, Bengt Rutisson <bengt.rutisson at oracle.com
>> > wrote:
>>
>>>
>>> Hi Brian,
>>>
>>> On 2015-05-05 05:17, Brian Harris wrote:
>>>
>>> Hi,
>>>
>>>  I find that this code crashes in 8u40 after getting up to about 900
>>> when run with -XX:MaxMetaspaceSize=10m. When run in 7u60 with
>>> -XX:MaxPermSize=10m it does not crash.
>>>
>>>
>>> Thanks for providing the example program. For me it does not crash but
>>> if I run with -XX:MaxMetaspaceSize=10m I get an OutOfMemoryError. Does it
>>> crash for you?
>>>
>>> The OutOfMemoryError can be explained by the fact that when you run with
>>> -XX:MaxPermSize=10m there is some aligning going on and in the end you
>>> actually end up with a perm gen that is 20m large. Here's what I get when I
>>> use
>>>
>>> $ java -XX:+PrintGCDetails  -XX:MaxPermSize=10m
>>>
>>> Heap
>>>  PSYoungGen      total 150528K, used 10363K [0x0000000758c80000,
>>> 0x0000000763400000, 0x0000000800000000)
>>>   eden space 129536K, 8% used
>>> [0x0000000758c80000,0x000000075969ed58,0x0000000760b00000)
>>>   from space 20992K, 0% used
>>> [0x0000000761f80000,0x0000000761f80000,0x0000000763400000)
>>>   to   space 20992K, 0% used
>>> [0x0000000760b00000,0x0000000760b00000,0x0000000761f80000)
>>>  ParOldGen       total 342016K, used 0K [0x000000060a600000,
>>> 0x000000061f400000, 0x0000000758c80000)
>>>   object space 342016K, 0% used
>>> [0x000000060a600000,0x000000060a600000,0x000000061f400000)
>>>  PSPermGen       total 20480K, used 3382K [0x0000000609200000,
>>> 0x000000060a600000, 0x000000060a600000)
>>>   object space 20480K, 16% used
>>> [0x0000000609200000,0x000000060954dae0,0x000000060a600000)
>>>
>>> As you can see the perm gen is 20 m even though I specified 10m on the
>>> command line.
>>>
>>> If I run your program with -XX:MaxMetaspaceSize=20m it passes and does
>>> not run out of memory.
>>>
>>>
>>> There are no guarantees that you can always just replace MaxPermSize
>>> with MaxMetaspaceSize. Often it works, but sometimes you have to adjust the
>>> values. Especially at boundary cases as low as 10m.
>>>
>>> Hths,
>>> Bengt
>>>
>>>
>>>
>>>  Is that expected? It seems similar to
>>> https://bugs.openjdk.java.net/browse/JDK-8025635
>>>
>>>  Thanks,
>>> Brian
>>>
>>>  // uses Guava's CacheBuilder
>>>  public class Main {
>>>
>>>     public static void main(String[] args) throws Exception {
>>>         Cache<Integer, Object> cache = CacheBuilder.newBuilder()
>>>                 .softValues()
>>>                 .build();
>>>
>>>         for (int i = 0; i < 50_000; i++) {
>>>             URL[] dummyUrls = {new URL("file:" + i + ".jar")};
>>>             URLClassLoader cl = new URLClassLoader(dummyUrls,
>>> Thread.currentThread().getContextClassLoader());
>>>             Object proxy = Proxy.newProxyInstance(cl, new
>>> Class[]{Foo.class}, new InvocationHandler() {
>>>                 @Override
>>>                 public Object invoke(Object proxy, Method method,
>>> Object[] args) throws Throwable {
>>>                     return null;
>>>                 }
>>>             });
>>>             cache.put(i, proxy);
>>>             System.out.println(i);
>>>         }
>>>     }
>>>
>>>     public interface Foo {
>>>             void x();
>>>     }
>>> }
>>>
>>>
>>> _______________________________________________
>>> hotspot-gc-use mailing listhotspot-gc-use at openjdk.java.nethttp://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>>
>>>
>>>
>>
>> _______________________________________________
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>
>>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20150515/ff362994/attachment.html>