On Dec 21, 2012, at 2:22 AM, "MacGregor, Duncan (GE Energy Management)" <duncan.macgre...@ge.com> wrote:
> Okay I've been experimenting a bit before you sent that, and If the code > cache is set to something rather large then we seem to get good > performance on large applications anyway, though we do still see lambda > form classes getting loaded (though at a lower rate once everything has > been running for a while) so without lambda form caching running instances > would almost certainly end up running out of permgen eventually. I'll keep > tracking application performance and memory usage on 7u12 and 8, and see > what difference caching and incremental unlinking make. > > BTW. Is there any good way to get instrumentation on code cache usage? > Either in real time or by processing the compilation log afterwards? I can > piece together a lot from the compilation log method and make_not_entrant > information so I can see when things have become zombies, but I don't see > anything in there to indicate when zombies have actually been flushed. +PrintMethodFlushing should log the current code cache state. I don't think we have anything that prints flushed methods. -- Chris > > On 20/12/2012 19:27, "Christian Thalinger" > <christian.thalin...@oracle.com> wrote: > >> >> On Dec 13, 2012, at 7:55 AM, "MacGregor, Duncan (GE Energy Management)" >> <duncan.macgre...@ge.com> wrote: >> >>> Thanks. Meanwhile I've patched the two offending parts of the database >>> library to work round the problem. Although our benchmarks run quite >>> nicely on 7u12 and 8 (give or take a couple of slowdowns) full >>> applications really aren't performing well right now. >>> >>> Startup time on 7u12 has increased by somewhere between 50 and 70%, >>> which seems to be due to the new LambdaForm infrastructure being slower >>> on initialisation/initial calls. That isn't great but is something I >>> think we can live with and will probably push us to look at ways of >>> improving overall startup time. >>> >>> The large number of LamdbaForms created means permgen usage has >>> increased substantially it was over 300MB by the time the applications >>> has started. >>> >>> Compilation never really settles down during use of the app. I'll look >>> into this (I don't think it ever really settled down on 7u9 either but >>> performance was considerably better). >>> >>> I'm going to try running everything with PrintCompilation and >>> LogCompilation to try and work out why compilation isn't settling down >>> and narrow the problem down. >> >> You are on the bleeding edge right now even with 7u12 (since the code is >> basically the same as in 8). For better performance we need to wait for >> two changes: >> >> 1. incremental inlining: http://bugs.sun.com/view_bug.do?bug_id=8005071 >> >> 2. LambdaForm caching (can't find the bug number right now) >> >> These must (and will) go into 7u12 and 8. >> >> -- Chris >> >>> >>> From: John Rose <john.r.r...@oracle.com<mailto:john.r.r...@oracle.com>> >>> Reply-To: Da Vinci Machine Project >>> <mlvm-dev@openjdk.java.net<mailto:mlvm-dev@openjdk.java.net>> >>> Date: Wednesday, 12 December 2012 19:42 >>> To: Da Vinci Machine Project >>> <mlvm-dev@openjdk.java.net<mailto:mlvm-dev@openjdk.java.net>> >>> Subject: Re: Java 7 update 12 issue with MethodHandles.catchException. >>> >>> On Dec 12, 2012, at 11:33 AM, Christian Thalinger wrote: >>> >>> That helps. I can't recall code that has a "8 argument limitation" and >>> does something else with 9+. Maybe John has an idea. >>> >>> The bug is probably in GuardWithCatch.invoke_V, in this file: >>> >>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/ >>> lang/invoke/MethodHandleImpl.java >>> >>> I'll look into it. >>> >>> ‹ John >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev@openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev@openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
