大家讨论一下embedded jvm啊

群组首页 → 编程语言 → 高级语言虚拟机 → 论坛

发表回复

tian06100102 2011-11-23

目前做的特别好的

ray_linn 2011-11-29

jvm不知道，.net有 micro framework，直接贴着硬件层的。

tian06100102 2011-12-03

有KVM，PhoneME advanced, Cacao，JamVm等，现在想找一个点研究来写硕士论文，自己也对这方面不是很了解。求大牛们指导分析一下。

RednaxelaFX 2011-12-03

原来是硕士论文的选题。那你想做什么方面的课题呢？
例如说省电啊、安全啊之类的？

tian06100102 2011-12-08

RednaxelaFX 写道

原来是硕士论文的选题。那你想做什么方面的课题呢？
例如说省电啊、安全啊之类的？

我最近正在查所有外文数据库关于这个方向的。之前没想到省电方向，在从安全，小，实时这几个方面找可以写的点。大拿有啥好点子。

RednaxelaFX 2011-12-08

嗯…我也不太清楚。在嵌入式设备上为了提高VM的性能同时考虑省空间和省电的因素而采用trace-based compiler方面的研究近年不少。Google Android里的Dalvik VM也实际在用这样的技术了。不过不知道有啥实际部署了的嵌入式JVM是用trace-based compiler的呢？

安全的话，利用解释器或简单编译器的漏洞去攻击或许也是可搞的。有些VM在实现的时候图方便会留下后门，例如之前我就利用过HotSpot VM的后门玩过shell code。不过嵌入式设备上的JVM很多都对安全比较关注，或者是像Java ME的CLDC规范不需要支持反射之类的，有些漏洞或许是“若隐若现”的，要真找出一两个可利用的漏洞需要运气和经验。

还有看看有没有办法做更多的静态校验和更少的动态校验来维持一个高安全级别同时又运行得快之类的。

小的话…其实以Java SE Embedded来看，Oracle都在试图把Java SE用到一些比较高端的嵌入式设备上了，也计划为Java ME的CDC添加更多功能让它更接近Java SE，或许论证一下“为何这样是可行的”也可以写点什么。当然这些高端设备都已经算不上传统意义上的嵌入式设备了…恐怕比我家里放着的古董486的计算能力都高了。
之前在Java One上见到过跑Java SE Embedded的智能电表，里面还运行着Java版Berkeley DB，这就是一个应用实例。它里面的JVM也有开源版，可以参考这里：
http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/summary

省电是现在比较头疼的问题吧。嵌入式设备上的处理器速度提升得很快，内存容量也在涨，核数也上来了，使得手机上都可以跑并发GC了（见Dalvik）。唯独就是电池不够给力。位于核心的JVM假如能省电的话那自然是再好不过了。这方面就算不做创新去研究如何能省电且高效，至少想办法量化出一些典型设备在不同workload及不同VM实现上的耗电表现也不错。我没读过这方面的论文，不知道有多少现成的结论呢。

实时的话果然还是会倾向操作系统方面和GC方面吧？线程调度、进程间通信、上下文切换的开销的降低和“实时优先级任务”之类的概念都做了很多，适用于嵌入式设备的实时GC也有很多研究了，这方面我不太肯定是否值得钻。

tian06100102 2011-12-08

谢谢RednaxelaxFX~。

问几个还没太懂的问题：
1、为什么trace-based compiler能省电。

2、动态校验是指bytecode的verifer吗。那静态校验是之前的编译器检查吗？动态校验能维持高安全级别，静态校验能维持高速度。这样理解对吗

3、“计划为Java ME的CDC添加更多功能让它更接近Java SE”，这样不是与小矛盾吗？感觉嵌入式就是舍弃了一些功能，然后做小。

4、耗电不是硬件设计的问题吗？主频太高之类的。和JVM的设计的关系是？。

RednaxelaFX 写道

RednaxelaFX 2011-12-09

tian06100102 写道

问几个还没太懂的问题：
1、为什么trace-based compiler能省电。

2、动态校验是指bytecode的verifer吗。那静态校验是之前的编译器检查吗？动态校验能维持高安全级别，静态校验能维持高速度。这样理解对吗

3、“计划为Java ME的CDC添加更多功能让它更接近Java SE”，这样不是与小矛盾吗？感觉嵌入式就是舍弃了一些功能，然后做小。

4、耗电不是硬件设计的问题吗？主频太高之类的。和JVM的设计的关系是？。

1、这是相对于传统的以方法/函数为编译单元的编译器而言的。例如说如果不做内联，那么同样是编译一个方法，以方法为编译单元的编译器需要处理整个方法的控制流图，无论其中是否存在根本未执行过的路径或很少执行的路径；trace-based compiler一定只会编译执行过且相对较热的路径，控制流简单（看设计取舍，最简单的情况下一个trace只会有单一入口，控制流非常简单，这样要是用SSA形式的IR的话有可能连Phi都不用）。总之就是简单的情况下trace-based compiler见效快，编译成本低，所以：
a) 更早让Java程序进去较快的运行阶段，更快的完成同样的计算任务通常更省电；
b) 编译开销低，在编译器上消耗的电也少。

2、我这里说的校验都是bytecode verifier。像桌面上的HotSpot VM就是总是在运行时做完整的bytecode verification的（除了后门之外），这样肯定保证安全，但会有一定开销（.NET的CLR的话，校验与JIT编译融合在一起了所以开销给隐藏了，但HotSpot VM的实现中校验跟解释器、编译器都是分离的，模块性是好而开销没隐藏起来）。别的做法，例如说要是有个设备，一旦class信息写到（或者说下载到）设备上之后就不可修改，这样就可以在刚下载下来的时候做部分校验（这里叫静态校验），而在运行的时候减少校验开销。

3、就是与“小”正好是相反的方向。背景是现在很多所谓的嵌入式设备其实运算能力和存储空间都相当高了。我的想法是很多论文都是向着“小”的方向去的，那么反其道而行的主题或许会比较有趣。

4、关于省内存与省电，你可以参考一下2008年Google I/O上关于Dalvik VM的演讲，http://www.tudou.com/programs/view/rfRoG3TkJ8U/。跟前面说的第一点一样，省电在软件层面也是很重要的，同样的操作如果能更快完成本身就可能带来省电的效果，特别是像JVM这种有大循环的程序。

nkhanxh 2011-12-14

我有个问题问RednaxelaFX，我看资料说，目前的jit就是trace based吧？都是看到热点之后再编译的，为了节省程序启动时间，并且让编译时间少占用用户时间。

RednaxelaFX 写道

RednaxelaFX 2011-12-14

nkhanxh 写道

那么先放个以前我在这边发过的帖的链接，从那边再延伸出去讨论如何？
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

发表回复

>>返回群组首页

大家讨论一下embedded jvm啊

相关讨论

相关资源推荐