RFR: Harmonize actual and expected signature of Continuation.doYield
Aleksey Shipilev
shade at openjdk.java.net
Thu Oct 14 15:29:08 UTC 2021
Found this inconsistency when reading the Loom code during x86_32 porting. `Continuation.doYield` has an `int` argument, yet C2's `OptoRuntime::continuation_doYield_Type` does not declare it. I think this is basically asking for trouble in C2, as the optimizations may ask the function type, discover there is an input of type `int`, but no such input is actually present. Runtime stubs seem to be also oblivious there is an argument, and calling conventions probably put it in the register on x86_64 and AArch64. On other arches, that might not be true.
I don't believe it breaks anything now, but let's fix it, while we are at it. It looks to me that `Continuation.doYield` is ever called with `0`, so we might just drop its `int` argument? Not sure if `scopes` is something Java code plans to use.
Additional testing:
- [x] Linux x86_64 fastdebug, `jdk_loom hotspot_loom`
-------------
Commit messages:
- Fix
Changes: https://git.openjdk.java.net/loom/pull/78/files
Webrev: https://webrevs.openjdk.java.net/?repo=loom&pr=78&range=00
Stats: 12 lines in 5 files changed: 2 ins; 4 del; 6 mod
Patch: https://git.openjdk.java.net/loom/pull/78.diff
Fetch: git fetch https://git.openjdk.java.net/loom pull/78/head:pull/78
PR: https://git.openjdk.java.net/loom/pull/78
More information about the loom-dev
mailing list