8 ms·

For those wondering about the "tail call" part that would be more interesting for Clojure than fibers: As adding the ability to manipulate call stacks to the

For those wondering about the "tail call" part that would be more interesting for Clojure than fibers: As adding the ability to manipulate call stacks to the JVM will undoubtedly be required, it is also the goal of this project to add an even lighter-weight construct that will allow unwinding the stack to some point and then invoke a method with given arguments (basically, a generalization of efficient tail-calls). We will call that feature unwind-and-invoke, or UAI. It is not the goal of this project to add an automatic tail-call optimization to the JVM. [1] https://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html https://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.ht...

gorjusborg 4y ago
> It is not the goal of this project to add an automatic tail-call optimization to the JVM. Wait what? Are we getting TCO or not with Loom?
- joe_fishfish 4y ago
  Tail-call optimisation on the JVM is already somewhat supported with an annotation / keyword (depending on language). My understanding is that the project will improve the current implementation, but you'll still need to define when a function is tail-recursive, the compiler won't do it automatically.
  - funcDropShadow 4y ago
    E.g. Scala provides such an annotation, but that is implemented by rewriting the recursive method to a non-recursive method with a loop.
    - anamexis 4y ago
      Isn't that kinda how all TCO works?
      - pjmlp 4y ago
        First level TCO yes, however the annotation way doesn't work for mutually recursive calls.
        jwesleyharding 4y ago
        to clarity just a tad, the Scala compiler does TCO out of the box and the annotation is added only to check that the method is in fact so optimizable
        pjmlp 4y ago
        Unless something changed since 2.0.9 (last time I did anything relevant in Scala), only one level, it isn't clever enough to rewrite mutually recursive calls. This is rather important, specially when coming from languages like Scheme that have TCO as part of the language specification compliance.
- patrec 4y ago
  I interpret this as "we will add a primitive that will allow you to implement TCO yourself (and more), but the behavior of existing java or byte code won't change, and the stack will continue to grow, even if a call occurs in tail position". Presumably because it's hard to impossible to retrofit TCO without changing observable behavior.
  - zasdffaa 4y ago
    Serious question, isn't that just a while/for/do loop? If people want TCO then... just write a loop, surely? I must be missing something.
    - patrec 4y ago
      You are -- non-self tail-calls. If you have mutually tail-recursive functions, say f1, f2, ..., f_n you have two problems without TCO: 1. There is no way to rewrite this into loops by just modifying the insides of these functions. 2. The remedy, which is to transform these functions and everything that calls them into a giant loop causes lots of problems: The code will become utterly unreadable (if you do this transform manually). Modularity is completely broken and there's no sane way to expose these functions individually to external callers. Also, even if you don't care about either of the above: your compiler's optimizer will probably choke on it (https://blog.reverberate.org/2021/04/21/musttail-efficient-interpreters.html https://blog.reverberate.org/2021/04/21/musttail-efficient-i...).
      - zasdffaa 4y ago
        Well, good points but I was rather thinking the compiler should do it as an option. Of lesser note, I don't believe I've ever come across mutually tail recursive functions, or the need for them, and although that may reflect my lack of experience in some areas, I guess it's not at all common? Maybe in the haskell world perhaps.
        Twisol 4y ago
        They make state machines leagues easier to reason about. Each state is its own function, and you tail-call to the next state (and pass along only the data it relies on, if you're doing things functionally).
- funcDropShadow 4y ago
  No we won't. [1] does not even mention tail-call elimination. Project Loom does not change the bytecode and does not change it's semantics. I.e. we don't get guaranteed tail-call elimination. [1]: https://openjdk.java.net/jeps/425 https://openjdk.java.net/jeps/425
- _old_dude_ 4y ago
  One issue to implement TCO is that the "security model"/circus of Java is based on the stack frames, so you can not remove stack frames without getting into trouble. The security manager has to be removed first [1] [1] https://openjdk.java.net/jeps/411 https://openjdk.java.net/jeps/411
- ithrow 4y ago
  TCO will be part of project valhalla not loom.

gorjusborg 4y ago

> It is not the goal of this project to add an automatic tail-call optimization to the JVM. Wait what? Are we getting TCO or not with Loom?

joe_fishfish 4y ago
Tail-call optimisation on the JVM is already somewhat supported with an annotation / keyword (depending on language). My understanding is that the project will improve the current implementation, but you'll still need to define when a function is tail-recursive, the compiler won't do it automatically.
- funcDropShadow 4y ago
  E.g. Scala provides such an annotation, but that is implemented by rewriting the recursive method to a non-recursive method with a loop.
  - anamexis 4y ago
    Isn't that kinda how all TCO works?
    - pjmlp 4y ago
      First level TCO yes, however the annotation way doesn't work for mutually recursive calls.
      - jwesleyharding 4y ago
        to clarity just a tad, the Scala compiler does TCO out of the box and the annotation is added only to check that the method is in fact so optimizable
        pjmlp 4y ago
        Unless something changed since 2.0.9 (last time I did anything relevant in Scala), only one level, it isn't clever enough to rewrite mutually recursive calls. This is rather important, specially when coming from languages like Scheme that have TCO as part of the language specification compliance.
patrec 4y ago
I interpret this as "we will add a primitive that will allow you to implement TCO yourself (and more), but the behavior of existing java or byte code won't change, and the stack will continue to grow, even if a call occurs in tail position". Presumably because it's hard to impossible to retrofit TCO without changing observable behavior.
- zasdffaa 4y ago
  Serious question, isn't that just a while/for/do loop? If people want TCO then... just write a loop, surely? I must be missing something.
  - patrec 4y ago
    You are -- non-self tail-calls. If you have mutually tail-recursive functions, say f1, f2, ..., f_n you have two problems without TCO: 1. There is no way to rewrite this into loops by just modifying the insides of these functions. 2. The remedy, which is to transform these functions and everything that calls them into a giant loop causes lots of problems: The code will become utterly unreadable (if you do this transform manually). Modularity is completely broken and there's no sane way to expose these functions individually to external callers. Also, even if you don't care about either of the above: your compiler's optimizer will probably choke on it (https://blog.reverberate.org/2021/04/21/musttail-efficient-interpreters.html https://blog.reverberate.org/2021/04/21/musttail-efficient-i...).
    - zasdffaa 4y ago
      Well, good points but I was rather thinking the compiler should do it as an option. Of lesser note, I don't believe I've ever come across mutually tail recursive functions, or the need for them, and although that may reflect my lack of experience in some areas, I guess it's not at all common? Maybe in the haskell world perhaps.
      - Twisol 4y ago
        They make state machines leagues easier to reason about. Each state is its own function, and you tail-call to the next state (and pass along only the data it relies on, if you're doing things functionally).
funcDropShadow 4y ago
No we won't. [1] does not even mention tail-call elimination. Project Loom does not change the bytecode and does not change it's semantics. I.e. we don't get guaranteed tail-call elimination. [1]: https://openjdk.java.net/jeps/425 https://openjdk.java.net/jeps/425
_old_dude_ 4y ago
One issue to implement TCO is that the "security model"/circus of Java is based on the stack frames, so you can not remove stack frames without getting into trouble. The security manager has to be removed first [1] [1] https://openjdk.java.net/jeps/411 https://openjdk.java.net/jeps/411
ithrow 4y ago
TCO will be part of project valhalla not loom.