Thanks Clément for the long description. I will improve the comments of that method.
Cheers, Alexandre > On May 24, 2016, at 1:35 PM, Clément Bera <bera.clem...@gmail.com> wrote: > > Hi, > > Sorry the mail is quite long... I CC'd Nevena for section II, she used the VM > caches for type inference. > > Section I. VM parameters > > 46 size of machine code zone, in bytes > > Well, the size of the machine code zone :-). To speed-up execution, the cog > uses internally a JIT compiler which translates to machine code frequently > used bytecoded method and run the machine code to execute them instead of > using the interpreter. The machine code zone is an executable memory zone > containing all the machine code versions of methods. > > The default size should be between 1Mb and 2Mb for standard applications. If > memory is a constraint, it can be lowered down to 750kb, under that you > should use the stack VM else the performance starts to drastically decrease. > > This setting is useful to tune your application performance. For example, on > compilation-intensive benchs, 750kb is the optimal machine code zone size. On > large benchmarks, 2 Mb, maybe more, is better, but then one may see machine > code garbage collection pauses. On small benchs all the methods fit into this > zone so it doesn't really matter. > > Growing the machine code zone: > - increase the number of methods that can be present there, hence decreasing > machine code zone garbage collection frequency and method jit compilation. > - decrease the machine code zone to cpu instruction cache mapping > - slow down machine code zone garbage collection > > To set the machine code zone you need to use another parameter (47 I think) > and restart the VM+image. > > 59 number of check event calls since startup (read-only) > > If I remember correctly, the number of times the VM has checked for OS events > since start-up. > > 60 number of stack page overflows since startup (read-only; Cog VMs > only) > 61 number of stack page divorces since startup (read-only; Cog VMs only) > > This is related to stack page management. Read the Cog blog to understand how > it's done. See > http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/ > section Stack pages. > > Section II. Accessing the caches > > Is there a way to get access to the cache? How many caches does Cog has? I > guess it has > - a method call cache (associating (object,symbol) -> compiled method > - a cache for the JIT-compiled methods right? > > Are there other cache? How can I access them? In particular to query about > their fill. > > There is indeed a global look-up cache, mapping (receiver type, symbol) -> > (compiled method, primitive function pointer). In the jitted methods there > are per send-sites look-up caches, also known as inline caches. > > The most useful is the inline cache values, they provide the receiver types > met for each send site and are fairly reliable. There are ways to access > those caches. I personally use those caches values for the runtime optimizing > compiler, but more recently I worked with Nevena Milojkovic (I CC'd her) and > she was able to use those cache values for type inference, while she is not a > VM expert. We wrote an IWST paper about that, hopefully it'll get accepted > and you will be able to read it. In the IWST paper I sum-up Eliot's > implementation of inline caches and how the VM provides the types. > > In short, to access the caches: > 1) add those primitives: > VirtualMachine>>allMachineCodeMethods > <primitive: 'primitiveAllMethodsCompiledToMachineCode' module:''> > ^#() > CompiledMethod>>sendAndBranchData > <primitive: 'primitiveSistaMethodPICAndCounterData' module:''> > ^#() > 2) add glue code to map caches values from bytecode pc to the AST, something > like that: > CompiledMethod>>astWithCacheAnnotations > | tmp1 | > tmp1 := self sendAndBranchData. > tmp1 > ifEmpty: [ 'No data' logCr. > ^ self ast ]; > do: [ :arg1 | > (self sourceNodeForPC: arg1 first) > propertyAt: #cacheInformation > put: arg1 allButFirst ]. > ^ self ast > 3) Compile the VM with the SistaCogit and SistaVM=true (Slang compilation > settings). > > I guess you could read our IWST paper, that would help. I don't know if > that's possible before the reviewers answer. > > Don't build production tools using those values though, the VM is evolving > and the cache values may vary in the future with the sista optimizer. > > Regards, > > Clement > > On Tue, May 24, 2016 at 5:39 PM, Alexandre Bergel <alexandre.ber...@me.com> > wrote: > Hi, > > The Cog virtual machine expose some very useful parameters. However, some of > them are a bit obscure to me. For example, what are the following parameters? > What do they mean? > > 46 size of machine code zone, in bytes > 59 number of check event calls since startup (read-only) > 60 number of stack page overflows since startup > (read-only; Cog VMs only) > 61 number of stack page divorces since startup > (read-only; Cog VMs only) > > Is there a way to get access to the cache? How many caches does Cog has? I > guess it has > - a method call cache (associating (object,symbol) -> compiled method > - a cache for the JIT-compiled methods right? > > Are there other cache? How can I access them? In particular to query about > their fill. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
