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

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