On Mon, 14 Sep 2026 11:12:24 GMT, Jorn Vernee <[email protected]> wrote:
>> Don't know what prompted you to added this now (maybe FFM?) but this looks >> like a reasonable addition in general. Some comments but these problems >> exist in existing code like tableswitch forms. > >> Don't know what prompted you to added this now (maybe FFM?) > > I wrote up the patch a few weeks back while working on other things. Had > needed this combinator in the past, so I figured I might as well create a PR. > >> Another remark: since what 90% of this LF is doing is to box and unbox >> arguments, maybe we can later figure out a way to just attach an intrinsic >> to the adapted MH for the interpreter `synchronize` so we don't need to spin >> the LF but just need the InvokerBytecodeGenerator intrinsic. > > Right, we don't really run things through the LF interpreter these days, and > C2 (and probably other parts of the VM) assumes that a LF never changes its > `vmentry`, so there's no lazy LF compilation in practice either. So, in > practice, the fallback `synchronize` method is just for show, and we could > replace it with a simple placeholder name that then gets replaced with the > bytecode intrinsic when the LF is translated into bytecode. > > I've been thinking for a while that it might be possible to generate bytecode > more directly, skip the list-of-names stage, and remove the LF interpreter. > i.e. LF becomes just a wrapper around a class. We'd have to find a way to > re-implement LF transforms and customization on top of that though. @JornVernee You can finalize the CSR now. All the discussion so far happen around LF implementation, which is not related to the API. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32817#issuecomment-5697585281
