RFR (S): 8066566: Refactor ParNewGeneration to contain ParNewTracer
erik.helin at oracle.com
Thu Dec 11 08:15:13 UTC 2014
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:
- const 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 :)).
More information about the hotspot-gc-dev