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