Java平台的DLR：Da Vinci Machine项目

12顶
1踩

2008-05-28 11:42 by 见习编辑 Eastsun 评论(10) 有4854人浏览

Java performance java7 JVM

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

　　我们知道M$的.NET平台在CLR的基础上增加了一个所谓的DLR（动态语言运行时），可以为在.NET平台实现动态语言提供方便；虽然目前运行在JAVA平台的动态语言也有很多种，并且在Java6中引入了JSR223来更好的支持动态语言，但相比.NET似乎还稍嫌不足。
　　不过目前JAVA平台对动态语言支持上的一些不足，在JAVA的以后版本将会得到改善。JAVA7中就将引入JSR 292通过在JVM中添加一个新的字节码来提高JVM上运行动态语言的性能（见： Java7的invokedynamic指令草案已经公布）。
　　而且，JAVA社区对JAVA平台的期望不止这些。这里有一个Da Vinci Machine 项目，该项目的主要目的是通过扩展JVM，使其更好的支持更加广泛的各种语言，包括函数式语言以及动态语言，使它们在JVM上的运行性能能媲美当前JAVA语言的性能。

引用

We are extending the JVM with first-class architectural support for languages other than Java, especially dynamic languages. This project will prototype a number of extensions to the JVM, so that it can run non-Java languages efficiently, with a performance level comparable to that of Java itself.

　　该项目的主要子项目是支持动态调用；此外还支持许多其他子项目，包括增加对尾调用和尾递归（通过一个新的tailcall字节码前缀）、三元体（使用一个新的tagged tuple签名字符）的支持。这些特性的一部分将采纳到JAVA7虚拟机规范。
　　个人认为，该项目对多语言的支持方式比.NET平台的DLR更加具有优势。按照我的理解（对.NET平台不熟悉，如有不当望指出）：.NET的DLR是基于CLR的，它相当于在CLD之上再增加了一层抽象，它首先将动态语言编译为一个表达式树（AST），实际执行的时候再再CLR上展开这个AST。这样做只是方便了在.NET平台添加新的动态语言，但对提高动态语言在CLR上的运行效率看不出有太大作用。
　　而JAVA是从JVM上着手改进对动态语言的支持，能够很好的利用当前已经很成熟的JIT技术对动态语言的性能进行优化，这对性能的提高是不言而喻的。

来自: http://openjdk.java.net/projects/mlvm/

分享到：

12
顶

1
踩

评论共 10 条请登录后发表评论

10 楼 ray_linn 2008-05-30 18:31

另外应该考虑的是Microsoft的Dynamic language的应用场景,Microsoft的javascript, ruby, python和vbx,他们被使用在WPF/Silverlight中作为Embeded script使用,这些Script通常都是短小的片段,即使AST有所损失，影响也不大.

DLR的优化策略是寻找一条最可能的静态类型路径,这样动态语言就成为了静态语言,效率就提升了.

9 楼 Eastsun 2008-05-30 15:00

呵呵，对DLR/JIT的内部究竟是怎样优化的，俺也不懂。
说说而已，不必太认真。

等到JDK7出来后，实际测试一下就知分晓。

8 楼 ray_linn 2008-05-30 13:01

俺觉得你最后那条依据非常的不充分，不懂的人还以为是JIT起的作用。

7 楼 ray_linn 2008-05-30 12:58

AST并不是软解码，AST最重要的是建立动态类型系统与静态类型系统的匹配，或叫类型推断，JVM无论如何增加JVM，并不能更改Java是静态类型语言的本质。所以它也必须进行这一层翻译，这层翻译的实现是决定彼此性能优劣的关键。

6 楼 Eastsun 2008-05-30 12:16

引用

ray_linn 2008-05-30 10:48
假如我使用python写了个jar（最后它也是java的IL)，那么现有java 6.0的就无法调用该jar。如果Da Vinci Machine 不能成为标准，那么它就分裂了java阵营，（这和当年的VJ++是一样的，VJ++兼容了java 1.1，但java 1.1无法兼容VJ++）。

那么你这里的兼容性是指“向前兼容性”了？
就是说Java7编译的class不能运行在Java7之前的JRE中？
我觉这不是个问题，对于动态语言保持源代码级的兼容就够了。而且我更倾向于允许一些不兼容性的存在，这样语言才能进化。

至于Da Vinci Machine，我觉得可以把它看成一块试验田：有什么想法先在上面实现，然后大家可以去尝试。实践证明是有用的，再把它加到Java标准不迟。
而且Java开源后这种情况是不可避免的，以后肯定会有更多的非正统Java的版本出现。

引用

文章最后一条得出“能够很好的利用当前已经很成熟的JIT技术对动态语言的性能进行优化”这是明显错误的，大部分VM都采用了JIT技术，哪怕是MS DLR也能享受JIT技术，这得益于MS的类型缓存技术。

最后要说的是动态语言的性能缺陷是运行时类型推断造成的，我不觉得在JVM里加入指令能解决这个问题。

当然，只要是运行在JVM或CLR上，最后的形式都是bytecode，都会用到JIT技术。
但不同的是，DLR是在CLR之上先做了一层抽象；而Java7直接由JVM来做这件事。
怎么说呢，做个不太恰当的比喻，我觉得DLR就像是软解码，而Java7就像是硬解码。

引用

最后Java DLR能不能胜过MS DLR，完全取决于他们各自的实现和战略.

的确，一个产品能不能成功，技术并非决定性的因素。

5 楼 ray_linn 2008-05-30 10:48

假如我使用python写了个jar（最后它也是java的IL)，那么现有java 6.0的就无法调用该jar。如果Da Vinci Machine 不能成为标准，那么它就分裂了java阵营，（这和当年的VJ++是一样的，VJ++兼容了java 1.1，但java 1.1无法兼容VJ++）。

文章最后一条得出“能够很好的利用当前已经很成熟的JIT技术对动态语言的性能进行优化”这是明显错误的，大部分VM都采用了JIT技术，哪怕是MS DLR也能享受JIT技术，这得益于MS的类型缓存技术。

最后要说的是动态语言的性能缺陷是运行时类型推断造成的，我不觉得在JVM里加入指令能解决这个问题。

最后Java DLR能不能胜过MS DLR，完全取决于他们各自的实现和战略。

4 楼 Eastsun 2008-05-29 20:19

引用

ray_linn 2008-05-29 16:35
扩展JVM就直接导致不具备兼容性,而.NET的方法却能让C#调用IronRuby,孰优孰劣就难说了.

.NET的DLR上直接为.NET的战略服务的,即提高.NET语言间的操作性,Java呢?它的战略是什么??还是跟风?

你这里的“兼容性”指什么？
向后兼容性还是其它？

3 楼 ray_linn 2008-05-29 16:51

即使是JVM添加指令（就扩展JVM）也得解决静态类型和动态类型的匹配问题。

2 楼 ray_linn 2008-05-29 16:49

PS:

Microsoft采用的是Python AST---DLR AST---JIT的方式，缓慢的地方应该是DLR AST to JIT的地方，但是动态语言性能不佳的地方不是在to JIT，而是在于每个调用点上发生的额外检查和搜索，JVM添加指令未必对此有帮助。

1 楼 ray_linn 2008-05-29 16:35

扩展JVM就直接导致不具备兼容性,而.NET的方法却能让C#调用IronRuby,孰优孰劣就难说了.

.NET的DLR上直接为.NET的战略服务的,即提高.NET语言间的操作性,Java呢?它的战略是什么??还是跟风?

发表评论

您还没有登录,请您登录后再发表评论

12顶1踩