大家讨论一下embedded jvm啊
 |
nkhanxh
2011-12-26
RednaxelaFX 写道 nkhanxh 写道 我有个问题问RednaxelaFX，我看资料说，目前的jit就是trace based吧？都是看到热点之后再编译的，为了节省程序启动时间，并且让编译时间少占用用户时间。
那么先放个以前我在这边发过的帖的链接，从那边再延伸出去讨论如何？ http://hllvm.group.iteye.com/group/topic/17798 在某些上下文里，一个“trace”跟一个“extended basic block”是可以等价的。可以参考另一篇：http://www.masonchang.com/blog/2009/1/13/the-difference-between-extended-basic-blocks-and-traces.html 不好意思，这几天有事，都没来。 我在你那篇里面回复了，不过是讨论那里面的问题。 我理解你得意思了dalvik的jit还不很完善是吧？ |
|
nkhanxh
2011-12-27
RednaxelaFX 写道 nkhanxh 写道 我有个问题问RednaxelaFX，我看资料说，目前的jit就是trace based吧？都是看到热点之后再编译的，为了节省程序启动时间，并且让编译时间少占用用户时间。
那么先放个以前我在这边发过的帖的链接，从那边再延伸出去讨论如何？ http://hllvm.group.iteye.com/group/topic/17798 在某些上下文里，一个“trace”跟一个“extended basic block”是可以等价的。可以参考另一篇：http://www.masonchang.com/blog/2009/1/13/the-difference-between-extended-basic-blocks-and-traces.html 抱歉，是我晕头了。jit和trace based还是有点区别的。 应该是trace based是结合了解释器和jit，解释器来跟踪，jit来编译。 这样可以更好的找到热点。trace trees等术语我还没有来得及阅读到。 初来乍到，非常感谢redFx的帮助！希望有机会多向你请教。 |
 |
RednaxelaFX
2011-12-27
nkhanxh 写道 抱歉，是我晕头了。jit和trace based还是有点区别的。
应该是trace based是结合了解释器和jit，解释器来跟踪，jit来编译。 这样可以更好的找到热点。trace trees等术语我还没有来得及阅读到。 初来乍到，非常感谢redFx的帮助！希望有机会多向你请教。 这个也不完全对。Trace-base compiler主要在运行过程中记录下实际执行经过的trace，然后以trace为编译单元进行编译。但并不是一定要用解释器来记录trace的。 这边有TraceMonkey记录trace的方式的简介：http://andreasgal.com/2008/05/21/recording-traces-in-spidermonkey/ 这是典型的使用解释器来记录trace的做法。这么做的好处自然是实现起来比较简单。 但也完全可以实现这样的多层纯编译系统： 1、第一次执行某个方法（或“代码块”，取决于具体实现的叫法）就通过template-based方式实现的baseline compiler超快速的编译掉该方法，不需要做任何优化；并在某些特定位置生成计数代码，例如方法入口与回边（backedge处）。然后运行这个版本的代码。 2、当某些方法的上述计数器超过一定阈值时，将这些方法重新编译一次；这次在每个涉及中间指令边界的地方都生成额外的记录代码。然后执行这个版本的代码（可以只执行一次也可以多执行几次），得到trace。 3、编译掉前面记录到的trace，并在后续执行中使用最后编译的这个版本。 请参考这两个项目，都是无解释器的trace-based compiler系统： http://research.microsoft.com/en-us/projects/spur/ http://www.ics.uci.edu/~franz/Site/pubs-pdf/ICS-TR-10-01.pdf 我只是想说用不用解释器不是trace-based compiler的关键点。当然，实际实用的trace-based compiler系统里很多都是有解释器的。 |
|
nkhanxh
2011-12-27
RednaxelaFX 写道 nkhanxh 写道 抱歉，是我晕头了。jit和trace based还是有点区别的。
应该是trace based是结合了解释器和jit，解释器来跟踪，jit来编译。 这样可以更好的找到热点。trace trees等术语我还没有来得及阅读到。 初来乍到，非常感谢redFx的帮助！希望有机会多向你请教。 这个也不完全对。Trace-base compiler主要在运行过程中记录下实际执行经过的trace，然后以trace为编译单元进行编译。但并不是一定要用解释器来记录trace的。 这边有TraceMonkey记录trace的方式的简介：http://andreasgal.com/2008/05/21/recording-traces-in-spidermonkey/ 这是典型的使用解释器来记录trace的做法。这么做的好处自然是实现起来比较简单。 但也完全可以实现这样的多层纯编译系统： 1、第一次执行某个方法（或“代码块”，取决于具体实现的叫法）就通过template-based方式实现的baseline compiler超快速的编译掉该方法，不需要做任何优化；并在某些特定位置生成计数代码，例如方法入口与回边（backedge处）。然后运行这个版本的代码。 2、当某些方法的上述计数器超过一定阈值时，将这些方法重新编译一次；这次在每个涉及中间指令边界的地方都生成额外的记录代码。然后执行这个版本的代码（可以只执行一次也可以多执行几次），得到trace。 3、编译掉前面记录到的trace，并在后续执行中使用最后编译的这个版本。 请参考这两个项目，都是无解释器的trace-based compiler系统： http://research.microsoft.com/en-us/projects/spur/ http://www.ics.uci.edu/~franz/Site/pubs-pdf/ICS-TR-10-01.pdf 我只是想说用不用解释器不是trace-based compiler的关键点。当然，实际实用的trace-based compiler系统里很多都是有解释器的。 多谢。感觉用解释器来做简单一些。如果纯粹用纯编译的话，是不是deoptimize有些麻烦？当然似乎deoptimzation也可以放进编译后的代码里面去。 我觉得总要有一个控制器（我叫他解释器，虽然他主要是控制的）来控制这个流程的。不然纯用注入的机器码虽然可以实现，但是似乎没有可预见到的好处？因为我觉得如果做profiling那些代码的耗费和被编译的部分比例已经到了需要考虑的地步了，似乎这个profiling就不怎么成功，不知道想的对不对? |
|
RednaxelaFX
2012-01-28
正好看到，顺便放个跟嵌入式JVM/能耗相关的论文：
Impact of JVM superoperators on energy consumption in resource-constrained embedded systems Carmen Badea, Alexandru Nicolau, Alexander V. Veidenbaum Jun. 2008 ACM SIGPLAN Notices Volume: 43 Issue: 7 Impact of JVM superoperators on energy consumption in resource-constrained embedded systems Carmen Badea, Alexandru Nicolau, Alexander V. Veidenbaum Jun. 2008 Proceedings of the 2008 ACM SIGPLAN-SIGBED conference on Languages, compilers, and tools for embedded systems |
