在没有JVM支持的情况下,如何在JVM语言中实现协同程序?

mar*_*kin 50 java jvm scala jvm-languages kotlin

在阅读了Loom提案之后提出了这个问题,该提案描述了在Java编程语言中实现协同程序的方法.

特别是此提案表示,要在该语言中实现此功能,将需要额外的JVM支持.

据我所知,JVM上已经有多种语言可以将协同程序作为其功能集的一部分,例如Kotlin和Scala.

那么如何在没有额外支持的情况下实现此功能,如果没有它可以有效实施?

Jör*_*tag 39

tl; dr摘要:

特别是此提案表示,要在该语言中实现此功能,将需要额外的JVM支持.

当他们说"必需"时,他们的意思是"为了以一种在语言之间兼容和可互操作的方式实施".

那么如何在没有额外支持的情况下实现此功能

有许多方法,最容易理解它是如何工作的(但不一定最容易实现)是在JVM之上用你自己的语义实现自己的VM.(注意,这不是它实际完成的方式,这只是为什么可以完成它的直觉.)

没有它可以有效地实施吗?

并不是的.

稍微长一点的解释:

请注意,Project Loom的一个目标是将此抽象纯粹作为库引入.这有三个好处:

  • 引入新库比更改Java编程语言要容易得多.
  • 在JVM上,每种语言编写的程序都可以立即使用库,而Java语言功能只能由Java程序使用.
  • 可以实现具有相同API且不使用新JVM功能的库,这将允许您通过简单的重新编译来编写在较旧的JVM上运行的代码(尽管性能较低).

但是,将其实现为库可以排除聪明的编译器技巧,将协同例程转换为其他内容,因为不涉及编译器.如果没有聪明的编译器技巧,获得良好的性能将更加困难,因为它是JVM支持的"要求".

更长的解释:

通常,所有通常的"强大"控制结构在计算意义上是等同的并且可以彼此使用.

最着名的那些"强大的"通用控制流结构是令人尊敬的GOTO,另一个是Continuations.然后,有线程和协同程序,以及人们通常不会想到的,但这也等同于GOTO:异常.

一种不同的可能性是重新调用的调用堆栈,因此调用堆栈可以作为程序员的对象访问,并且可以被修改和重写.(例如,许多Smalltalk方言就是这样做的,它也很像C和汇编中的方式.)

只要你有其中一个,你就可以拥有所有这些,只需在另一个上面实现一个.

JVM有两个:例外和GOTO,但是GOTOJVM中不是通用的,它非常有限:它只能单个方法中运行.(它主要用于循环.)因此,这给我们留下了例外.

因此,这是您的问题的一个可能的答案:您可以在例外之上实现协同例程.

另一种可能性是不使用JVM的控制流在所有和实现自己的堆栈.

但是,这通常不是在JVM上实现协同例程时实际采用的路径.最有可能的是,实现协同例程的人会选择使用Trampolines并将执行上下文部分重新作为对象.也就是说,例如,如何在CLI上的C♯中实现生成器(不是JVM,但挑战类似).C♯中的生成器(基本上是受限制的半协同例程)是通过将方法的局部变量提升到上下文对象的字段中并在每个yield语句中将该方法拆分为该对象上的多个方法,将它们转换为状态来实现的.机器,并通过上下文对象上的字段仔细线程化所有状态更改.在作为语言特性出现之前async/ await之后,一个聪明的程序员也使用相同的机制实现了异步编程.

然而,这就是你指出的文章最有可能提到的:所有这些机器都是昂贵的.如果你实现自己的堆栈或将执行上下文提升到一个单独的对象中,或者将所有方法编译成一个巨大的方法并GOTO在任何地方使用(由于方法的大小限制,甚至不可能),或者使用Exceptions作为控制 -流程,这两件事中至少有一件是真的:

  • 您的调用约定与其他语言期望的JVM堆栈布局不兼容,即您失去了互操作性.
  • JIT编译器不知道你的代码是在干嘛,并呈现字节码图案,执行流程模式和使用模式(如抛出和捕获极大的相量例外),它不指望,不知道如何优化,即你失去了表现.

Rich Hickey(Clojure的设计师)曾在一次演讲中说过:"Tail Calls,Performance,Interop.Pick Two." 我把它概括为我称之为Hickey的Maxim:"高级控制流,性能,互操作.选择两个."

事实上,这通常很难实现,甚至一个互操作或性能.

此外,您的编译器将变得更加复杂.

当构造在JVM中本地可用时,所有这一切都消失了.想象一下,例如,如果JVM没有Threads.然后,每个语言实现都会创建自己的Threading库,这个库很难,很复杂,很慢,并且不能与任何其他语言实现的Threading库互操作.

一个最近的,现实世界的例子是lambdas:JVM上的许多语言实现都有lambda,例如Scala.那么Java添加lambda表达式为好,但因为JVM不支持lambda表达式,它们必须被编码不知何故,和甲骨文选择的编码是从一个斯卡拉之前选择了,这意味着你不能传递一个Java拉姆达不同期待Scala的Scala方法Function.这种情况下的解决方案是Scala开发人员完全重写了lambda的编码,以便与Oracle选择的编码兼容.这实际上在某些地方打破了向后兼容性.


Tod*_*odd 23

来自CorotinesKotlin文档(强调我的):

协同程序通过将并发症放入库中来简化异步编程.程序的逻辑可以在协程中顺序表示,底层库将为我们找出异步.该库可以将用户代码的相关部分包装到回调中,订阅相关事件,在不同线程(甚至不同的机器上)上安排执行!并且代码保持简单,就像它被顺序执行一样.

简而言之,它们被编译成使用回调和状态机来处理挂起和恢复的代码.

项目负责人Roman Elizarov在2017年KotlinConf上就此主题进行了两次精彩的演讲.一个是Coroutines简介,第二个是Coroutines深度潜水.

  • `使用回调和状态机` - 一个小的修正:在编译的代码中没有回调,因为FSM就像它们一样 (3认同)