RFR (S): 8043243: convert SCAN_AND_FORWARD, SCAN_AND_ADJUST_POINTERS, SCAN_AND_COMPACT macros to methods

[Kim Barrett]

On Sep 25, 2014, at 6:28 AM, Marcus Larsson <marcus.larsson at oracle.com> wrote:
> 
> New webrev:
> http://cr.openjdk.java.net/~mlarsson/8043243/webrev.00/

I still haven't been able to do a really thorough review, but one
thing stood out for me:

==============================================================================
compactibleFreeListSpace.hpp
scanned_block_is_obj()
scanned_block_size()
Both call CompactibleFreeList::block_xxx() to avoid virtual function
call overhead.

Similarly in g1/heapRegion.hpp
scanned_block_size()

This "devirtualization" is an unsafe abstraction violation, since
there is nothing that would prevent the wrong function from being
called if a derived class were to override those directly called
implementations.  This devirtualization is also not present in the old
code that is being replaced.  [Note: The C++11 "final" specifier could
be used to make the devirtualization safe (by preventing any such
derived class overrides), but in that case the explicit
devirtualization wouldn't be necessary because the compiler could (and
should) infer it.]

If elimination of virtual function call overhead is a goal, then I
think a CRTP-based approach should probably be used instead.  I
suspect that's a pretty large underdaking though.

I also think that a CRTP-based approach could to be tackled as a
separate step later, whilst still replacing the macros with function
templates now.  I think, though, that if that's the plan then my
previous suggestion of eliminating the adapter classes may have been a
mistake, as I suspect it might make the CRTP revision more
complicated.  Sorry for any whiplash.

============================================================================== 
space.inline.hpp
line 97: stray trailing "\"