Hi Chris,
On 17/04/2020 3:18 am, Chris Plummer wrote:
Hello,
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8242787
http://cr.openjdk.java.net/~cjplummer/8242787/webrev.00/index.html
After fixing JDK-8230731 [1], this test still failed, this time with a
WrongTypeException. The issue is basically the same one as was just
fixed in JDK-8235220 [2]. With CDS on you sometimes get a
WrongTypeException instead of an AddressException, so in some places
code that allows an AddressException needs to also allow a
WrongTypeException.
Just an observation: the multiple catch blocks that are identical:
261 catch (AddressException e) {
262 // This is okay at the top of these regions
263 }
264 catch (UnknownOopException e) {
265 // This is okay at the top of these regions
266 }
267 catch (WrongTypeException e) {
268 // This is okay at the top of these regions
269 }
can now be written more succinctly as:
261 catch (AddressException | UnknownOopException |
WrongTypeException e) {
262 // These are okay at the top of these regions
263 }
Cheers,
David
-----
Note that fixing this issue then exposes JDK-8242789 [3], which I'll be
fixing next, so the problem list entry changed from JDK-8242787 to
JDK-8242789.
I also did a bit of cleaning up of some debugging code. During my
debugging session I set DEBUG = true to get some extra debugging output,
and suddenly a lot of tests were failing with a RuntimeException. This
is because of the debugging code I've now stripped out. It decided to
convert an acceptable failure type (UnknownOopException) into one that
the outer try/catch would not catch (RuntimeException).
UnknownOopException is not suppose to cause iterateLiveRegions() to abort.
https://bugs.openjdk.java.net/browse/JDK-8230731
https://bugs.openjdk.java.net/browse/JDK-8235220
https://bugs.openjdk.java.net/browse/JDK-8242789
thanks,
Chris
