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

[Roman Kennke]

>>> http://cr.openjdk.java.net/~eosterlund/8199781/webrev.02/src/hotspot/share/oops/accessBackend.new.hpp.html
> . . .
>> Also, it would be nice to get ok from John and Andrew. :-)
> Wrong Andrew here, I am afraid. However, I am butting in just to place
> on record that this /one file/ is quite probably the most unmaintainable
> piece of code I have ever been witness to in 35 years of professional
> software development (and, yes, that includes the Interlisp-D machine's
> reference counting GC which had invisible microcode support (Pope's
> 'butterfly on a wheel' [1] springs to mind :-).
> 
> Although I am very glad to hear (and even more glad to take it on
> assurance ;-) that the compiler understands enough to inline it all
> away, my real concern is whether anyone else will still understand it in
> 6 months or 1 year if (when?) a bug manifests. Especially if bug is
> caused by misguided and/or unexpected usage in the JIT or (more likely)
> JVM runtime code.
> 
> Anyway, that's enough of my contrarian, old man griping. You young uns
> can just carry on with whatever it is you are doing :-)
> 

Well yeah, you do have a point. I kindof sortof have an idea what it
does, but it's incredibly complex.

I'd probably have done it differently. We probably would have gotten
away with a bunch of virtual methods (duplicated to deal with the oop vs
narrowOop schism... because virtual methods can't be templated).
Sprinkled a bunch of #ifdefs around to avoid virtual calls for some
stuff like oopDesc::equals() for non-Shenandoah builds, to make the
performance pessimists happy. Probably add some more APIs to also handle
different memory ordering constraints, etc etc. To be honest, I am not
sure if the end result would have been so much better. The Access API as
it is does have some crazy stuff in it, however, from a usage point of
view it's great.

The concern that I have is that all the magical voodoo knowledge to
maintain it is in the head of Erik Österlund, and god beware he'll ever
disappear and then we get to change something in it ;-)

However, it's not the scope of this change to re-design the Access API.
I believe everybody will be happy to have this discussion to simplify
the Access API... I suspect a lot could be achieved by eventually
dropping build-time switches for Shenandoah (which I don't buy are
necessary performance-wise), and use proper virtual calls instead of all
this resolving and setting-up of function pointers for each entry point.
We don't win much, if anything, by avoiding the little table lookup of a
virtual call vs. a straight call (IMO).

Thanks,
Roman


> [1] https://en.wikipedia.org/wiki/Who_breaks_a_butterfly_upon_a_wheel%3F
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>