JDK 9 rampdown and a plea for mercy

Volker Simonis volker.simonis at gmail.com
Fri Mar 10 16:58:30 UTC 2017


On Fri, Mar 10, 2017 at 3:55 PM, Andrew Haley <aph at redhat.com> wrote:
> As you may remember, I did some work on ByteBuffers a couple of years
> ago.  At the time the generated code was sparklingly good, and I was
> happy the job was done well.  Yesterday I looked at the code we are
> generating in JDK9, and was horrified to see that it now is a steaming
> pile of ordure.  It might be, of course, that I am mistaken about it
> being better before, but I really don't think so: I wouldn't have let
> it go out like that.  I suppose it was just good luck (or a C2 bug)
> that great code was generated.
>
> The full gory details are in
> https://bugs.openjdk.java.net/browse/JDK-8176513, but the bottom line
> is that unless this regression is fixed all my ByteBuffer work will
> have been for naught.
>
> Roland has had a look at what is happening, and he thinks that this
> can be fixed fairly quickly: he already has a working patch.  Is there
> any way that we can get it in?
>
> One thing for the future: we need to keep an eye on code quality
> regressions.  I'm not sure how, exactly.  And perhaps I need to
> remember that just because C2 generates good code today, it might not
> generate good code tomorrow.
>

I totally agree. One possibility would be to expose the OptoAssembly
trough the WhiteBox API. That way we could write tests which ensure
that certain patterns are really matched in the expected way. It will
still be hard to write such tests because they will be mostly platform
specific, but at least it could be a start. One problem with the
OptoAssembly (i.e. the name of the corresponding nodes) is that they
aren't available in the opt/product builds. I think making them
available wouldn't be too much of an overhead and could be acceptable.
I once had a corresponding change, but never made it available.
"JDK-8046030: WhiteBox :: get native code disassembly or optoassembly"
[1] tracked a simiklar issue, but was closed :(

In our commercial VM we have some tests where we dump all the matched
nodes just to ensure that every expected node is still matched. But
that's of course just a start for checking that the generated code for
a method is good (and remains good):

Regards,
Volker

[1] https://bugs.openjdk.java.net/browse/JDK-8046030

> Thanks,
>
> Andrew.


More information about the hotspot-dev mailing list