RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build.

Bengt Rutisson bengt.rutisson at oracle.com
Mon Dec 14 09:43:50 UTC 2015


Hi Kim and Goetz,

On 2015-12-13 00:02, Kim Barrett wrote:
> On Dec 11, 2015, at 5:52 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
>> diff -r 73e267ddd93d src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
>> --- a/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp     Wed Nov 18 11:31:59 2015 +0100
>> +++ b/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp     Fri Dec 11 11:42:52 2015 +0100
>> @@ -2731,7 +2731,7 @@
>>    // Not MT-safe; so do not pass around these StackObj's
>>    // where they may be accessed by other threads.
>>    jlong wallclock_millis() {
>> -    return TimeHelper::counter_to_millis(os::elapsed_counter() - _trace_time.start_time());
>> +    return (jlong)TimeHelper::counter_to_millis(os::elapsed_counter() - _trace_time.start_time());
>>    }
>> };
> This conversion was introduced by the recently pushed 8145092: Use Unified Logging for the GC logging.
>
> The only caller of wallclock_millis compares the result with CMSMaxAbortablePrecleanTime (an intx).
>
> So I think we’ve always had a bit of a type mismatch here.
>
> I’m not sure what to do about this one yet, but adding a cast doesn’t seem like the right solution to me.

I would suggest changing CMSMaxAbortablePrecleanTime to a double. It may 
not be the cleanest way to handle the flag but having it as an intx is 
also not very clean. Negative values won't make sense. Changing it to a 
double won't make the situation much worse than it is now and it will 
simplify the code.

So, I would suggest:

diff --git a/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp 
b/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
--- a/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
+++ b/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
@@ -2733,1 +2733,1 @@
-  jlong wallclock_millis() {
+  double wallclock_millis() {
diff --git a/src/share/vm/runtime/globals.hpp 
b/src/share/vm/runtime/globals.hpp
--- a/src/share/vm/runtime/globals.hpp
+++ b/src/share/vm/runtime/globals.hpp
@@ -1836,1 +1836,1 @@
-  product(intx, CMSMaxAbortablePrecleanTime, 
5000,                          \
+  product(double, CMSMaxAbortablePrecleanTime, 
5000,                        \


>
>> diff -r 73e267ddd93d src/share/vm/gc/g1/g1CollectedHeap.cpp
>> --- a/src/share/vm/gc/g1/g1CollectedHeap.cpp    Wed Nov 18 11:31:59 2015 +0100
>> +++ b/src/share/vm/gc/g1/g1CollectedHeap.cpp    Fri Dec 11 11:42:52 2015 +0100
>> @@ -3621,7 +3621,7 @@
>>      log_info(gc)("To-space exhausted");
>>    }
>>
>> -  double pause_time_sec = TimeHelper::counter_to_seconds(pause_time_counter);
>> +  double pause_time_sec = TimeHelper::counter_to_seconds((jlong)pause_time_counter);
>>    g1_policy()->print_phases(pause_time_sec);
>>
>>    g1_policy()->print_detailed_heap_transition();
> Adding a cast is not the proper fix here.
>
> The problem is that log_gc_footer’s double pause_time_counter argument ought to itself be a jlong.
> The caller (do_collection_pause_at_safepoint) contains
>
>    double pause_start_counter = os::elapsed_counter();
>>    log_gc_footer(os::elapsed_counter() - pause_start_counter);
>
> elapsed_counter returns a jlong.  So pause_start_counter ought to be a jlong too, and fixing the
> parameter type for log_gc_footer would then make everything work out.
>
> This appears to be a mistake introduced by the recently pushed 8145092: Use Unified Logging for the GC logging.
>

Yes, this is a mistake in the push for the unified logging work. I 
created a patch and sent out a new review request to fix it.

RFR: JDK-8145303: Clean up the units for log_gc_footer
http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-December/015903.html

http://cr.openjdk.java.net/~brutisso/8145303/webrev.00/

Thanks,
Bengt



More information about the hotspot-gc-dev mailing list