2015-02-23 15:08 GMT+01:00 Thierry Goubier <[email protected]>:
> Hi Clement, > > 2015-02-23 14:46 GMT+01:00 Clément Bera <[email protected]>: > >> >> Any method is jitted if when activated it's already in the global lookup >> cache and it's not already jitted (so mostly on second calls). >> > > Ok. > > >> >> The only limit is on the number of literals. A method with more than a >> certain number of literals (by default, 64) is not jitted. You can change >> this limit by starting the VM with a specific command line argument (I >> don't remember, something like --maxNumLiterals, you will find it when >> pressing --help I don't have access to a VM right now). Basically the limit >> is to 64 because the GC consume a lot of time in the machine code zone. >> Each literals require specific care because their addresses are directly in >> the generated code (Has the literal moved in memory, ...). >> > > 64 literals in a method... This means something like : > > aCompiledMethod numLiterals <= 64 > > Would reasonably tells me which methods will be jitted. > Yes. This is the code in VMMAker: ^(objectMemory literalCountOfMethodHeader: methodHeader) <= maxLiteralCountForCompile > > >> >> There's a few other things, such as a method with unknown bytecodes will >> not be jitted (so you can rely for example on the respondsToUnknownBytecode >> hook with interpreted methods), but I don't think it matters for you. >> > > And unknown bytecodes won't be generated by standard smalltalk code, > right? So it shouldn't matter to me. > No. But I wrote that just so you know if you start doing exotic things there are other constraints than just the number of literals. > > This is very helpful, thanks. > > Thierry >
