8267989: Exceptions thrown during upcalls should be handled #543
@JornVernee This change now passes all automated pre-integration checks.
After integration, the commit message for the final commit will be:
At the time when this comment was updated there had been no new commits pushed to the
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've switched to using
I've removed the public
Finally, I've changed the test to always print the output as well, besides checking the contents.
I still have to add an eager check (and test) to see if the target of an upcall throws an exception.
Adapt the existing exception check done by MemoryHandles to be more lenient towards bound method handles which might or might not throw an exception, and re-use that check.
I've now added the eager exception checking to upcallStub.
As discussed offline, this reuses the exception check done for the VarHandle adapters, but makes the check more lenient towards BoundMetrhodHandles that might or might not throw an exception. The current check was too conservative toward rejecting such handles, because it rejects a BoundMehtodHandle that contained any MethodHandle field that could throw an exception. But, such an exception might be caught be an exclosing method handle. (see also https://bugs.openjdk.java.net/browse/JDK-8268031)
Instead, when a filter used for a var handle combinator throws a checked a exception when invoked, it is caught, and an IllegalStateException is thrown instead (with the original exception as the cause).