RFR: JDK-8258603 c1 IR::verify is expensive
Ludvig Janiuk
duke at openjdk.java.net
Thu Dec 16 13:29:53 UTC 2021
On Wed, 15 Dec 2021 15:39:26 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:
> IR::verify iterates the whole object graph. This proves costly when used in e.g. BlockMerger inside of iterations over BlockLists, leading to quadratic or worse complexities as a function of bytecode length. In several cases, only a few Blocks were changed, and there was no need to go over the whole graph, but until now there was no less blunt tool for verification than IR::verify.
>
> This PR introduces IR::verify_local, intended to be used when only a defined set of blocks have been modified. As a complement, expand_with_neighbors provides a way to also capture the neighbors of the "modified set" ahead of modification, so that afterwards the appropriate asserts can be made on all blocks which might possibly have been changed. All this should let us remove the expensive IR::verify calls, while still performing equivalent (or stricter) assertions.
>
> Some changes have been made in the verifiers along the way. Some amount of refactoring, and even added invariants (see validate_edge_mutiality).
small local interspersed test with 2 first rounds discarded seems to show a slight increase in compilation time, which can be explained by the added checks:
| C1 compile time | | Emit LIR | |
-- | -- | -- | -- | -- | --
| this PR | master | this PR | master |
| 1,63 | 1,705 | 1,34 | 1,412 |
| 1,701 | 1,563 | 1,412 | 1,276 |
| 1,694 | 1,564 | 1,405 | 1,27 |
| 1,704 | 1,593 | 1,406 | 1,306 |
| 1,696 | 1,709 | 1,407 | 1,415 |
| 1,704 | 1,622 | 1,418 | 1,335 |
| 1,72 | 1,732 | 1,427 | 1,433 |
| 1,686 | 1,712 | 1,396 | 1,42 |
avg | 1,691875 | 1,65 | 1,401375 | 1,358375 |
Invocation:
` for i in {1..10}; do .../jdk-myfix/bin/java -Xbatch -XX:+CITime compiler.c2.cr6340864.TestLongVect > time/myfix-$i.txt; .../jdk-master/bin/java -Xbatch -XX:+CITime compiler.c2.cr6340864.TestLongVect > time/master-$i.txt; done`
Note that the timeouts of [openjdk/jdk16#44](https://github.com/openjdk/jdk16/pull/44) were remediated, likely by accident, in https://bugs.openjdk.java.net/browse/JDK-8267806, thus making it a worse candidate for testing this.
-------------
PR: https://git.openjdk.java.net/jdk/pull/6850
More information about the hotspot-compiler-dev
mailing list