RFR (M): 8168467: Use TaskEntry as task mark queue elements

[Kim Barrett]

> On Mar 7, 2017, at 11:35 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
>> src/share/vm/gc/g1/g1ConcurrentMark.hpp 
>>   42 #ifdef _MSC_VER
>>   43 #pragma warning(push)
>>   44 // warning C4522: multiple assignment operators specified
>>   45 #pragma warning(disable:4522)
>>   46 #endif
>> 
>> Is the non-volatile overload of operator= needed?
> 
> Yes, it is part of the API for the task queues.
> 
>> Or can the need for an assignment operator be eliminated?  That is,
>> replace one or both with a named function, say "assign(...)".
> 
> What is the reason for this suggestion? Having two assignment
> operators, one for volatile and other for non-volatile instances does
> not seem to be really problematic. When I tried this the code doing the
> assignments became more unnatural looking.
> 
> This seems to be more a case of the compiler being over-cautious than a
> real problem.

I have a vague recollection of a real problem involving having both
volatile and nonvolatile overloads with the Microsoft compiler under
some circumstances.  But that could be old information, or I could
just be misremembering.  The documentation for this warning does
indicate that it's only informational, and the code should work as
expected

The warning, and the need to suppress it, is still annoying.  That's
why I asked whether the nonvolatile overload is actually required.  Is
there any problem with just having the volatile method?

> New webrev:
> http://cr.openjdk.java.net/~tschatzl/8168467/webrev.0_to_1/ (incrementa
> l)
> http://cr.openjdk.java.net/~tschatzl/8168467/webrev.1/ (full)

Other than the operator= overload question, looks good.