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