RFR (S): 8066566: Refactor ParNewGeneration to contain ParNewTracer

[Erik Helin]

On 2014-12-10 18:40, Kim Barrett wrote:
> On Dec 10, 2014, at 9:51 AM, Marcus Larsson <marcus.larsson at oracle.com> wrote:
>>
>> Hi again,
>>
>> Updated the patch with some cleanups to use 'const ParNewTracer*' rather than 'ParNewTracer&' where appropriate.
>
> Why “pointer to const” rather than “reference to const”, e.g. use “const ParNewTracer&” instead.  That would be much more usual C++ style.

It was my suggestion. I know that using a const reference here is 
probably more "standard" C++, the reasons I suggested a pointer are:
- HotSpot is already rather "pointy", pointers is far more common in
   our code base than references.
- I think pointers adds more information to the reader. The following
   code:

     gc_tracer().report_promition_failure(info);

   could mean that gc_tracer() returns one of:
   - GCTracer&
   - const GCTracer&
   - GCTracer
   - (GCTracer&& ? I'm not fully up to speed on C++14)
   whereas the following line:

     gc_tracer()->report_promition_failure(info);

   tells me that gc_tracer() returns one of:
   - GCTracer* (const)
   - const GCTracer* (const)
   (ignore the cases when the pointer itself is const, that doesn't
   matter). To me, dereferencing a pointer indicate that I'm using
   memory that does not belong to my particular piece of code. With a
   const reference, this situation is not as easy to identify. Or, as the
   Google C++ style guide [0] puts it:
   "References can be confusing, as they have value syntax but pointer
    semantics."

The big advantage of a function having a const reference parameter 
instead of pointer is that you don't have to check for null. If you feel 
strongly about using const references, I'm fine with that as well (it is 
non-const references that I really dislike :)).

Thanks,
Erik

[0]: 
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Reference_Arguments