java8 metaspace issue

Jon Masamitsu jon.masamitsu at oracle.com
Fri May 15 18:20:47 UTC 2015


Brian,

In your first mail you mention 7u60 and 8u40.  With 7u60 you must be setting
MaxPermSize.  What value are you using and you are not seeing any problems.
A sample GC log with -XX:+PrintGCDetails and -XX:+PrintHeapAtGC would
help us understand the 7u60 behavior.

With 8u40 you are not setting MaxMetaspaceSize yet you are seeing an OOME
with Metaspace as the cause?  A GC log would be most helpful there also

Jon

On 5/15/2015 8:40 AM, Brian Harris wrote:
> 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 
> <mailto: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 <mailto: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 <mailto: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 list
>>             hotspot-gc-use at openjdk.java.net  <mailto: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
>         <mailto: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
>     <mailto: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/d086e793/attachment.html>


More information about the hotspot-gc-use mailing list