/** * In live var analysis a BB asks its successor (in essence) about which * vars are live, mixes it with its own uses and defs and passes on a * new list of live vars to its predecessors. Since the information * bubbles up the chain, we iterate the list in reverse order, for * efficiency. We could order the list topologically or do a depth-first * spanning tree, but it seems like overkill for most bytecode * procedures. The order of computation doesn't affect the correctness; * it merely changes the number of iterations to reach a fixpoint. * 变量活跃性分析,按照物理顺序,从最后一个块向前分析;把当前块及其物理后续块变量的活动性信息传递到下一个块(物理顺序前一块)进行分析。 * 如果一个变量只在当前块中有访问,而在物理后续块中没有,则说明此变量活动范围到当前块结束。 */ private void doLiveVarAnalysis() { ArrayList<BasicBlock> bbs = getBasicBlocks();//所有bb Collections.sort(bbs); // sorts in increasing startPos order boolean changed; do { changed = false; for (int i = bbs.size() - 1; i >= 0; i--) {//从后向前分析 changed = bbs.get(i).flowVarUsage() || changed;//一块块的分析 } } while (changed);//如果changed不为false,while内部循环可能走多次,这什么算法?因为successor每次都是不一样的in可能每次在变的 } //来看看BasicBlock.flowVarUsage的实现: public boolean flowVarUsage() { // for live var analysis, treat catch handlers as successors too. if (succUsage == null) {//catch handler里用到的变量也做分析 succUsage = new ArrayList<Usage>(successors.size() + handlers.size()); for (BasicBlock succ : successors) { succUsage.add(succ.usage); } for (Handler h : handlers) { succUsage.add(h.catchBB.usage); } } return usage.evalLiveIn(succUsage);//把当前bb中访问到的变量跟所有后继节点&catch handler中变量使用情况进行分析 } /** * This is the standard liveness calculation (Dragon Book, section 10.6). At each BB (and its * corresponding usage), we evaluate "in" using use and def. in = use U (out \ def) where out = * U succ.in, for all successors * 活跃变量分析,每个bb的in变量用use和def来表示,in = use 与 (out - def)的并集, out = successor.in的并集 * 目的何在? */ public boolean evalLiveIn(ArrayList<Usage> succUsage) { BitSet out = new BitSet(nLocals);//方法的maxLocals个bit BitSet old_in = (BitSet) in.clone(); if (succUsage.size() == 0) { in = use;//没有后继结点,in的就是当前bb use的 } else { // calculate out = U succ.in out = (BitSet) succUsage.get(0).in.clone(); for (int i = 1; i < succUsage.size(); i++) { out.or(succUsage.get(i).in); } // calc out \ def == out & ~def == ~(out | def) BitSet def1 = (BitSet) def.clone(); def1.flip(0, nLocals); out.and(def1); out.or(use); in = out; } return !(in.equals(old_in));//如果跟后继结点 }
相关推荐
Kilim 是一种 Java 消息传递框架,提供了超轻量级的线程,推动了线程之间迅速、安全、无需复制的消息传递的实现。 Kilim 使用 Java 编写,融入了角色模型的概念。在 Kilim 中,“角色” 是使用 Kilim 的 Task 类型...
JAVA版本他的系统源码Kilim :JVM 的延续、纤维、Actor 和消息传递 Kilim 由 2 个主要组件组成: Kilim weaver 修改已编译的 java 类的字节码,启用一种方法来保存它的状态并放弃对其线程的控制,即协同多任务 Kilim...
actor的一种实现,由于官网被屏蔽,所以上传到这里供大家下载
NULL 博文链接:https://eleopard.iteye.com/blog/1750384
具有Lindenmayer系统的程序性Kilim主题生成
Coroutine是基于Kilim/Promise JDeferred的协程式驱动框架,基于Apache Zookeeper的分布式规则存储和动态规则变更通知。 主要特性: 1. 基于微服务框架理念设计 2. 支持同步/异步调用 3. 支持串行/并行调用 4....
协程(Coroutine)理论上而言能够大幅度提升java应用所能支撑的并发量,目前java尚不能从语言层次上支持Coroutine,在Sun JDK7尚未正式发布的情况下如希望在java中使用Coroutine,Scala或Kilim是可行的选择。