The point is not really to limit the amount of nodes, but rather to limit how fast they come.
As suggested on JBS, I've made `make_scalar_in_safepoints` able to process a single safepoint, and `SafePointNode::Ideal` is just taking care of itself. I have added an overload for compatibility. The name is a bit awkward, especially the plural, since if the new last argument is provided, it doesn't work on multiple safepoints. Yet it does the same, and we can argue it still works on all the safepoints contained in a singleton set. Besides, `make_scalar_in_safepoint` exists, and is a helper of `make_scalar_in_safepoints`, so I'd rather not mess with names too much. Similar semantics get the same name. Conceptually, it also sounds nicer to me that idealizing a safepoint is not touching all the other cousin safepoints at the same time. Thanks, Marc --------- - [x] I confirm that I make this contribution in accordance with the [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). ------------- Commit messages: - No AbortVMOnCompilationFailure - Add test - Trying - Re-enable Changes: https://git.openjdk.org/valhalla/pull/2480/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2480&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373598 Stats: 134 lines in 5 files changed: 120 ins; 2 del; 12 mod Patch: https://git.openjdk.org/valhalla/pull/2480.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2480/head:pull/2480 PR: https://git.openjdk.org/valhalla/pull/2480
