对JVM的哪些更改最有利于Scala编译器和运行时？
通过引入InvokeDynamic计划到达JVM 7 的字节代码,动态语言将在性能上受益匪浅,Scala可能会受益于尾递归(不确定它是否会出现在JVM 8或更高版本中).
Scala及其现有功能集可以从JVM中获益吗？这些变化即将到来吗？
具体来说,JVM是否会对闭包和函数作为对象提高性能？
Kev*_*ght 26
基本上,约翰罗斯一直在竞选的一切:)
Fixnums - 消除装箱/拆箱原语的成本.
方法句柄 - 可以加速高阶函数并允许JVM更有效地优化它们.SAM类型有时可能需要在单态和多态呼叫站点之间进行笨拙的翻转/翻转,以防止内联.
Continuations - 根据node.js支持异步/并发设计
接口注入 - 简化mixin组合和角色的实现,并且在许多情况下无需生成某些中间类并使结构类型成为可能而无需反射.
尾调优化 - 应该是一个不用脑子:)
通常会引用Reification作为有利于Scala模式匹配的内容,但考虑到两种语言使用的不同方差方案,这在interop方面会产生很高的成本.在这一点上,我认为物化实际上可能造成的伤害远远超过它的好处.
我还认为期望任何会破坏Java的向后兼容性是不合理的.这不会发生.
kei*_*ter 13
Scala有一些功能可以在JVM中更好地实现,例如:
可在运行时访问的泛型.目前,scalac将泛型类型保存为隐藏字段(如果有问题的类是案例类).这使得泛型在案例类中不必要地昂贵.
声明 - 站点差异.Scala在定义站点指定类型参数的方差,而Java在调用站点处这样做.虽然这不太可能得到修复,因为它会破坏所有现有的Java通用代码.
尾调用优化.Scalac可以自己做一些尾调用优化,但只能用最简单的(自递归)情况.任何其他尾调用都将使用堆栈空间,就像在JVM中一样.
删除空指针.Scala已经可以使用Option [A]处理空引用,但由于它位于JVM上,对选项本身的引用可能为null,或者它的参数可能为null.所以你不能像Haskell那样得到非空的保证.
编辑:向列表添加声明站点方差.
Jes*_*erg 10
对于元组和case类,值类型将有助于提高性能.转义分析有助于减少这些对象的堆分配,但目前JVM无法积极地内联某些方法调用,因此无法消除这些小的不可变对象的堆分配.这导致堆垃圾并且执行时间增加3-4倍.
值类型还有助于增加数据位置并减少内存使用量.例如,在一个简单的Array [(Int,Int)]中,每个数组条目都有一个指针+对象头的开销.使用值类型,可以完全消除此开销.
| 归档时间： |
|
| 查看次数： |
2012 次 |
| 最近记录： |