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

[Marcus Larsson]

On 11/12/14 09:13, Erik Helin wrote:
> 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

I'm fine with either solution. Unless we really want to move to 
const-references, it probably makes more sense to stick to pointers however.

Thanks,
Marcus