Request for review: 8008546: G1: Wrong G1CONFIDENCEPERCENT results in GUARANTEE(VARIANCE() > -1.0) FAILED
Bengt Rutisson
bengt.rutisson at oracle.com
Thu Feb 21 09:56:14 UTC 2013
John,
The bug report lists a guarantee in nuberSeq.cpp. You need a concurrent
cycle for the issue to reproduce.
I can repro it with this command line using SPECjbb2005:
java -XX:+UseG1GC -XX:G1ConfidencePercent=300 -Xmx256m
-XX:InitiatingHeapOccupancyPercent=1 -XX:+PrintGC -cp jbb.jar:check.jar
spec.jbb.JBBmain
Here is the stack trace from the hs_err file i get:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error
(/Users/brutisso/repos/hs-gc-test-deprecated/src/share/vm/utilities/numberSeq.cpp:166),
pid=34072, tid=16131
# guarantee(variance() > -1.0) failed: variance should be >= 0
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b68) (build
1.8.0-ea-b68)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b15-internal-jvmg
mixed mode bsd-amd64 compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable
core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
#
--------------- T H R E A D ---------------
Current thread (0x00007feda9038000): ConcurrentGCThread [stack:
0x0000000129587000,0x0000000129687000] [id=16131]
Stack: [0x0000000129587000,0x0000000129687000], sp=0x0000000129686190,
free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code)
V [libjvm.dylib+0xd48e80] VMError::report(outputStream*)+0x1262
V [libjvm.dylib+0xd4a57b] VMError::report_and_die()+0x88f
V [libjvm.dylib+0x5328a7] report_vm_error(char const*, int, char
const*, char const*)+0xc7
V [libjvm.dylib+0xac6dd2] TruncatedSeq::add(double)+0x170
V [libjvm.dylib+0x4d389a] CMTask::do_marking_step(double, bool,
bool)+0x15ba
V [libjvm.dylib+0x4d9d5a] CMConcurrentMarkingTask::work(unsigned
int)+0x192
V [libjvm.dylib+0xda8c8e] GangWorker::loop()+0x666
V [libjvm.dylib+0xda7fc0] GangWorker::run()+0x3a
V [libjvm.dylib+0xafef34] java_start(Thread*)+0x1d4
C [libsystem_c.dylib+0x14742] _pthread_start+0x147
C [libsystem_c.dylib+0x1181] thread_start+0xd
Bengt
On 2/20/13 9:13 PM, John Cuthbertson wrote:
> Hi Vladimir,
>
> The change looks good to me. But I have a question: which counter was
> tripping the guarantee? I just ran jvm98 with a confidence percent
> value of 200 and 300 and the guarantee didn't fire for me.
>
> I kind of agree with Bengt that moving this kind of error checking
> earlier would be better. But that can be done as a separate CR.
>
> Thanks,
>
> JohnC
>
> On 2/20/2013 7:27 AM, vladimir kempik wrote:
>> Hi Bengt,
>>
>> Thanks for looking at this!
>>
>> Here is an updated webrev based on your feedback:
>>
>> http://cr.openjdk.java.net/~mcherkas/vladimir/8008546/webrev.01/
>>
>> I applied what you suggested.
>>
>> Thanks,
>> Vladimir.
>>
>> On 20.02.2013 17:54, Bengt Rutisson wrote:
>>>
>>> Hi Vladimir,
>>>
>>> This looks very similar to how we treat G1ReservePercent, so I think
>>> it looks good. An alternative would have been to check this earlier
>>> in the initialization phase and update the flag G1ConfidencePercent
>>> so that PrintFlagsFinal would have printed the actual value. But for
>>> consistency I think it looks good this way.
>>>
>>> I think you can change G1ConfidencePercent to be an uintx instead of
>>> intx (in g1_globals.hpp). In that case you don't need the second if
>>> statment since it can't be less than 0. It is also more consistent
>>> with G1ReservePercent which is an uintx.
>>>
>>> Thanks,
>>> Bengt
>>>
>>> On 2/20/13 2:31 PM, vladimir kempik wrote:
>>>> Hi all,
>>>>
>>>> Could I have a couple of reviews for this change?
>>>>
>>>> http://cr.openjdk.java.net/~mcherkas/vladimir/8008546/webrev.00/
>>>>
>>>> Input value for G1CONFIDENCEPERCENT wasn't checked before using.
>>>> This results in crash sometimes if -XX:+UseG1GC
>>>> -XX:G1ConfidencePercent=200 flags are used. Now checking the value
>>>> same way as it was done for G1ReservePercent. Increase to 0 if
>>>> negative, decrease to 100 if more than 100.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>
>>
>
More information about the hotspot-gc-dev
mailing list