Well the aspects described here either are documented or are being documented through IWST papers waiting for approval.
The cache accessing technique is detailed in the IWST'16 paper *Inferring Types by Mining Class Usage Frequency from Inline Caches**. *Hopefully it'll get accepted and everyone can read it. Nevena worked a lot on it and I believe it's very good. The VM parameters are detailed in Pharo in the method comment of VirtualMachine>>parameterAt: . The comment is self-explanatory so if one does not understand it one needs to read already available documentation about the VM internal behavior. The machine code zone details I added are discussed in my IWST'16 paper *A low Overhead Per Object Write Barrier for Smalltalk. *Hopefully it'll get accepted and everyone can read it. On Wed, May 25, 2016 at 8:46 AM, stepharo <steph...@free.fr> wrote: > clement > > > you should add that to a simple blog post :) > > > Stef > > Le 24/5/16 à 19:35, Clément Bera a écrit : > > 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/> > 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>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 >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > >
