[15] RFR(S): 8246203: Segmentation fault in verification due to stack overflow with -XX:+VerifyIterativeGVN
Christian Hagedorn
christian.hagedorn at oracle.com
Thu Jun 11 07:38:27 UTC 2020
Hi Tobias
Thank you for your review!
I ran some more testing with -XX:+VerifyIterativeGVN over night and
compared the iterative solution with the old recursive version. We hit
some more test timeouts with the new iterative solution because we are
now really looking at all nodes for a requested depth. There are cases
where the recursive solution would not do that. For example, if
verify_depth = 4 and given a node chain 1->2->3->4->5, the recursive DFS
solution visits nodes 1-4 and then at node 4 when it wants to visit node
5 it immediately returns because the depth 4 is reached. Node 4 is now
marked as visited. If, however, there is an additional path
1->4->5->6->7 to look at later, the recursive DFS solution will just
stop at node 4 because that node was already visited. The iterative
solution, on the other hand, processes the nodes in a BFS and will visit
all nodes up to depth 4, including node 5 and 6. This results in
spending more time (as seen with more timeouts for more complex
graphs/tests).
We could now try to simulate the same recursive DFS behavior in an
iterative approach with a stack. But as we seem to be missing some nodes
at a requested depth this is probably not what we really want?
Alternatively, we could go with this BFS solution as it is and decrement
verify_depth = 4 in the call Node::verify(n, 4) to reduce the time
spent. Or just leave webrev.01 as it is and treat the additional
timeouts as expected.
What do you think?
Best regards,
Christian
On 10.06.20 14:30, Tobias Hartmann wrote:
> Hi Christian,
>
> On 09.06.20 19:32, Christian Hagedorn wrote:
>> http://cr.openjdk.java.net/~chagedorn/8246203/webrev.01/
>
> Looks good to me.
>
> Did you run testing with -XX:+VerifyIterativeGVN?
>
> Best regards,
> Tobias
>
More information about the hotspot-compiler-dev
mailing list