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. 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
