RFR: JDK-8199781: Don't use naked == for comparing oops

[John Rose]

On Mar 29, 2018, at 4:27 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> With regard to whether the compiler understands enough to inline it
> all, it probably will but there's no guarantee.  When Stepanov was
> writing STL he coined the phrase "Abstraction Penalty" which claims to
> be the factor by which you will be punished by your compiler if you
> attempt to use C++ data abstraction features.  Back then there were
> some severe penalties, so C++ compiler writers did a lot of work to
> fix them.  These days, because of heavy use of STL and suchlike, the
> Abstraction Penalty is usually 1, i.e. there is no penalty.
> 
> I agree, though, that accessBackend.new.hpp is a frightening piece of
> code written in an idiom that's very different from the rest of
> HotSpot.  I doubt that its usefulness exceeds its maintenance burden.

So, when I collected the HotSpot style guide pages way back in the day,
the very last point was, "Introduce new templates only by Act of Congress",
which is whimsically stated.  But it occurs to me that what we are doing
right now is evaluating a significant new set of templates in an act of
public discussion, not very different (in our setting) from that of a congress.

IIRC one of the intentions behind the cute phrase is to be very deliberate
about adding templates, precisely because they allow the introduction of
powerful but bewildering new sub-languages of C++.  If you look at
GrowableArray, it is is mild stuff compared to the newer decorator
based idioms in the logging and access APIs.  I think the mildness
of GA relative to the other things is that your "journey" to understand
the code is short, and passes through only one header file (maybe two).

(Another intention was that using templates can hide unintentional
dilution of the basic C++ performance model, that simple operations
are zero or one machine instructions.  That's why we have spent
several extra days on Roman's review.  When the "Act of Congress"
guideline was written, Stepanov's AP number was much worse,
and we had to be sure that all of our templates were understandable
by all of our C++ toolchains.  Hence, again, the mildness of GA.)

One risk of putting in one really hairy template system (logging)
is that it loosens the sense of restraint we might have on adding
a second (access) and then a third (any takers?).  The same is
true of many other "big ticket" C++ features, like exceptions or
multiple inheritance (and just wait for the concepts).  The problem
is not with people making full use of a truly great programming
language, so much as people learning the deep corners of
some special idiom allowed by that language, and leaving
the rest of us behind, writing code that is so hard to read
(without investing in the idiom) that it becomes magic,
whose maintainers must be mages.

C++ (that great salad of a language) has always been a
temptation to wizards of various ranks (myself one of the
lesser, Erik and Kim in the middle, people like Stepanov the
greatest), to use the deepest parts of the language to solve
increasingly hard problems.  For me, it's usually a loss, because
I'm not good enough to use the deep features in a communicative
manner, though I'm clever enough to use them all in a sort
of "private ecstasy".  For OpenJDK, I think the process is working
out better, but we need to make sure that there is nothing private
about the thinking that put together our template-heavy code.
That means signposting Erik's and Coleen's "journey" through
the code, so that future travelers don't need a first class
wizard as a tour-guide.  First-class wizards have better things
to do, after all.

— John

P.S.  Re: More on my claim as C++ magus minor.  I have always
been fascinated by how far the C++ language can be taken; I used
it enthusiastically.  It was an influence on the C* language which
I co-designed.  I've written several C++ tools, including a dynamically
typed interpreter.  I contributed a bug fix to cfront in the early 80's.
In the late 80's a reaction kicked in:  I realized that the complexity
had a dark side (took me that long!) and I began to think of C++
as a fascinating sort of "puzzle box", not altogether wholesome to
spend one's hours with, a hobby as much as a profession.  At that
that point I switched hobbies, to a dynamically typed Scheme VM.
I used that for a few projects (including building the C++ interpreter
on top), until Java came out.  I know there are well-socialized,
non-ecstatic ways to program in C++, and I also know that it
takes decades to shake out the trendy ideas and focus on
stable ideas, then wait for the toolchains to optimize accepted
idioms.  The challenge, I think, for any large C++ project is to
decide how to discern which well-socialized idioms to adopt,
and (if absolutely necessary) which ones to locally invent.
This challenge requires the expert wizards to hold back from
exerting their full powers, so that the whole community can
become comfortable with the shared source code.

P.P.S.  Re:  "virtuals cannot be templates".  This is because
you can't split a v-table slot across an infinite range of template
instances.  But sometimes, as a workable compromise, you can
choose to split a v-table slot across a finite (pre-set) range of
template instances, and use the virtual/non-virtual companion
method pattern to wire up devirtualized methods to template
algorithms.  This probably requires macros, but intrusion by
macros can be limited to almost nothing:  A single-token helper
macro that is placed in each preset instance type.   An example
of that is here, for the enjoyment of C++ puzzle masters:

http://cr.openjdk.java.net/~jrose/draft/splitvtbl.cpp