Java 7 update 12 issue with MethodHandles.catchException.

[MacGregor, Duncan (GE Energy Management)]

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.thalinger at oracle.com> wrote:

>
>On Dec 13, 2012, at 7:55 AM, "MacGregor, Duncan (GE Energy Management)"
><duncan.macgregor at 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.rose at oracle.com<mailto:john.r.rose at oracle.com>>
>> Reply-To: Da Vinci Machine Project
>><mlvm-dev at openjdk.java.net<mailto:mlvm-dev at openjdk.java.net>>
>> Date: Wednesday, 12 December 2012 19:42
>> To: Da Vinci Machine Project
>><mlvm-dev at openjdk.java.net<mailto:mlvm-dev at 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 at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>_______________________________________________
>mlvm-dev mailing list
>mlvm-dev at openjdk.java.net
>http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev