RFR: 8062036: ConcurrentMarkThread::slt may be invoked before ConcurrentMarkThread::makeSurrogateLockerThread causing intermittent crashes
Bengt Rutisson
bengt.rutisson at oracle.com
Tue Nov 4 09:13:25 UTC 2014
Hi Kim,
The change looks good. Thanks for fixing this.
Regarding assignments in if statements; I thought we had a style where
we use booleans for comparisons. This means that I would prefer Jon's
suggestion since the comparison will be on a bool value rather than
relying on that NULL is interpreted as false.
The hotspot style guidelines does not cover a lot and I guess it is open
for interpretation whether or not this case is covered. But there is a
short sentence about booleans:
https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#StyleGuide-Booleans
I interpret "use true & false (not 1 & 0)" as that NULL should also not
be used as a bool value.
Thanks,
Bengt
On 2014-11-03 23:13, Kim Barrett wrote:
> On Nov 3, 2014, at 4:31 PM, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
>> Kim,
>>
>> Change looks good. I can sponsor. Let me know when the reviews
>> are complete.
> Thanks.
>
>> Some suggestions.
>>
>> http://cr.openjdk.java.net/~kbarrett/8062036/webrev/src/share/vm/gc_implementation/g1/vm_operations_g1.cpp.frames.html
>>
>>> 216 if (SurrogateLockerThread* slt = ConcurrentMarkThread::slt()) {
>>> 217 slt->manipulatePLL(SurrogateLockerThread::acquirePLL);
>>> 218 } else {
>>> 219 SurrogateLockerThread::report_missing_slt();
>>> 220 }
>> I have a preference for
>>
>> SurrogateLockerThread* slt = ConcurrentMarkThread::slt();
>> if (slt != NULL) {
>> slt->manipulatePLL(SurrogateLockerThread::acquirePLL);
>> } else {
>> SurrogateLockerThread::report_missing_slt();
>> }
> I like declarations in conditions (also applicable to switch, for, and while statements) because it limits the scope of the declared variable. Though I tend to not use that form when the true case is large, because I dislike having an else clause that is a long way from the associated condition. So I would typically write either
>
> if (T v = init()) {
> /* small amount of code using v */
> } else {
> /* code for !v */
> }
>
> or
>
> T v = init()
> if (!v) {
> /* small block of code for !v */
> } else {
> /* code using v */
> }
>
> or (pretty commonly)
>
> T v = init();
> if (!v) {
> /* small amount of code for !v, with break/return avoiding code using v */
> }
> /* larger block of code using v */
>
> And if I can’t do one of those I’d probably factor out into helpers to allow one of those.
>
> I’m willing to change my ways and drop this idiom though if folks dislike or find it too odd or difficult to read.
>
>> http://cr.openjdk.java.net/~kbarrett/8062036/webrev/src/share/vm/gc_implementation/shared/concurrentGCThread.hpp.frames.html
>>
>> 96 // Terminate VM with error message that SLT needed but not yet created.
>>
>> I think it would read better as
>>
>> "SLT needed but not yet created." => "SLT is needed but has not yet been created."
> Sure. I guess this text *is* a bit more user-facing than an assert message, so grammar is more important.
>
More information about the hotspot-gc-dev
mailing list