RednaxelaFX
- 浏览: 3048111 次
- 性别:
- 来自: 海外
-
文章分类
- 全部博客 (430)
- Programming Languages (23)
- Compiler (20)
- Virtual Machine (57)
- Garbage Collection (4)
- HotSpot VM (26)
- Mono (2)
- SSCLI Rotor (1)
- Harmony (0)
- DLR (19)
- Ruby (28)
- C# (38)
- F# (3)
- Haskell (0)
- Scheme (1)
- Regular Expression (5)
- Python (4)
- ECMAScript (2)
- JavaScript (18)
- ActionScript (7)
- Squirrel (2)
- C (6)
- C++ (10)
- D (2)
- .NET (13)
- Java (86)
- Scala (1)
- Groovy (3)
- Optimization (6)
- Data Structure and Algorithm (3)
- Books (4)
- WPF (1)
- Game Engines (7)
- 吉里吉里 (12)
- UML (1)
- Reverse Engineering (11)
- NSIS (4)
- Utilities (3)
- Design Patterns (1)
- Visual Studio (9)
- Windows 7 (3)
- x86 Assembler (1)
- Android (2)
- School Assignment / Test (6)
- Anti-virus (1)
- REST (1)
- Profiling (1)
- misc (39)
- NetOA (12)
- rant (6)
- anime (5)
- Links (12)
- CLR (7)
- GC (1)
- OpenJDK (2)
- JVM (4)
- KVM (0)
- Rhino (1)
- LINQ (2)
- JScript (0)
- Nashorn (0)
- Dalvik (1)
- DTrace (0)
- LLVM (0)
- MSIL (0)
最新评论
-
mldxs：
虽然很多还是看不懂，写的很好！
虚拟机随谈（一）：解释器，树遍历解释器，基于栈与基于寄存器，大杂烩 -
HanyuKing：
Java的多维数组 -
funnyone：
Java 8的default method与method resolution -
ljs_nogard：
Xamarin workbook - .Net Core 中不 ...
LINQ的恶搞…… -
txm119161336：
allocatestlye1 顺序为 // Fields o ...
最近做的两次Java/JVM分享的概要
昨天承night_stalker老兄的提醒，去google了一下YARV，看看我是不是把事情记错了。记得Ruby还没1.9的时候我就稍微关注过YARV的信息，但印象中Ruby 1.9/YARV是没有JIT的……
Hmm，我貌似是没记错。目前的Ruby 1.9.1里并没有JIT。
首先需要定义我这里所指的JIT是什么。JIT，Just-In-Time Compiler，也就是所谓的即时编译器，其过程是JIT compilation，即时编译。
广义上说，只要有一个环境E直接支持某种语言B的运行，另外有一个程序是以语言A所编写的，在E上运行前没有单独的编译阶段，而是直接在运行前“即时”将A编译为B，这个即时编译的过程就可以称为JIT，无论A是高级语言也好字节码也好，B是别的字节码也好机器指令也好。
但实践中JIT一般是指将某种中间代码形式转换为机器指令的过程，及执行这个过程的编译器。例如说在x86上运行的Sun Hotspot JVM，其中的JIT会在一定条件下将JVM字节码编译为x86指令；或者说在x86上运行的微软CLR，其中的JIT会在执行某个托管方法之前先检查其是否已经被编译为x86指令，如果还没有的话就将其中的MSIL（CLR的字节码，也叫CIL）给JIT为x86指令，然后再执行那个方法。
Ruby（以下直接提到Ruby实现如无特别说明皆指CRuby，也就是官方版）在1.8系列及之前的版本采用的运行方式是：
Ruby源代码 => 解析为AST（抽象语法树） => 直接在抽象语法树上解释执行
由Sasada Koichi先生所写的YARV进化为了Ruby 1.9.x的虚拟机，它的运行方式是：
Ruby源代码 => 解析为AST => 从AST生成YARV字节码 => 直接在YARV字节码上解释执行
YARV后端的字节码解释器采用的是direct threaded code的解释方式，其特征是在每执行完一条指令之后直接对下一条指令解码，并直接跳转到下一条指令所对应的函数去；这样避免了使在一个大的中央循环内通过switch来做指令解码和分发，减少了CPU的分支预判的失败。在指令流水线较长的CPU上，这种技巧对提高执行速度很有好处。最经典的threaded code应该是各种Forth的实现，其中包括directed threaded code与indirected threaded code等不同的实现方式。
至少在Ruby 1.9.1上，YARV并没有将YARV字节码先JIT为本地机器指令后再执行。我认为这就可以称为“没有使用JIT”。
像是CPython的运行过程：
Python源代码 => 解析为AST => 从AST生成Python字节码 => 直接在Python字节码上解释执行
跟YARV的看起来很像对吧？如果YARV算是使用了JIT，那CPython自然也算是使用了JIT了。照这个推广，用JIT的解释器可就多了。老的SpiderMonkey（Mozilla FireFox的JavaScript引擎）也是先将源码编译为它自己的字节码然后在字节码上解释执行的，KJS（KDE Konqueror的JavaScript引擎）也是类似，……嘛
对YARV的实现方式有兴趣的话可以留意Ruby 1.9的源码里vm开头的源文件。其中字节码解释器的主循环在vm_exec.c的vm_exec_core()函数里；每条指令对应的函数则在vm.inc里。让我们看看其中加号对应的YARV字节码opt_plus的实现函数：
离JIT还是有一段距离的，嗯。
原本的YARV规划里是有JIT的，但，现实是在Ruby 1.9.1里它还没到位（*）。引用RubyConf 2005上Koichi先生的话：
和当时的图：
到RubyConf 2006的时候，AOT有进展了而JIT仍然没到位。
RubyConf 2008，Koichi先生第四次参加RubyConf……这次他没提到JIT的问题。还是得读代码去了解现状 =w=
（*）：或者它到位了而我没发现。求知道详情的讲解一下～～
=========================================================================
YARV自己是还没有JIT，不过这不能阻止其他人为YARV编写JIT后端。下面是相关的两个项目，yajit和yarv2llvm的一些链接：
Shinichiro Hamaji: yajit
Miura: yarv2llvm
Inside yarv2llvm(その1)
Inside yarv2llvm(その2)
Inside yarv2llvm(その3)
Inside yarv2llvm(その4)
Inside yarv2llvm(その5)
Inside yarv2llvm(その6)
=========================================================================
再看看JRuby。它的执行方式可以在启动JRuby虚拟机之前配置，例如说强制使用或禁用某些编译模式之类。
默认情况下，JRuby的运行方式是：
Ruby源代码 => 解析为AST => 在AST上解释执行（JRuby自己的解释器）
==> 某个CallSite的成功调用次数超过一定限制后（现在默认为是50次），将对应方法的AST即时编译为JVM字节码
（由JVM执行字节码，有没有进一步的JIT取决于JVM）
JRuby也有预先编译的模式：
运行之前做预先编译（AOT，Ahead-of-Time compilation）：
Ruby源代码 => 解析为AST => 将AST编译为JVM字节码
运行时：
JVM字节码由JVM执行（有没有JIT取决于JVM）
那JRuby算不算有JIT呢？
值得注意的是，JRuby自身是运行在JVM之上的。如果它底下的JVM是有JIT的，那么它也就算有了半个JIT。在JRuby的JIT模式被激活了之后，Ruby方法就会被JRuby编译为JVM字节码，进而有可能被JVM的JIT编译为本地机器指令。挺微妙的，呵呵。
至于JRuby的性能嘛，
Charles O. Nutter如是说："Noise Cancelling" (2008-11-23)
而根据Antonio Cangiano在2008-12-09的测试结果：The Great Ruby Shootout (December 2008)
当然，那是去年年底的测试结果，使用的还是JRuby 1.1.6RC1 vs Ruby 1.9.1；它们其实算是不相上下，各有侧重。现在JRuby已经出到1.2.0RC1了，性能比起1.1.6又有了一定的提升；官方Ruby方面则暂时还没发布1.9.2系列的preview。谁更快其实不好说。
其实要说“谁更快”很关键的一点在于自己的应用的类型。如果是I/O-bound的类型，那无论VM速度如何可能对应用的性能都不会带来多少影响；如果是需要真的并行计算，那么在当前的Ruby 1.9.1里的GIL限制显然会让它慢于支持真正多线程的JRuby；如果是需要高的交互性能，那么解释执行反而可能比JIT更合适，等等。有很多外在因素使得各种microbenchmark与实际自己的应用侧重的性能需求有所不同，所以基本上大家在提到benchmarks的时候都会说“Benchmarks are just lies damn lies”（引用自John Lam）
JRuby比较占优势的应该是长时间运行、多线程的应用场景。运行时间不够长的话JRuby主要是在解释模式运行的；只有当某个CallSite被调用了超过50次并且都是指向同一个目标时，JRuby才会考虑把目标方法编译为JVM字节码。在长时间、高强度的循环里这会带来一定的好处。
不过，不出意外的，JRuby的JIT对底下的Sun JVM的Hotspot JIT也会造成影响：Hotspot会根据它所看到的JVM字节码来决定是否做内联、peephole之类的优化；当执行路径发生改变时，Hotspot会发现它做的一些假设不成立了，于是要退回到解释JVM字节码的模式，重新对执行状况做分析。Charles提到过他们在对JRuby做benchmark的时候，发现有些benchmark在执行到50次之前都还好好的，反而在50次之后JRuby做了JIT使Hotspot退到了慢速路径上而且久久没能恢复过来。以后JRuby还有很多潜力可以挖掘，让它与Hotspot能更好的匹配。（然而专门对Hotspot做的优化对其它JVM或许又是个毒药……要留心）
=========================================================================
IronRuby是.NET上的Ruby实现，它运行在CLI之上；在微软平台上的话，CLI的实现就是CLR；在*-nix平台上则有Novell支持的Mono作为CLI的实现。Anyway，为了讨论的方便，就以CLR为具体例子来说明。
目前的IronRuby也有两种运行模式，一种是预先编译的模式，另一种是解释模式；目前前者是默认模式。
预先编译模式：
Ruby源代码 => 解析为AST => 将AST转换为Expression Tree => 从Expression Tree生成MSIL => 由CLR执行（CLR会JIT）
解释模式：
Ruby源代码 => 解析为AST => 将AST转换为Expression Tree => 由DLR解释执行Expression Tree
所以IronRuby算不算有JIT呢？跟JRuby有相似之处。也是很微妙。不过目前IronRuby的解释模式不会触发Expression Tree => MSIL的编译过程，比JRuby的自适应性要弱一些。
更新：新的DLR解释器也开始有自适应编译了：先解释执行ETv2，一个“方法”被调用三次才触发ETv2 => MSIL的编译。请见这帖：http://www.iteye.com/topic/353790
早期DLR的实现里就没有解释器，上层的语言实现将源码转换到DLR tree（现在与LINQ合并就叫做Expression Tree了）之后，DLR里的编译器就将DLR tree以LCG的方式编译为MSIL，得到LCG委托后去调用那个委托。
但是IronPython和IronRuby的实际表现使他们不得不考虑重新加入解释模式。去年下半年开始，DLR里就有一个通用的、功能简单的Expression Tree解释器了。上层的语言实现要用DLR的解释器基本上不用做多少修改，只要传入一个flag表明要解释执行即可。不过这个通用的解释器对语言特定的功能的支持可能不是最优的，所以如果要获得更高的解释性能，DLR允许语言实现自己插入解释器的实现。
John Lam在一些会议上也提到过IronRuby的发展过程与其它Ruby实现有所不同，就是IronRuby是先有编译模式再有解释模式。他提到在没有解释模式之前，IronRuby的启动速度慢得难以接受，而且在debug和交互式环境下编译的代价不值得，所以后来还是走回了解释的路上。
既然DLR已经有了纯解释模式，为了达到更好的性能平衡，以后发展出混合模式也是不奇怪的。
嗯我知道你那个是分布式的作业，之前在校内看到了。这方面在我的盲区内，没办法了（摊手
精华不精华不重要啦。倒是能召唤到些VM有爱人士就好了 T T
嗯肯定是说这个没错。
segfault可以是任何地方的Access violation，经常出问题的地方和显示出来的那块东西完全不搭界……
关键的一点是在1.9里面，RSRING(str)->ptr没有了（用StringValueCStr才对），在1.8下面编译的扩展必定会出问题。
不过Nokogiri的文档说它支持Ruby 1.9的嘛，所以我才试的。结果segfault让我一头雾水 T T
于是我知道了……呜哇，突然觉得有点不好意思了（奔
RPC的书在图书室里肯定有，去挖一下吧～说来我们是什么课提到RPC的来着，除了设计模式讲到代理的时候？莫非是大软……OTL
丫的，现在是分布式系统，嗯，设计模式的倒没有什么，细节太多了，我准备去图书馆看看。
你好好的一个精华帖被我变成水帖了，不好意思啊，哈哈～。
嗯肯定是说这个没错。
segfault可以是任何地方的Access violation，经常出问题的地方和显示出来的那块东西完全不搭界……
关键的一点是在1.9里面，RSRING(str)->ptr没有了（用StringValueCStr才对），在1.8下面编译的扩展必定会出问题。
不过Nokogiri的文档说它支持Ruby 1.9的嘛，所以我才试的。结果segfault让我一头雾水 T T
于是我知道了……呜哇，突然觉得有点不好意思了（奔
RPC的书在图书室里肯定有，去挖一下吧～说来我们是什么课提到RPC的来着，除了设计模式讲到代理的时候？莫非是大软……OTL
ID很眼熟但是我想不起来了，郁闷啊
最近我没怎么上MSN，印象中……如果我知道你是谁的话那我们肯定在MSN上聊过 OTL
呃……你在校内上不是说得火热嘛，这都不知道。
RPC原理我就没怎么看过。抱歉推荐不了什么书了。以前课上提到CORBA的时候稍微读过些零散的资料，都是放狗去找的……
唉，作业头疼啊
呃……你在校内上不是说得火热嘛，这都不知道。
RPC原理我就没怎么看过。抱歉推荐不了什么书了。以前课上提到CORBA的时候稍微读过些零散的资料，都是放狗去找的……
唉，作业头疼啊
segfault可以是任何地方的Access violation，经常出问题的地方和显示出来的那块东西完全不搭界……
关键的一点是在1.9里面，RSRING(str)->ptr没有了（用StringValueCStr才对），在1.8下面编译的扩展必定会出问题。
ID很眼熟但是我想不起来了，郁闷啊
最近我没怎么上MSN，印象中……如果我知道你是谁的话那我们肯定在MSN上聊过 OTL
RPC原理我就没怎么看过。抱歉推荐不了什么书了。以前课上提到CORBA的时候稍微读过些零散的资料，都是放狗去找的……
Hmm，我貌似是没记错。目前的Ruby 1.9.1里并没有JIT。
首先需要定义我这里所指的JIT是什么。JIT，Just-In-Time Compiler，也就是所谓的即时编译器，其过程是JIT compilation，即时编译。
广义上说，只要有一个环境E直接支持某种语言B的运行，另外有一个程序是以语言A所编写的，在E上运行前没有单独的编译阶段，而是直接在运行前“即时”将A编译为B，这个即时编译的过程就可以称为JIT，无论A是高级语言也好字节码也好，B是别的字节码也好机器指令也好。
但实践中JIT一般是指将某种中间代码形式转换为机器指令的过程，及执行这个过程的编译器。例如说在x86上运行的Sun Hotspot JVM，其中的JIT会在一定条件下将JVM字节码编译为x86指令；或者说在x86上运行的微软CLR，其中的JIT会在执行某个托管方法之前先检查其是否已经被编译为x86指令，如果还没有的话就将其中的MSIL（CLR的字节码，也叫CIL）给JIT为x86指令，然后再执行那个方法。
Ruby（以下直接提到Ruby实现如无特别说明皆指CRuby，也就是官方版）在1.8系列及之前的版本采用的运行方式是：
Ruby源代码 => 解析为AST（抽象语法树） => 直接在抽象语法树上解释执行
由Sasada Koichi先生所写的YARV进化为了Ruby 1.9.x的虚拟机，它的运行方式是：
Ruby源代码 => 解析为AST => 从AST生成YARV字节码 => 直接在YARV字节码上解释执行
YARV后端的字节码解释器采用的是direct threaded code的解释方式，其特征是在每执行完一条指令之后直接对下一条指令解码，并直接跳转到下一条指令所对应的函数去；这样避免了使在一个大的中央循环内通过switch来做指令解码和分发，减少了CPU的分支预判的失败。在指令流水线较长的CPU上，这种技巧对提高执行速度很有好处。最经典的threaded code应该是各种Forth的实现，其中包括directed threaded code与indirected threaded code等不同的实现方式。
至少在Ruby 1.9.1上，YARV并没有将YARV字节码先JIT为本地机器指令后再执行。我认为这就可以称为“没有使用JIT”。
像是CPython的运行过程：
Python源代码 => 解析为AST => 从AST生成Python字节码 => 直接在Python字节码上解释执行
跟YARV的看起来很像对吧？如果YARV算是使用了JIT，那CPython自然也算是使用了JIT了。照这个推广，用JIT的解释器可就多了。老的SpiderMonkey（Mozilla FireFox的JavaScript引擎）也是先将源码编译为它自己的字节码然后在字节码上解释执行的，KJS（KDE Konqueror的JavaScript引擎）也是类似，……嘛
对YARV的实现方式有兴趣的话可以留意Ruby 1.9的源码里vm开头的源文件。其中字节码解释器的主循环在vm_exec.c的vm_exec_core()函数里；每条指令对应的函数则在vm.inc里。让我们看看其中加号对应的YARV字节码opt_plus的实现函数：
vm.inc 写道
INSN_ENTRY(opt_plus){
{
VALUE val;
VALUE recv = TOPN(1);
VALUE obj = TOPN(0);
DEBUG_ENTER_INSN("opt_plus");
ADD_PC(1+0);
PREFETCH(GET_PC());
POPN(2);
#define CURRENT_INSN_opt_plus 1
#define INSN_IS_SC() 0
#define INSN_LABEL(lab) LABEL_opt_plus_##lab
#define LABEL_IS_SC(lab) LABEL_##lab##_##t
USAGE_ANALYSIS_INSN(BIN(opt_plus));
{
#line 1287 "insns.def"
if (0) {
}
#if 1
else if (FIXNUM_2_P(recv, obj) &&
BASIC_OP_UNREDEFINED_P(BOP_PLUS)) {
/* fixnum + fixnum */
#ifndef LONG_LONG_VALUE
val = (recv + (obj & (~1)));
if ((~(recv ^ obj) & (recv ^ val)) &
((VALUE)0x01 << ((sizeof(VALUE) * CHAR_BIT) - 1))) {
val = rb_big_plus(rb_int2big(FIX2LONG(recv)),
rb_int2big(FIX2LONG(obj)));
}
#else
long a, b, c;
a = FIX2LONG(recv);
b = FIX2LONG(obj);
c = a + b;
if (FIXABLE(c)) {
val = LONG2FIX(c);
}
else {
val = rb_big_plus(rb_int2big(a), rb_int2big(b));
}
#endif
}
#endif
else if (!SPECIAL_CONST_P(recv) && !SPECIAL_CONST_P(obj)) {
if (0) {
}
#if 1
else if (HEAP_CLASS_OF(recv) == rb_cFloat &&
HEAP_CLASS_OF(obj) == rb_cFloat &&
BASIC_OP_UNREDEFINED_P(BOP_PLUS)) {
val = DBL2NUM(RFLOAT_VALUE(recv) + RFLOAT_VALUE(obj));
}
#endif
#if 1
else if (HEAP_CLASS_OF(recv) == rb_cString &&
HEAP_CLASS_OF(obj) == rb_cString &&
BASIC_OP_UNREDEFINED_P(BOP_PLUS)) {
val = rb_str_plus(recv, obj);
}
#endif
#if 1
else if (HEAP_CLASS_OF(recv) == rb_cArray &&
BASIC_OP_UNREDEFINED_P(BOP_PLUS)) {
val = rb_ary_plus(recv, obj);
}
#endif
else {
goto INSN_LABEL(normal_dispatch);
}
}
else {
INSN_LABEL(normal_dispatch):
PUSH(recv);
PUSH(obj);
CALL_SIMPLE_METHOD(1, idPLUS, recv);
}
#line 1901 "vm.inc"
PUSH(val);
#undef CURRENT_INSN_opt_plus
#undef INSN_IS_SC
#undef INSN_LABEL
#undef LABEL_IS_SC
END_INSN(opt_plus);}}}离JIT还是有一段距离的，嗯。
原本的YARV规划里是有JIT的，但，现实是在Ruby 1.9.1里它还没到位（*）。引用RubyConf 2005上Koichi先生的话：
Sasada Koichi 写道
JIT Compilation
• I made easy one for x86, but…
• Too hard to do alone. I retired.
• I made easy one for x86, but…
• Too hard to do alone. I retired.
和当时的图：
到RubyConf 2006的时候，AOT有进展了而JIT仍然没到位。
RubyConf 2008，Koichi先生第四次参加RubyConf……这次他没提到JIT的问题。还是得读代码去了解现状 =w=
（*）：或者它到位了而我没发现。求知道详情的讲解一下～～
=========================================================================
YARV自己是还没有JIT，不过这不能阻止其他人为YARV编写JIT后端。下面是相关的两个项目，yajit和yarv2llvm的一些链接：
Shinichiro Hamaji: yajit
Miura: yarv2llvm
Inside yarv2llvm(その1)
Inside yarv2llvm(その2)
Inside yarv2llvm(その3)
Inside yarv2llvm(その4)
Inside yarv2llvm(その5)
Inside yarv2llvm(その6)
=========================================================================
再看看JRuby。它的执行方式可以在启动JRuby虚拟机之前配置，例如说强制使用或禁用某些编译模式之类。
默认情况下，JRuby的运行方式是：
Ruby源代码 => 解析为AST => 在AST上解释执行（JRuby自己的解释器）
==> 某个CallSite的成功调用次数超过一定限制后（现在默认为是50次），将对应方法的AST即时编译为JVM字节码
（由JVM执行字节码，有没有进一步的JIT取决于JVM）
JRuby也有预先编译的模式：
运行之前做预先编译（AOT，Ahead-of-Time compilation）：
Ruby源代码 => 解析为AST => 将AST编译为JVM字节码
运行时：
JVM字节码由JVM执行（有没有JIT取决于JVM）
那JRuby算不算有JIT呢？
值得注意的是，JRuby自身是运行在JVM之上的。如果它底下的JVM是有JIT的，那么它也就算有了半个JIT。在JRuby的JIT模式被激活了之后，Ruby方法就会被JRuby编译为JVM字节码，进而有可能被JVM的JIT编译为本地机器指令。挺微妙的，呵呵。
至于JRuby的性能嘛，
Charles O. Nutter如是说："Noise Cancelling" (2008-11-23)
Charles O. Nutter 写道
A year ago, we were generally a bit slower than Ruby 1.8.6; this year, we're faster in most cases than Ruby 1.9.
而根据Antonio Cangiano在2008-12-09的测试结果：The Great Ruby Shootout (December 2008)
Antonio Cangiano 09 Dec 2008 at 9:51 am 写道
JRuby was the second best, Ruby 1.9.1 was fastest.
当然，那是去年年底的测试结果，使用的还是JRuby 1.1.6RC1 vs Ruby 1.9.1；它们其实算是不相上下，各有侧重。现在JRuby已经出到1.2.0RC1了，性能比起1.1.6又有了一定的提升；官方Ruby方面则暂时还没发布1.9.2系列的preview。谁更快其实不好说。
其实要说“谁更快”很关键的一点在于自己的应用的类型。如果是I/O-bound的类型，那无论VM速度如何可能对应用的性能都不会带来多少影响；如果是需要真的并行计算，那么在当前的Ruby 1.9.1里的GIL限制显然会让它慢于支持真正多线程的JRuby；如果是需要高的交互性能，那么解释执行反而可能比JIT更合适，等等。有很多外在因素使得各种microbenchmark与实际自己的应用侧重的性能需求有所不同，所以基本上大家在提到benchmarks的时候都会说“Benchmarks are just lies damn lies”（引用自John Lam）
JRuby比较占优势的应该是长时间运行、多线程的应用场景。运行时间不够长的话JRuby主要是在解释模式运行的；只有当某个CallSite被调用了超过50次并且都是指向同一个目标时，JRuby才会考虑把目标方法编译为JVM字节码。在长时间、高强度的循环里这会带来一定的好处。
不过，不出意外的，JRuby的JIT对底下的Sun JVM的Hotspot JIT也会造成影响：Hotspot会根据它所看到的JVM字节码来决定是否做内联、peephole之类的优化；当执行路径发生改变时，Hotspot会发现它做的一些假设不成立了，于是要退回到解释JVM字节码的模式，重新对执行状况做分析。Charles提到过他们在对JRuby做benchmark的时候，发现有些benchmark在执行到50次之前都还好好的，反而在50次之后JRuby做了JIT使Hotspot退到了慢速路径上而且久久没能恢复过来。以后JRuby还有很多潜力可以挖掘，让它与Hotspot能更好的匹配。（然而专门对Hotspot做的优化对其它JVM或许又是个毒药……要留心）
=========================================================================
IronRuby是.NET上的Ruby实现，它运行在CLI之上；在微软平台上的话，CLI的实现就是CLR；在*-nix平台上则有Novell支持的Mono作为CLI的实现。Anyway，为了讨论的方便，就以CLR为具体例子来说明。
目前的IronRuby也有两种运行模式，一种是预先编译的模式，另一种是解释模式；目前前者是默认模式。
预先编译模式：
Ruby源代码 => 解析为AST => 将AST转换为Expression Tree => 从Expression Tree生成MSIL => 由CLR执行（CLR会JIT）
解释模式：
Ruby源代码 => 解析为AST => 将AST转换为Expression Tree => 由DLR解释执行Expression Tree
所以IronRuby算不算有JIT呢？跟JRuby有相似之处。也是很微妙。不过目前IronRuby的解释模式不会触发Expression Tree => MSIL的编译过程，比JRuby的自适应性要弱一些。
更新：新的DLR解释器也开始有自适应编译了：先解释执行ETv2，一个“方法”被调用三次才触发ETv2 => MSIL的编译。请见这帖：http://www.iteye.com/topic/353790
分享到：
评论
25 楼
夜鸣猪
2009-03-11
专程学习，先留脚印
24 楼
RednaxelaFX
2009-03-09
yawl 写道
我觉得ironruby不会实现jruby的那种‘混合’模式，对它来说没有必要。
早期DLR的实现里就没有解释器，上层的语言实现将源码转换到DLR tree（现在与LINQ合并就叫做Expression Tree了）之后，DLR里的编译器就将DLR tree以LCG的方式编译为MSIL，得到LCG委托后去调用那个委托。
但是IronPython和IronRuby的实际表现使他们不得不考虑重新加入解释模式。去年下半年开始，DLR里就有一个通用的、功能简单的Expression Tree解释器了。上层的语言实现要用DLR的解释器基本上不用做多少修改，只要传入一个flag表明要解释执行即可。不过这个通用的解释器对语言特定的功能的支持可能不是最优的，所以如果要获得更高的解释性能，DLR允许语言实现自己插入解释器的实现。
John Lam在一些会议上也提到过IronRuby的发展过程与其它Ruby实现有所不同，就是IronRuby是先有编译模式再有解释模式。他提到在没有解释模式之前，IronRuby的启动速度慢得难以接受，而且在debug和交互式环境下编译的代价不值得，所以后来还是走回了解释的路上。
既然DLR已经有了纯解释模式，为了达到更好的性能平衡，以后发展出混合模式也是不奇怪的。
23 楼
night_stalker
2009-03-09
不知道萝卜ruby效果怎么样，召唤考据党
22 楼
yawl
2009-03-09
我觉得ironruby不会实现jruby的那种‘混合’模式，对它来说没有必要。
jruby那样做有历史原因。因为最早的jruby,在charles nutter和tom之前，解释器已经做了，基本上是从c代码port到java的。后来不断积累完善，大多ruby代码能在下面跑的好好的了。
jruby的编译是比较后加入的，其实直到现在也不能完整的把ruby代码全部编译执行。所以charles一直用了个简单的办法--先'试图'编译一下，不行的话解释AST的老办法。这个实际效果其实很不错，用户的代码仍然跑得好好的（因为最差情况也就是继续解释AST的老办法），也能感受编译的好处。
ironruby是从头开始的，没有必要去花很大力气去做一个ruby 1.8那种的落后的解释器。
jruby那样做有历史原因。因为最早的jruby,在charles nutter和tom之前，解释器已经做了，基本上是从c代码port到java的。后来不断积累完善，大多ruby代码能在下面跑的好好的了。
jruby的编译是比较后加入的，其实直到现在也不能完整的把ruby代码全部编译执行。所以charles一直用了个简单的办法--先'试图'编译一下，不行的话解释AST的老办法。这个实际效果其实很不错，用户的代码仍然跑得好好的（因为最差情况也就是继续解释AST的老办法），也能感受编译的好处。
ironruby是从头开始的，没有必要去花很大力气去做一个ruby 1.8那种的落后的解释器。
21 楼
tetsu.soh
2009-03-09
好文章。
回答我关于Ruby和JIT问题的就是你啊～，没想到下来又做了这么多功课，佩服佩服。
看你的Blog里，有日文Site的引用，难道还精通日文？！好厉害的说。
我也是个学生，在语言实现方面还是新米。很多东西都不懂，目前正在补功课。以后有机会多多交流啊～
回答我关于Ruby和JIT问题的就是你啊～，没想到下来又做了这么多功课，佩服佩服。
看你的Blog里，有日文Site的引用，难道还精通日文？！好厉害的说。
我也是个学生，在语言实现方面还是新米。很多东西都不懂，目前正在补功课。以后有机会多多交流啊～
20 楼
RednaxelaFX
2009-03-09
呵呵，嗯。确实许多问题都是这样，概念本身的定义太困难，或者说对概念的了解还不够透彻使得定义很暧昧。所以使用概念前都需要在语境下做一次明确的定义来解决当前语境下的概念分歧。
跟JIT相关，另外一个概念也是经常被弄得很混乱的：虚拟机。如果说Hotspot和VMWare都是虚拟机，它们却又很明显不一样。于是出现了高级语言虚拟机、应用虚拟机、系统虚拟机等概念。然后像是虚拟机的执行方式，有二进制翻译和二进制解释两种；而Hotspot等带有JIT的虚拟机却模糊了这个界线。
跟JIT相关，另外一个概念也是经常被弄得很混乱的：虚拟机。如果说Hotspot和VMWare都是虚拟机，它们却又很明显不一样。于是出现了高级语言虚拟机、应用虚拟机、系统虚拟机等概念。然后像是虚拟机的执行方式，有二进制翻译和二进制解释两种；而Hotspot等带有JIT的虚拟机却模糊了这个界线。
19 楼
night_stalker
2009-03-09
还是维特根斯坦他老人家说得好：
问题无解，原因往往就是问题定义有问题，或者人类智能无法理解此概念。(大意..)
JIT就是个暧昧的概念，"Ruby是不是JIT了"就是个有问题的问题。
问题无解，原因往往就是问题定义有问题，或者人类智能无法理解此概念。(大意..)
JIT就是个暧昧的概念，"Ruby是不是JIT了"就是个有问题的问题。
18 楼
RednaxelaFX
2009-03-09
没错，Charles Nutter说的“JRuby的JIT”指的是JRuby将Ruby源码编译到JVM字节码的过程，与我所说的JIT不相符。但同时JVM字节码是有机会被JVM所JIT的。所以在JRuby做了JIT、JVM也做了JIT之后，整个过程就符合我所说的JIT了。所以说很微妙。
IronRuby方面比JRuby……或许没那么微妙。现在的IronRuby如果是在默认模式，会一口气把Ruby源码都解析为Expression Tree。然后DLR会将Expression Tree编译为MSIL。接着CLR会将MSIL给JIT成本地机器指令。整个过程没任何可选部分，整体上看就等同于把Ruby源码JIT到了本地机器指令才执行。
IronRuby的以后肯定也会实现混合模式的运行方式，虽然现在还没有。DLR有默认的解释模式，这种模式下Expression Tree只用于解释而不编译到MSIL。相对来说自适应性就没了。
JRuby默认用的是混合模式的运行方式，在刚启动时采用纯解释模式，在达到一些条件之后对部分热点做“JRuby的JIT”。之所以是“部分热点”是因为多了会塞爆PermGen；JRuby得对每个“JIT”出来的类用单独的class loader来加载，以保证在达到内存使用上限时能卸载掉一些老的“JIT”出来的类。
JRuby对Ruby核心库是有特别实现的：核心库的功能是用Java实现的，运行时创建许多小的包装类来实现快速调用，这样可以用相对具体的signature来从Ruby调用底下的Java方法。用比较具体的signature可以减少通用signature中varargs数组的包装，减轻GC的负担。对一般的Java库，JRuby还是用普通的反射来做调用的。
JRuby巨占资源这点恐怕比较难改善。以后invokedynamic正式合并到JVM spec里的话可以减少对包装类的需求，那样是可以减少一些资源占用。不过JVM本身就不是省油的灯就是了，呃呵呵。
不知道Sun的Kenai后面是用怎样的机器撑着的呢？有人有了解么？用JRuby on Rails来做hosting还真是一强悍的广告……
IronRuby方面比JRuby……或许没那么微妙。现在的IronRuby如果是在默认模式，会一口气把Ruby源码都解析为Expression Tree。然后DLR会将Expression Tree编译为MSIL。接着CLR会将MSIL给JIT成本地机器指令。整个过程没任何可选部分，整体上看就等同于把Ruby源码JIT到了本地机器指令才执行。
IronRuby的以后肯定也会实现混合模式的运行方式，虽然现在还没有。DLR有默认的解释模式，这种模式下Expression Tree只用于解释而不编译到MSIL。相对来说自适应性就没了。
JRuby默认用的是混合模式的运行方式，在刚启动时采用纯解释模式，在达到一些条件之后对部分热点做“JRuby的JIT”。之所以是“部分热点”是因为多了会塞爆PermGen；JRuby得对每个“JIT”出来的类用单独的class loader来加载，以保证在达到内存使用上限时能卸载掉一些老的“JIT”出来的类。
JRuby对Ruby核心库是有特别实现的：核心库的功能是用Java实现的，运行时创建许多小的包装类来实现快速调用，这样可以用相对具体的signature来从Ruby调用底下的Java方法。用比较具体的signature可以减少通用signature中varargs数组的包装，减轻GC的负担。对一般的Java库，JRuby还是用普通的反射来做调用的。
JRuby巨占资源这点恐怕比较难改善。以后invokedynamic正式合并到JVM spec里的话可以减少对包装类的需求，那样是可以减少一些资源占用。不过JVM本身就不是省油的灯就是了，呃呵呵。
不知道Sun的Kenai后面是用怎样的机器撑着的呢？有人有了解么？用JRuby on Rails来做hosting还真是一强悍的广告……
17 楼
yawl
2009-03-09
这个看你怎么抠概念了。
比如charles nutter一直说的jruby的'JIT',就完全不符合你说的JIT概念。jruby是混合模式，有些代码是自己直接解释AST,有些是编译成java字节码交给jvm。他所指的jit其实就是运行时编译的部分。
ruby的1.8及之前的实现，确实很业余。这点matz也承认。同样做个loop的话，ruby比其他语言慢几十上百倍。1.9改进了解释器的实现。在benchmark上轻松的上了个大台阶。
但是诸如rails这样的应用，loop快上几十倍就没大关系了，也就是几毫秒和几十毫秒的区别。同时，你的页面里也许有几个sql query,瓶颈大多在其他方面上了。我猜这是rails在1.9上目前没有大的提高的原因吧。
我也试过在jruby上跑过rails程序，和robbin说的一样，挺慢的，而且巨占资源。
比如charles nutter一直说的jruby的'JIT',就完全不符合你说的JIT概念。jruby是混合模式，有些代码是自己直接解释AST,有些是编译成java字节码交给jvm。他所指的jit其实就是运行时编译的部分。
ruby的1.8及之前的实现，确实很业余。这点matz也承认。同样做个loop的话，ruby比其他语言慢几十上百倍。1.9改进了解释器的实现。在benchmark上轻松的上了个大台阶。
但是诸如rails这样的应用，loop快上几十倍就没大关系了，也就是几毫秒和几十毫秒的区别。同时，你的页面里也许有几个sql query,瓶颈大多在其他方面上了。我猜这是rails在1.9上目前没有大的提高的原因吧。
我也试过在jruby上跑过rails程序，和robbin说的一样，挺慢的，而且巨占资源。
16 楼
night_stalker
2009-03-07
有快有慢，视情况而定。
ruby酱网站给过一系列的benchmark，总体来说是快了的。
当然benchmark不可信，但是一两个脚本的特例就更不可信了。
ruby酱网站给过一系列的benchmark，总体来说是快了的。
当然benchmark不可信，但是一两个脚本的特例就更不可信了。
15 楼
七猫
2009-03-07
>g:\ruby187\bin\ruby dzhreader.rb
>Exit code: 0 Time: 19.469
这是我编译的1.87(vc2008)
1.9运行结果：45秒(vc2008)
>ruby dzhreader.rb
>Exit code: 0 Time: 26.467
官方自带
vc2008加上一些优化选项的确能使性能有所提高，但1.9的速度感到很困惑。
>Exit code: 0 Time: 19.469
这是我编译的1.87(vc2008)
1.9运行结果：45秒(vc2008)
>ruby dzhreader.rb
>Exit code: 0 Time: 26.467
官方自带
vc2008加上一些优化选项的确能使性能有所提高，但1.9的速度感到很困惑。
14 楼
七猫
2009-03-07
我用2008优化编译的1.9在跑某个脚本需要的时间是1.87的两倍，没仔细去找原因了。
13 楼
RednaxelaFX
2009-03-07
seraphim871211 写道
丫的，现在是分布式系统，嗯，设计模式的倒没有什么，细节太多了，我准备去图书馆看看。
你好好的一个精华帖被我变成水帖了，不好意思啊，哈哈～。
你好好的一个精华帖被我变成水帖了，不好意思啊，哈哈～。
嗯我知道你那个是分布式的作业，之前在校内看到了。这方面在我的盲区内，没办法了（摊手
精华不精华不重要啦。倒是能召唤到些VM有爱人士就好了 T T
12 楼
seraphim871211
2009-03-06
RednaxelaFX 写道
ray_linn 写道
RPC? 远程方法调用？ Remote Procedure Call?
嗯肯定是说这个没错。
night_stalker 写道
RednaxelaFX 写道
...还有Ruby 1.9的兼容性问题。天啊，在Ruby 1.9.1上用不了Mechanize/Nokogiri真是太要命了。
...
...
segfault可以是任何地方的Access violation，经常出问题的地方和显示出来的那块东西完全不搭界……
关键的一点是在1.9里面，RSRING(str)->ptr没有了（用StringValueCStr才对），在1.8下面编译的扩展必定会出问题。
不过Nokogiri的文档说它支持Ruby 1.9的嘛，所以我才试的。结果segfault让我一头雾水 T T
seraphim871211 写道
呃……你在校内上不是说得火热嘛，这都不知道。
于是我知道了……呜哇，突然觉得有点不好意思了（奔
RPC的书在图书室里肯定有，去挖一下吧～说来我们是什么课提到RPC的来着，除了设计模式讲到代理的时候？莫非是大软……OTL
丫的，现在是分布式系统，嗯，设计模式的倒没有什么，细节太多了，我准备去图书馆看看。
你好好的一个精华帖被我变成水帖了，不好意思啊，哈哈～。
11 楼
RednaxelaFX
2009-03-06
ray_linn 写道
RPC? 远程方法调用？ Remote Procedure Call?
嗯肯定是说这个没错。
night_stalker 写道
RednaxelaFX 写道
...还有Ruby 1.9的兼容性问题。天啊，在Ruby 1.9.1上用不了Mechanize/Nokogiri真是太要命了。
...
...
segfault可以是任何地方的Access violation，经常出问题的地方和显示出来的那块东西完全不搭界……
关键的一点是在1.9里面，RSRING(str)->ptr没有了（用StringValueCStr才对），在1.8下面编译的扩展必定会出问题。
不过Nokogiri的文档说它支持Ruby 1.9的嘛，所以我才试的。结果segfault让我一头雾水 T T
seraphim871211 写道
呃……你在校内上不是说得火热嘛，这都不知道。
于是我知道了……呜哇，突然觉得有点不好意思了（奔
RPC的书在图书室里肯定有，去挖一下吧～说来我们是什么课提到RPC的来着，除了设计模式讲到代理的时候？莫非是大软……OTL
10 楼
seraphim871211
2009-03-06
seraphim871211 写道
RednaxelaFX 写道
seraphim871211 写道
没呢，我只是随便说说，你还知道我是谁啊。
ID很眼熟但是我想不起来了，郁闷啊
最近我没怎么上MSN，印象中……如果我知道你是谁的话那我们肯定在MSN上聊过 OTL
呃……你在校内上不是说得火热嘛，这都不知道。
引用
seraphim871211 写道
最近我要看RPC/RMI原理方面的东西，要自己实现个简单的“玩具”RPC，有好书推荐吗？最好语言是用java，C#的也行。
RPC原理我就没怎么看过。抱歉推荐不了什么书了。以前课上提到CORBA的时候稍微读过些零散的资料，都是放狗去找的……
唉，作业头疼啊
9 楼
seraphim871211
2009-03-06
RednaxelaFX 写道
seraphim871211 写道
没呢，我只是随便说说，你还知道我是谁啊。
ID很眼熟但是我想不起来了，郁闷啊
最近我没怎么上MSN，印象中……如果我知道你是谁的话那我们肯定在MSN上聊过 OTL
ID很眼熟但是我想不起来了，郁闷啊
最近我没怎么上MSN，印象中……如果我知道你是谁的话那我们肯定在MSN上聊过 OTL
呃……你在校内上不是说得火热嘛，这都不知道。
seraphim871211 写道
最近我要看RPC/RMI原理方面的东西，要自己实现个简单的“玩具”RPC，有好书推荐吗？最好语言是用java，C#的也行。
RPC原理我就没怎么看过。抱歉推荐不了什么书了。以前课上提到CORBA的时候稍微读过些零散的资料，都是放狗去找的……
唉，作业头疼啊
8 楼
night_stalker
2009-03-06
RednaxelaFX 写道
...还有Ruby 1.9的兼容性问题。天啊，在Ruby 1.9.1上用不了Mechanize/Nokogiri真是太要命了。
...
...
segfault可以是任何地方的Access violation，经常出问题的地方和显示出来的那块东西完全不搭界……
关键的一点是在1.9里面，RSRING(str)->ptr没有了（用StringValueCStr才对），在1.8下面编译的扩展必定会出问题。
7 楼
ray_linn
2009-03-06
RPC? 远程方法调用？ Remote Procedure Call?
6 楼
RednaxelaFX
2009-03-06
seraphim871211 写道
没呢，我只是随便说说，你还知道我是谁啊。
ID很眼熟但是我想不起来了，郁闷啊
最近我没怎么上MSN，印象中……如果我知道你是谁的话那我们肯定在MSN上聊过 OTL
seraphim871211 写道
最近我要看RPC/RMI原理方面的东西，要自己实现个简单的“玩具”RPC，有好书推荐吗？最好语言是用java，C#的也行。
RPC原理我就没怎么看过。抱歉推荐不了什么书了。以前课上提到CORBA的时候稍微读过些零散的资料，都是放狗去找的……
发表评论
-
The Prehistory of Java, HotSpot and Train
2014-06-02 08:18 0http://cs.gmu.edu/cne/itcore/vi ... -
MSJVM and Sun 1.0.x/1.1.x
2014-05-20 18:50 0当年的survey paper: http://www.sym ... -
Sun JDK1.4.2_28有TieredCompilation
2014-05-12 08:48 0原来以前Sun的JDK 1.4.2 update 28就已经有 ... -
IBM JVM notes (2014 ver)
2014-05-11 07:16 0Sovereign JIT http://publib.bou ... -
class data sharing by Apple
2014-03-28 05:17 0class data sharing is implement ... -
HotSpot Server VM与Server Class Machine
2014-02-18 13:21 0HotSpot VM历来有Client VM与Server V ... -
Java 8的lambda表达式在OpenJDK8中的实现
2014-02-04 12:08 0三月份JDK8就要发布首发了，现在JDK8 release c ... -
GC stack map与deopt stack map的异同
2014-01-08 09:56 0两者之间不并存在包含关系。它们有交集，但也各自有特别的地方。 ... -
HotSpot Server Compiler与data-flow analysis
2014-01-07 17:41 0http://en.wikipedia.org/wiki/Da ... -
基于LLVM实现VM的JIT的一些痛点
2014-01-07 17:25 0同事Philip Reames Sanjoy Das http ... -
tailcall notes
2013-12-27 07:42 0http://blogs.msdn.com/b/clrcode ... -
《自制编程语言》的一些笔记
2013-11-24 00:20 0http://kmaebashi.com/programmer ... -
字符串的一般封装方式的内存布局 (1): 元数据与字符串内容，整体还是分离？
2013-11-07 17:44 22390（Disclaimer：未经许可请 ... -
字符串的一般封装方式的内存布局 (0): 拿在手上的是什么
2013-11-04 18:22 21489（Disclaimer：未经许可请 ... -
字符串的一般封装方式的内存布局
2013-11-01 12:55 0（Disclaimer：未经许可请 ... -
关于string，内存布局，C++ std::string，CoW
2013-10-30 20:45 0（Disclaimer：未经许可请 ... -
Java的instanceof是如何实现的
2013-09-22 16:57 0Java语言规范，Java SE 7版 http://docs ... -
也谈类型: 数据, 类型, 标签
2013-08-18 01:59 0numeric tower http://en.wikiped ... -
oop、klass、handle的关系
2013-07-30 17:34 0oopDesc及其子类的实例 oop : oopDesc* ... -
Nashorn各种笔记
2013-07-15 17:03 0http://bits.netbeans.org/netbea ...
相关推荐
由于JRuby是基于JVM（Java Virtual Machine）的，因此可以利用Java生态中的各种工具来对其进行监控和优化。本文将详细讲解如何监控JRuby脚本的执行，以及如何使用jprofiler这一强大的性能分析工具。 首先，理解...
JRuby的核心目标是提供与原生Ruby解释器相当的性能，同时利用JVM的跨平台兼容性和企业级特性，如垃圾回收、线程支持和丰富的库。通过在JVM上运行，JRuby可以无缝地与Java代码交互，使得开发人员能够利用Ruby的生产力...
3. **性能提升**：由于JRuby运行在JVM上，它可以利用JVM的优化技术，如Just-In-Time（JIT）编译，从而提高运行效率。 4. **Rails支持**：对于Web开发，JRuby支持Ruby on Rails框架，可以在Windows环境下搭建高效...
总之，理解Java和JIT编译器版本之间的关系以及如何根据操作系统和硬件配置来选择合适的JIT编译器是优化Java应用程序性能的关键步骤。正确设置这些参数可以显著提升Java程序的运行效率，降低资源消耗。
5. **性能调优**：了解JRuby的性能特性，如JIT编译，如何监控和优化JRuby应用。 6. **部署与持续集成**：学习如何在生产环境中部署JRuby应用，以及如何将其整合到持续集成/持续部署（CI/CD）流程中。 通过阅读...
实验结果表明，对于具有深层嵌套方法调用和扁平执行路径的大型应用，Trace JIT能够提供显著的性能提升。 #### 未来工作与总结 尽管Trace-Based JIT展现出了巨大的潜力，但它也面临着一系列挑战，如如何更准确地...
ZetaVM是一款专为动态编程语言设计的高效虚拟机，同时集成了Just-In-Time（JIT）编译器，以提供更快的执行速度和优化的性能。在本文中，我们将深入探讨ZetaVM的核心特性、工作原理以及它在C/C++开发中的应用。 ### ...
**JIT Spray技术详解** JIT（Just-In-Time）喷射，也称为JIT...通过分析`simple_sploit`和`advanced_shellcode`的源代码，我们可以进一步了解JIT Spray的具体实现和可能的变种，这对于安全研究和防御有着重要的意义。
总的来说，JIT管理实战课程旨在通过深入理解JIT的理论基础和实践应用，帮助企业提升生产效率，减少浪费，提高产品质量，以适应不断变化的市场环境。学习JIT不仅可以优化制造过程，还能促进企业的竞争力和盈利能力。
JavaScript引擎如V8（Chrome和Node.js使用）、SpiderMonkey（Firefox使用）以及JSC（Safari使用）都实现了JIT技术。这些引擎在执行JavaScript时，会根据不同的策略选择何时进行编译。例如，V8采用了分层的JIT编译...
在IT行业中，"JIT实现拓扑展现"这个主题涉及到的是动态编译技术和网络拓扑图的可视化。这里，我们主要探讨JIT（Just-In-Time）编译器以及如何利用它来优化程序性能，同时也会关注如何通过编程手段将网络拓扑结构以...
由于原始材料中未提供具体链接，建议读者搜索相关安全研究机构（如Digital Security Research Group）的出版物和报告，以获取更多关于JIT-Spray攻击技术和实践的信息。此外，各大安全会议（如Black Hat）的演讲和...
这些文件中的函数如`dvmCompilerStartup()`、`dvmCompilerShutdown()`和`compilerThreadStart()`等，共同构成了JIT技术的基础框架。 #### 编译流程与代码缓存 JIT技术的编译过程分为多个阶段，包括方法编译（`...
本文档探讨了两种新型技术来绕过这些缓解措施：指针推断（Pointer Inference）和即时编译喷射（JIT Spraying）。这两种技术充分利用了浏览器内广泛使用的高级脚本解释器或虚拟机的攻击面。 #### 关键技术介绍 ####...
JIT实务涉及到企业管理的多个方面，旨在通过最小化库存、优化流程和提高质量来降低成本并提升竞争力。 在JIT实务中，首先要理解八大浪费，这是精益生产的基础。八大浪费包括： 1. 不良、修理的浪费：由于质量问题...
5. **调试辅助**：Python脚本可以方便地生成和查看编译后的机器码，这对于理解和调试JIT编译器非常有用。 在压缩包"minijit-master"中，你可能会找到以下内容： - 源代码文件：C语言和Python的实现。 - 示例代码：...
jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识...
然而，传统MRP（Material Requirements Planning）和JIT（Just-In-Time）在材料需求规划上存在一些问题。在重复性生产的情况下，传统MRP进行销售预测时未考虑到企业产能的限制，以及预测数量的不确定性。这将导致...
JIT（Just In Time）采购，也称准时化采购，是一种源自日本丰田公司的管理理念，旨在通过精确控制供应流程，确保在正确的时间、正确的地点、提供正确数量和质量的物料，以满足生产需求，同时最大限度地减少库存和...