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.clement@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-... 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.bergel@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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

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 <stepharo@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-...> http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-... 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.bergel@me.com>alexandre.bergel@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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.