Heads up - Ran into something I haven't seen before

Bengt Rutisson bengt.rutisson at oracle.com
Mon Feb 18 07:19:14 UTC 2013


Jim,

"GC overhead limit exceeded" means that we through out of memory because 
we are spending too much time in GC compared to application time.

I think checking the GC logs as many have already suggested it a good 
start. Most likely you will find that there are back-to-back GCs around 
the time when the OOME is being thrown. You may need to increase your 
heap size or make sure the application reduces the number of live 
objects it keeps around. There may be other tuning to do as well.

hths,
Bengt

On 2/16/13 2:20 AM, Christian Thalinger wrote:
> On Feb 15, 2013, at 2:27 PM, Srinivas Ramakrishna <ysr1729 at gmail.com> wrote:
>
>> Check gc log. Your perm gen might be too all?
> Well, it's HS25.  There is no perm gen anymore.  Maybe hotspot-gc-dev is a better list for this.
>
> -- Chris
>
>> -- Ramki
>>
>> ysr1729
>>
>> On Feb 15, 2013, at 6:19, "Jim Laskey (Oracle)" <james.laskey at oracle.com> wrote:
>>
>>> Working to isolate
>>>
>>> java version "1.8.0-ea"
>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b76)
>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b17, mixed mode)
>>>
>>> command line: running raytrace.js...
>>> Score: 797
>>> Score: 404
>>> Score: 1120
>>> Score: 408
>>> Score: 184
>>> Score: 125
>>> Score: NaN
>>> Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
>>>    at java.util.regex.Pattern$BnM.optimize(Pattern.java:5404)
>>>    at java.util.regex.Pattern.compile(Pattern.java:1703)
>>>    at java.util.regex.Pattern.<init>(Pattern.java:1345)
>>>    at java.util.regex.Pattern.compile(Pattern.java:1055)
>>>    at java.lang.String.replace(String.java:2227)
>>>    at jdk.nashorn.internal.codegen.RuntimeCallSite.makeMethod(RuntimeCallSite.java:282)
>>>    at jdk.nashorn.internal.codegen.RuntimeCallSite.next(RuntimeCallSite.java:343)
>>>    at java.lang.invoke.LambdaForm$DMH/1094834071.invokeSpecial_L_L(LambdaForm$DMH)
>>>    at java.lang.invoke.LambdaForm$BMH/1411892748.reinvoke(LambdaForm$BMH)
>>>    at java.lang.invoke.LambdaForm$NamedFunction.invoke__L(LambdaForm.java:1087)
>>>    at java.lang.invoke.LambdaForm$DMH/752848266.invokeStatic_LL_L(LambdaForm$DMH)
>>>    at java.lang.invoke.LambdaForm$NamedFunction.invokeWithArguments(LambdaForm.java:1136)
>>>    at java.lang.invoke.LambdaForm.interpretName(LambdaForm.java:625)
>>>    at java.lang.invoke.LambdaForm.interpretWithArguments(LambdaForm.java:604)
>>>    at java.lang.invoke.LambdaForm$LFI/1973538135.interpret_I(LambdaForm$LFI)
>>>    at java.lang.invoke.LambdaForm$DMH/1100439041.invokeSpecial_LLL_I(LambdaForm$DMH)
>>>    at java.lang.invoke.LambdaForm$NFI/963522361.invoke_LLL_I(LambdaForm$NFI)
>>>    at java.lang.invoke.LambdaForm$DMH/752848266.invokeStatic_LL_L(LambdaForm$DMH)
>>>    at java.lang.invoke.LambdaForm$NamedFunction.invokeWithArguments(LambdaForm.java:1136)
>>>    at java.lang.invoke.LambdaForm.interpretName(LambdaForm.java:625)
>>>    at java.lang.invoke.LambdaForm.interpretWithArguments(LambdaForm.java:604)
>>>    at java.lang.invoke.LambdaForm$LFI/1973538135.interpret_I(LambdaForm$LFI)
>>>    at java.lang.invoke.LambdaForm$MH/1413378318.exactInvoker(LambdaForm$MH)
>>>    at java.lang.invoke.LambdaForm$NFI/175408781.invoke_LLL_Z(LambdaForm$NFI)
>>>    at java.lang.invoke.LambdaForm$DMH/752848266.invokeStatic_LL_L(LambdaForm$DMH)
>>>    at java.lang.invoke.LambdaForm$NamedFunction.invokeWithArguments(LambdaForm.java:1136)
>>>    at java.lang.invoke.LambdaForm.interpretName(LambdaForm.java:625)
>>>    at java.lang.invoke.LambdaForm.interpretWithArguments(LambdaForm.java:604)
>>>    at java.lang.invoke.LambdaForm$LFI/1973538135.interpret_I(LambdaForm$LFI)
>>>    at java.lang.invoke.LambdaForm$DMH/1100439041.invokeSpecial_LLL_I(LambdaForm$DMH)
>>>    at java.lang.invoke.LambdaForm$NFI/963522361.invoke_LLL_I(LambdaForm$NFI)
>>>    at java.lang.invoke.LambdaForm$DMH/752848266.invokeStatic_LL_L(LambdaForm$DMH)
>>>




More information about the hotspot-gc-dev mailing list