RFR (S): 8066566: Refactor ParNewGeneration to contain ParNewTracer
marcus.larsson at oracle.com
Mon Jan 5 11:17:51 UTC 2015
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
> 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:
> 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  puts it:
> "References can be confusing, as they have value syntax but pointer
> 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 :)).
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.
More information about the hotspot-gc-dev