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

[Roman Kennke]

>> 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

Thank you John for your support, and for sharing those fascinating stories.

I also have a story to share which I find quite fitting (and I hope I
don't bore the people who keep hearing this story from me).

Back when I worked at a much smaller company, then a ~20 employees shop,
working on a Java VM, we had one guy who owned a very significant amount
of very important code. It was written in a very special way, and was
sort of mad genius stuff, but nobody except this one guy could really
understand it, save make any changes to it. And for this reason it kept
getting worse: whenever something in this code needed changing, it was
this guy's job to do it. And therefore nobody ever got to learn to
navigate and work this code. Rinse and repeat. Back then I was joking
that he better be careful to not get run over by a bus or such. But as
life goes, eventually he fell in love with a japanese lady and decided
to go to Tokio. I believe this almost ruined the company. (At this point
I already joined Sun and was no longer working for them.) To my
knowledge, they struggled very badly to recover from this.

The similarities of this situation and the one we have here are
striking: 'his' code was an abstraction layer, as is the Access API, it
was done in very unusual way compared to the rest of the code base
(template-based idioms, then it was a horrible mess of C macros). It
ended up to only be maintainable by this one guy. It's a very risky
undertaking to go this route.

For this reason I can only agree with John to signpost this review
thread. I do make a point of trying to understand all this stuff, work
out problems/extensions etc myself, and hopefully contribute to improve
it to a more maintainable state in the future.

I'm waiting for Coleen to come back with performance testing results,
and will then push the last reviewed changeset.

Thanks everybody and cheers,
Roman