JDK 9 rampdown and a plea for mercy (original) (raw)
Volker Simonis volker.simonis at gmail.com
Fri Mar 10 16:58:30 UTC 2017
- Previous message: JDK 9 rampdown and a plea for mercy
- Next message: JDK 9 rampdown and a plea for mercy
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message: JDK 9 rampdown and a plea for mercy
- Next message: JDK 9 rampdown and a plea for mercy
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]