Java 7 update 12 issue with MethodHandles.catchException.

[Christian Thalinger]

On Dec 21, 2012, at 2:22 AM, "MacGregor, Duncan (GE Energy Management)" <duncan.macgregor at 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.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
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev