- Pharo-vm - lists.pharo.org

Re: Making pharoX the default branch

by Luc Fabresse

+1 --+- (default) dev - Pharo X (nowadays) ---> | |--- feature || PR ---> # will be merged in default |--- releases ---> BTW: I wanted to do a pass on the wiki pages of the VM repo but I think I need rights for that. do you confirm? Cheers, Luc Le mer. 5 oct. 2022 Ã 10:58, tesonep(a)gmail.com <tesonep(a)gmail.com> a Ã©crit : > I think is a good idea, go ahead > > On Wed, Oct 5, 2022, 10:20 Guille Polito <guillermo.polito(a)inria.fr> > wrote: > >> Hi all, >> >> We were thinking here with Jean Privat that we could make the pharoX >> branch (the dev branch) the default branch in the repository. >> Itâs just a convenience for dev. >> Thoughts? >> >> What should we add in the readme to make sure people do not make mistakes? >> - say that stable versions are in releases? >> - say the default branch is always dev? >> >> cheers, >> G & J >> _______________________________________________ >> Pharo-vm mailing list -- pharo-vm(a)lists.pharo.org >> To unsubscribe send an email to pharo-vm-leave(a)lists.pharo.org >> > _______________________________________________ > Pharo-vm mailing list -- pharo-vm(a)lists.pharo.org > To unsubscribe send an email to pharo-vm-leave(a)lists.pharo.org >

Oct. 5, 2022

Re: Making pharoX the default branch

by tesonep＠gmail.com

I think is a good idea, go ahead On Wed, Oct 5, 2022, 10:20 Guille Polito <guillermo.polito(a)inria.fr> wrote: > Hi all, > > We were thinking here with Jean Privat that we could make the pharoX > branch (the dev branch) the default branch in the repository. > Itâs just a convenience for dev. > Thoughts? > > What should we add in the readme to make sure people do not make mistakes? > - say that stable versions are in releases? > - say the default branch is always dev? > > cheers, > G & J > _______________________________________________ > Pharo-vm mailing list -- pharo-vm(a)lists.pharo.org > To unsubscribe send an email to pharo-vm-leave(a)lists.pharo.org >

Oct. 5, 2022

Cleaning stale branches

by Guille Polito

We have a couple of stale branches, named a bit chaotically, Iâd like to rename them in a good way, but I donât remember what they are about :) The numbers below (behind | ahead) are according to the current stable pharo9 branch. - headless has already the new tree organisation with cmake - dev-7 and pharo branches have the old tree organisation, dev-7 has some bugfixes when comparing to `pharo` - Cog has the original imported version from monticello Maybe we can have some naming convention for branches? - pharo-[version] to denote major development version branches - feat/[feature] for feature branches if needed Then the four above should be renamed accordingly. Something on the lines of... - Cog -> rename as pharo-0? - pharo -> can be removed - dev-7 -> pharo-1 - headless -> pharo-2 ? G

Oct. 5, 2022

Re: Making pharoX the default branch

by Norbert Hartl

I think it is good to have the main trunk being dev. The project is about developing pharo so that says it all. Furthermore tools tend to branch of the default branch mostly. So that would avoid a lot errornous PRs I guess. Stable should always branch off and receive hotfixes. My 2 cents, Norbert > Am 05.10.2022 um 10:20 schrieb Guille Polito <guillermo.polito(a)inria.fr>: > > ï»¿Hi all, > > We were thinking here with Jean Privat that we could make the pharoX branch (the dev branch) the default branch in the repository. > Itâs just a convenience for dev. > Thoughts? > > What should we add in the readme to make sure people do not make mistakes? > - say that stable versions are in releases? > - say the default branch is always dev? > > cheers, > G & J > _______________________________________________ > Pharo-vm mailing list -- pharo-vm(a)lists.pharo.org > To unsubscribe send an email to pharo-vm-leave(a)lists.pharo.org

Oct. 5, 2022

Making pharoX the default branch

by Guille Polito

Hi all, We were thinking here with Jean Privat that we could make the pharoX branch (the dev branch) the default branch in the repository. Itâs just a convenience for dev. Thoughts? What should we add in the readme to make sure people do not make mistakes? - say that stable versions are in releases? - say the default branch is always dev? cheers, G & J

Oct. 5, 2022

Re: JIT Code Zone

by Guille Polito

Hi, > El 26 sept 2022, a las 20:09, stephane ducasse <stephane.ducasse(a)inria.fr> escribiÃ³: > > > Hello, > I am wondering how the Pharo VM and Cogit manage the JIT code zone and have several questions related to that! I will ask my questions and what could be the answers, feel free to correct me! > > Context: I would like to secure this part of the VM, instrument accesses to it and experiment with changes in its layout/location! > > Initialization: > > When and how is the code zone memory allocated? And initialized? > The allocation is made through the succession of: allocateMemoryForImage:withHeader: then allocateMemory:desiredPosition:. The initialization is made through initializeCodeZoneFrom:upTo: where trampolines, PIC prototypes and offsets are generated/computed. Yes, take a look at the following line in #allocateMemoryForImage:withHeader: cogCodeBase := self allocateJITMemory: cogCodeSize desiredPosition: header oldBaseAddr - cogCodeSize. That method is defined only for the simulation as follows (see there is a <doNotGenerate> pragma) allocateJITMemory: desiredSize _: desiredPosition <doNotGenerate> ^ memoryManager allocate: desiredSize desiredPosition: desiredPosition And then there are native implementations of allocateJITMemory() in the C code of the repository. E.g., void* allocateJITMemory(usqInt desiredSize, usqInt desiredPosition){ char *address, *alloc; usqIntptr_t alignment; sqInt allocBytes; SYSTEM_INFO sysInfo; /* determine page boundaries & available address space */ GetSystemInfo(&sysInfo); pageSize = sysInfo.dwPageSize; pageMask = ~(pageSize - 1); minAppAddr = sysInfo.lpMinimumApplicationAddress; maxAppAddr = sysInfo.lpMaximumApplicationAddress; alignment = max(pageSize,1024*1024); address = (char *)(((usqInt)desiredPosition + alignment - 1) & ~(alignment - 1)); alloc = sqAllocateMemorySegmentOfSizeAboveAllocatedSizeInto(roundUpToPage(desiredSize), address, &allocBytes); if (!alloc) { logErrorFromErrno("Could not allocate JIT memory"); exit(1); } return alloc; } > What is the layout of the different components of the code zone? > Trampolines and methods/inline caches coexist, trampolines being the first thing generated. The JIT code cache has two main spaces, delimited by the methodZoneBase. The lower part of the JIT code cache (before the methodZoneBase) is the âTrampolineâ region, but it not only contains trampolines. It contains also other reusable machine code routines for the runtime (for example, there is the routine that reifies the stack frames). This part of the JIT code cache is fixed on VM initialization. Routines inside this part are not collected and are not moved/relocated. The upper part of the JIT code cache contains methods, polymorphic inline caches and megamorphic inline caches. This part is collected/compacted from time to time, here methods can move! > > Runtime: > JIT compilation - What is the granularity of a JIT compilation? When does it write to machine code? > The compiler processes bytecodes at the granularity of a method, using outputInstructionsForGeneratedRuntimeAt: or outputInstructionsAt:. It instruments the actual write with enableCodeZoneWriteDuring:flushingCacheWith:. The core of the compilation is in the last three lines of compileCogMethod: (result := self compileEntireMethod) < 0 ifTrue: [^coInterpreter cCoerceSimple: result to: #'CogMethod *']. ^self generateCogMethod: selector The first line generated the IR using a temporary memory buffer. The last line generates the machine code from the IR. If the question is how âatomicâ is the writing to the JIT code cache, my answer would be âit could be more atomicâ :). Inside the machine code generation, the machine code for all instructions is written by outputInstructionsAt: as you say. But the JIT does not only write instructions but also some metadata method header and a footer with machine code annotations. > This step only needs write accesses to the method zone region (after the trampolines). Yes, the move to ARMv8 and the new W^X restrictions forced us to explicitly identify in the code when the code cache is being modified. That probably could help you. If you want to know when the code cache is being written, just follow the senders of enableCodeZoneWriteDuring:flushingCacheWith: > Garbage collection - When is the GC interfering with machine code? For rewriting and compaction? > Marking with mapMachineCode: and compaction compactCogCompiledCode are the two ways the GC temper with machine code. While the first one only needs to read data, the second needs both read and write accesses. Hmm, there are two aspects here. The JIT code cache will get compacted when it reaches a threshold, by calling compactCogCompiledCode The compaction will remove methods from the cache, and relink linked sends, so it requires some code patching. On a second note, the heap GC will traverse the code cache to find roots. The GC does only need read permissions to extract meta-data, disassemble some machine code and extract object references from the code cache. So it does not need write nor execute permissoins. > > Interaction between interpreter and machine code - How is forward execution (interpreter - machine code) control flow performed? How is backward execution (machine code - interpreter) performed? > I guess the trampolines ceEnterCogCodePopReceiverReg and ceReturnToInterpreter: are the main bridges between both worlds. Yes, there is ceEnterCogCodePopReceiverReg and ceCallCogCodePopReceiverReg. The calling convention is that the interpreter puts the things required for the activation on the stack and call the enilopmarts. The enilopmarts will then extract the info from the stack, put them into registers and call the machine code method. The return is a bit more tricky. What happens is that when an interpreter method calls a JIT method, we do not push to the stack the bytecode program counter (which will be useless for the machine code). Instead, we push the address to a trampoline that knows how to return. The machine returns normally using a ret instruction and jumps to the trampoline, which will massage the stack and let the interpreter continue. > Bonus: What is the difference between Cogit and the CoInterpreter? > Cogit is the compiler. CoInterpreter is a subclass of the interpreter that has the glue code between the interpreter and the compiler. :) G > > Thanks in advance for the answers! > <https://www.ensta-bretagne.fr/> <https://www.labsticc.fr/en/index/> > Quentin Ducasse > Doctorant / PhD Student > Lab-STICC â UMR CNRS 6285 > www.labsticc.fr <http://www.labsticc.fr/> > > ENSTA Bretagne > Grande Ã©cole d'ingÃ©nieurs et centre de recherche > French State Graduate, Post-Graduate and Research Institute > 2 rue FranÃ§ois Verny - 29806 Brest Cedex 9 - France > www.ensta-bretagne.fr <https://www.ensta-bretagne.fr/> > > _______________________________________________ > Pharo-vm mailing list -- pharo-vm(a)lists.pharo.org > To unsubscribe send an email to pharo-vm-leave(a)lists.pharo.org

Sept. 28, 2022

JIT Code Zone

by stephane ducasse

Hello, I am wondering how the Pharo VM and Cogit manage the JIT code zone and have several questions related to that! I will ask my questions and what could be the answers, feel free to correct me! Context: I would like to secure this part of the VM, instrument accesses to it and experiment with changes in its layout/location! Initialization: When and how is the code zone memory allocated? And initialized? The allocation is made through the succession of: allocateMemoryForImage:withHeader: then allocateMemory:desiredPosition:. The initialization is made through initializeCodeZoneFrom:upTo: where trampolines, PIC prototypes and offsets are generated/computed. What is the layout of the different components of the code zone? Trampolines and methods/inline caches coexist, trampolines being the first thing generated. Runtime: JIT compilation - What is the granularity of a JIT compilation? When does it write to machine code? The compiler processes bytecodes at the granularity of a method, using outputInstructionsForGeneratedRuntimeAt: or outputInstructionsAt:. It instruments the actual write with enableCodeZoneWriteDuring:flushingCacheWith:. This step only needs write accesses to the method zone region (after the trampolines). Garbage collection - When is the GC interfering with machine code? For rewriting and compaction? Marking with mapMachineCode: and compaction compactCogCompiledCode are the two ways the GC temper with machine code. While the first one only needs to read data, the second needs both read and write accesses. Interaction between interpreter and machine code - How is forward execution (interpreter - machine code) control flow performed? How is backward execution (machine code - interpreter) performed? I guess the trampolines ceEnterCogCodePopReceiverReg and ceReturnToInterpreter: are the main bridges between both worlds. Bonus: What is the difference between Cogit and the CoInterpreter? Thanks in advance for the answers! <https://www.ensta-bretagne.fr/> <https://www.labsticc.fr/en/index/> Quentin Ducasse Doctorant / PhD Student Lab-STICC â UMR CNRS 6285 www.labsticc.fr ENSTA Bretagne Grande Ã©cole d'ingÃ©nieurs et centre de recherche French State Graduate, Post-Graduate and Research Institute 2 rue FranÃ§ois Verny - 29806 Brest Cedex 9 - France www.ensta-bretagne.fr <https://www.ensta-bretagne.fr/>

Sept. 26, 2022

Re: About primitiveMethodXray

by Nahuel

Wwoooooo this is very nice!!! Congrats ð > On 25 Sep 2022, at 08:31, stephane ducasse <stephane.ducasse(a)inria.fr> wrote: > > Thanks guille for the recap. > It was a cool session and we learned a lot from you. > > S > >> On 24 Sep 2022, at 22:19, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >> >> Just as a follow-up, last week we did together with Jean Privat and Stef a pass on this primitive, and the primitive that exposes method pic information. >> The work we did can be found in the following PR >> >> https://github.com/pharo-project/pharo-vm/pull/463 <https://github.com/pharo-project/pharo-vm/pull/463> >> >> The PR includes a couple of fixes, tests, and cleanups. >> The mashed log is >> >> Fixes on primitiveMethodXray <https://github.com/pharo-project/pharo-vm/pull/463/commits/67780af2e454a348…>: >> >> fixing flags + tests >> use externalWriteBackHeadFramePointers before code compaction to ensure stacks are in sync >> declare it as maycallback to ensure call is made through a trampoline and the return address remains correct after compacting jit code >> Protect method freeing in xray primitive <https://github.com/pharo-project/pharo-vm/commit/8a4b4b4ee93ea6ff71ca5671ae…> >> Expose method profiling data (PICs and linked sends type information): >> >> Expose method profiling data <https://github.com/pharo-project/pharo-vm/commit/dbf4154e553109ff17757f4565…> >> rename picData -> profilingData as it may yield also execution counters >> do not expose counters if not available >> Fix type of methodClassIfSuper, restore array shrinking <https://github.com/pharo-project/pharo-vm/commit/903ba641446c591412b59ff4f2…> >> Rename dollowing the literature <https://github.com/pharo-project/pharo-vm/pull/463/commits/10aba4ad1d6db046…>: >> >> OpenPIC -> MegamorphicIC >> ClosedPIC -> PolymorphicIC >> Cleanups: >> >> Adding notYetImplemented with message parameter <https://github.com/pharo-project/pharo-vm/commit/75be0cddfe3037aa5f574c6a37…> >> Remove old block compilation related methods <https://github.com/pharo-project/pharo-vm/commit/a806e2f7811973cdfca76f47ee…> >> Remove SistaCogitClone <https://github.com/pharo-project/pharo-vm/commit/7ea5b11e031707b83b1b6ca037…> >> Cleaning morphic related method <https://github.com/pharo-project/pharo-vm/commit/1ee56c2528503f6380415085a1…> >> Cheers, >> G >> >>> El 15 sept 2022, a las 21:15, stephane ducasse <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> escribiÃ³: >>> >>> Hi >>> >>> In CoInterpreter we can find >>> >>> initializePrimitiveTable >>> super initializePrimitiveTable. >>> PrimNumberHashMultiply := 159. >>> self assert: (PrimitiveTable at: PrimNumberHashMultiply + 1) = #primitiveHashMultiply. >>> >>> #(216 253) do: >>> [:pidx| self assert: (PrimitiveTable at: pidx + 1) = #primitiveFail]. >>> self assert: (PrimitiveTable at: 215 + 1) = #primitiveFlushCacheByMethod. >>> PrimitiveTable >>> at: 253 + 1 put: #primitiveCollectCogCodeConstituents; >>> at: 215 + 1 put: #primitiveVoidVMStateForMethod; >>> at: 216 + 1 put: #primitiveMethodXray >>> >>> >>> There is a primitive primitiveMethodXray :) >>> >>> primitiveMethodXray >>> "Lift the veil from a method and answer an integer describing the interior state >>> of its machine code. >>> Used for e.g. VM tests so they can verify they're testing what they think they're testing. >>> 0 implies a vanilla method. >>> Bit 0 = method might be compiled to machine code >>> Bit 1 = method is currently compiled to machine code >>> Bit 2 = is compiled frameless. >>> Bit 3 = method refers to young object. >>> Bit 4 = method too big to be jitted (more than 64k of code, or needs more than 1.5Mb of stack space to compile) >>> Bit 5 = method contains unknown/unjittable bytecode >>> Bit 6 = method should not be jitted because it contains a primitive not to be called from machine code (unused)" >>> | alreadyCogged flags cogMethod | >>> <var: #cogMethod type: #'CogMethod *'> >>> (self methodWithHeaderShouldBeCogged: (objectMemory methodHeaderOf: self stackTop)) >>> ifTrue: >>> [alreadyCogged := self maybeMethodHasCogMethod: self stackTop. >>> flags := 1. >>> alreadyCogged ifFalse: >>> [cogMethod := cogit cog: self stackTop selector: objectMemory nilObject. >>> (cogMethod = nil >>> and: [cogCompiledCodeCompactionCalledFor]) ifTrue: >>> [self commenceCogCompiledCodeCompaction. >>> cogMethod := cogit cog: self stackTop selector: objectMemory nilObject]. >>> cogMethod asInteger >>> caseOf: { >>> [MethodTooBig] -> [flags := 1 + 16]. >>> [EncounteredUnknownBytecode] -> [flags := 1 + 32]. >>> [ShouldNotJIT] -> [flags := 1 + 64] } >>> otherwise: [self deny: (cogMethod asInteger between: MaxNegativeErrorCode and: NotFullyInitialized)]]. >>> (flags = 1 >>> and: [self maybeMethodHasCogMethod: self stackTop]) ifTrue: >>> [cogMethod := self cogMethodOf: self stackTop. >>> flags := cogMethod stackCheckOffset = 0 ifTrue: [7] ifFalse: [3]. >>> cogMethod cmRefersToYoung ifTrue: >>> [flags := flags + 8]. >>> alreadyCogged ifFalse: >>> [cogit freeMethod: cogMethod]]] >>> ifFalse: [flags := 0]. >>> self pop: 1 thenPush: (objectMemory integerObjectOf: flags) >>> >>> >>> and I wanted to execute it. >>> >>> So on compiledMethod I defined a method >>> >>> CompiledMethod >> xray >>> >>> <primitive: 216> >>> >>> >>> and I did (Point>>#degrees) xray >>> but when I execute I get a compiled method and not an integer. >>> >>> So I probably do something silly. >>> But I would like to understand what. >>> >>> Tx >>> >>> >>> _______________________________________________ >>> Pharo-vm mailing list -- pharo-vm(a)lists.pharo.org <mailto:pharo-vm@lists.pharo.org> >>> To unsubscribe send an email to pharo-vm-leave(a)lists.pharo.org <mailto:pharo-vm-leave@lists.pharo.org> >> > > _______________________________________________ > Pharo-vm mailing list -- pharo-vm(a)lists.pharo.org > To unsubscribe send an email to pharo-vm-leave(a)lists.pharo.org

Sept. 25, 2022

Re: About primitiveMethodXray

by stephane ducasse

Thanks guille for the recap. It was a cool session and we learned a lot from you. S > On 24 Sep 2022, at 22:19, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Just as a follow-up, last week we did together with Jean Privat and Stef a pass on this primitive, and the primitive that exposes method pic information. > The work we did can be found in the following PR > > https://github.com/pharo-project/pharo-vm/pull/463 <https://github.com/pharo-project/pharo-vm/pull/463> > > The PR includes a couple of fixes, tests, and cleanups. > The mashed log is > > Fixes on primitiveMethodXray <https://github.com/pharo-project/pharo-vm/pull/463/commits/67780af2e454a348…>: > > fixing flags + tests > use externalWriteBackHeadFramePointers before code compaction to ensure stacks are in sync > declare it as maycallback to ensure call is made through a trampoline and the return address remains correct after compacting jit code > Protect method freeing in xray primitive <https://github.com/pharo-project/pharo-vm/commit/8a4b4b4ee93ea6ff71ca5671ae…> > Expose method profiling data (PICs and linked sends type information): > > Expose method profiling data <https://github.com/pharo-project/pharo-vm/commit/dbf4154e553109ff17757f4565…> > rename picData -> profilingData as it may yield also execution counters > do not expose counters if not available > Fix type of methodClassIfSuper, restore array shrinking <https://github.com/pharo-project/pharo-vm/commit/903ba641446c591412b59ff4f2…> > Rename dollowing the literature <https://github.com/pharo-project/pharo-vm/pull/463/commits/10aba4ad1d6db046…>: > > OpenPIC -> MegamorphicIC > ClosedPIC -> PolymorphicIC > Cleanups: > > Adding notYetImplemented with message parameter <https://github.com/pharo-project/pharo-vm/commit/75be0cddfe3037aa5f574c6a37…> > Remove old block compilation related methods <https://github.com/pharo-project/pharo-vm/commit/a806e2f7811973cdfca76f47ee…> > Remove SistaCogitClone <https://github.com/pharo-project/pharo-vm/commit/7ea5b11e031707b83b1b6ca037…> > Cleaning morphic related method <https://github.com/pharo-project/pharo-vm/commit/1ee56c2528503f6380415085a1…> > Cheers, > G > >> El 15 sept 2022, a las 21:15, stephane ducasse <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> escribiÃ³: >> >> Hi >> >> In CoInterpreter we can find >> >> initializePrimitiveTable >> super initializePrimitiveTable. >> PrimNumberHashMultiply := 159. >> self assert: (PrimitiveTable at: PrimNumberHashMultiply + 1) = #primitiveHashMultiply. >> >> #(216 253) do: >> [:pidx| self assert: (PrimitiveTable at: pidx + 1) = #primitiveFail]. >> self assert: (PrimitiveTable at: 215 + 1) = #primitiveFlushCacheByMethod. >> PrimitiveTable >> at: 253 + 1 put: #primitiveCollectCogCodeConstituents; >> at: 215 + 1 put: #primitiveVoidVMStateForMethod; >> at: 216 + 1 put: #primitiveMethodXray >> >> >> There is a primitive primitiveMethodXray :) >> >> primitiveMethodXray >> "Lift the veil from a method and answer an integer describing the interior state >> of its machine code. >> Used for e.g. VM tests so they can verify they're testing what they think they're testing. >> 0 implies a vanilla method. >> Bit 0 = method might be compiled to machine code >> Bit 1 = method is currently compiled to machine code >> Bit 2 = is compiled frameless. >> Bit 3 = method refers to young object. >> Bit 4 = method too big to be jitted (more than 64k of code, or needs more than 1.5Mb of stack space to compile) >> Bit 5 = method contains unknown/unjittable bytecode >> Bit 6 = method should not be jitted because it contains a primitive not to be called from machine code (unused)" >> | alreadyCogged flags cogMethod | >> <var: #cogMethod type: #'CogMethod *'> >> (self methodWithHeaderShouldBeCogged: (objectMemory methodHeaderOf: self stackTop)) >> ifTrue: >> [alreadyCogged := self maybeMethodHasCogMethod: self stackTop. >> flags := 1. >> alreadyCogged ifFalse: >> [cogMethod := cogit cog: self stackTop selector: objectMemory nilObject. >> (cogMethod = nil >> and: [cogCompiledCodeCompactionCalledFor]) ifTrue: >> [self commenceCogCompiledCodeCompaction. >> cogMethod := cogit cog: self stackTop selector: objectMemory nilObject]. >> cogMethod asInteger >> caseOf: { >> [MethodTooBig] -> [flags := 1 + 16]. >> [EncounteredUnknownBytecode] -> [flags := 1 + 32]. >> [ShouldNotJIT] -> [flags := 1 + 64] } >> otherwise: [self deny: (cogMethod asInteger between: MaxNegativeErrorCode and: NotFullyInitialized)]]. >> (flags = 1 >> and: [self maybeMethodHasCogMethod: self stackTop]) ifTrue: >> [cogMethod := self cogMethodOf: self stackTop. >> flags := cogMethod stackCheckOffset = 0 ifTrue: [7] ifFalse: [3]. >> cogMethod cmRefersToYoung ifTrue: >> [flags := flags + 8]. >> alreadyCogged ifFalse: >> [cogit freeMethod: cogMethod]]] >> ifFalse: [flags := 0]. >> self pop: 1 thenPush: (objectMemory integerObjectOf: flags) >> >> >> and I wanted to execute it. >> >> So on compiledMethod I defined a method >> >> CompiledMethod >> xray >> >> <primitive: 216> >> >> >> and I did (Point>>#degrees) xray >> but when I execute I get a compiled method and not an integer. >> >> So I probably do something silly. >> But I would like to understand what. >> >> Tx >> >> >> _______________________________________________ >> Pharo-vm mailing list -- pharo-vm(a)lists.pharo.org <mailto:pharo-vm@lists.pharo.org> >> To unsubscribe send an email to pharo-vm-leave(a)lists.pharo.org <mailto:pharo-vm-leave@lists.pharo.org> >

Sept. 25, 2022

Re: About primitiveMethodXray

by Guillermo Polito

Just as a follow-up, last week we did together with Jean Privat and Stef a pass on this primitive, and the primitive that exposes method pic information. The work we did can be found in the following PR https://github.com/pharo-project/pharo-vm/pull/463 The PR includes a couple of fixes, tests, and cleanups. The mashed log is Fixes on primitiveMethodXray <https://github.com/pharo-project/pharo-vm/pull/463/commits/67780af2e454a348…>: fixing flags + tests use externalWriteBackHeadFramePointers before code compaction to ensure stacks are in sync declare it as maycallback to ensure call is made through a trampoline and the return address remains correct after compacting jit code Protect method freeing in xray primitive <https://github.com/pharo-project/pharo-vm/commit/8a4b4b4ee93ea6ff71ca5671ae…> Expose method profiling data (PICs and linked sends type information): Expose method profiling data <https://github.com/pharo-project/pharo-vm/commit/dbf4154e553109ff17757f4565…> rename picData -> profilingData as it may yield also execution counters do not expose counters if not available Fix type of methodClassIfSuper, restore array shrinking <https://github.com/pharo-project/pharo-vm/commit/903ba641446c591412b59ff4f2…> Rename dollowing the literature <https://github.com/pharo-project/pharo-vm/pull/463/commits/10aba4ad1d6db046…>: OpenPIC -> MegamorphicIC ClosedPIC -> PolymorphicIC Cleanups: Adding notYetImplemented with message parameter <https://github.com/pharo-project/pharo-vm/commit/75be0cddfe3037aa5f574c6a37…> Remove old block compilation related methods <https://github.com/pharo-project/pharo-vm/commit/a806e2f7811973cdfca76f47ee…> Remove SistaCogitClone <https://github.com/pharo-project/pharo-vm/commit/7ea5b11e031707b83b1b6ca037…> Cleaning morphic related method <https://github.com/pharo-project/pharo-vm/commit/1ee56c2528503f6380415085a1…> Cheers, G > El 15 sept 2022, a las 21:15, stephane ducasse <stephane.ducasse(a)inria.fr> escribiÃ³: > > Hi > > In CoInterpreter we can find > > initializePrimitiveTable > super initializePrimitiveTable. > PrimNumberHashMultiply := 159. > self assert: (PrimitiveTable at: PrimNumberHashMultiply + 1) = #primitiveHashMultiply. > > #(216 253) do: > [:pidx| self assert: (PrimitiveTable at: pidx + 1) = #primitiveFail]. > self assert: (PrimitiveTable at: 215 + 1) = #primitiveFlushCacheByMethod. > PrimitiveTable > at: 253 + 1 put: #primitiveCollectCogCodeConstituents; > at: 215 + 1 put: #primitiveVoidVMStateForMethod; > at: 216 + 1 put: #primitiveMethodXray > > > There is a primitive primitiveMethodXray :) > > primitiveMethodXray > "Lift the veil from a method and answer an integer describing the interior state > of its machine code. > Used for e.g. VM tests so they can verify they're testing what they think they're testing. > 0 implies a vanilla method. > Bit 0 = method might be compiled to machine code > Bit 1 = method is currently compiled to machine code > Bit 2 = is compiled frameless. > Bit 3 = method refers to young object. > Bit 4 = method too big to be jitted (more than 64k of code, or needs more than 1.5Mb of stack space to compile) > Bit 5 = method contains unknown/unjittable bytecode > Bit 6 = method should not be jitted because it contains a primitive not to be called from machine code (unused)" > | alreadyCogged flags cogMethod | > <var: #cogMethod type: #'CogMethod *'> > (self methodWithHeaderShouldBeCogged: (objectMemory methodHeaderOf: self stackTop)) > ifTrue: > [alreadyCogged := self maybeMethodHasCogMethod: self stackTop. > flags := 1. > alreadyCogged ifFalse: > [cogMethod := cogit cog: self stackTop selector: objectMemory nilObject. > (cogMethod = nil > and: [cogCompiledCodeCompactionCalledFor]) ifTrue: > [self commenceCogCompiledCodeCompaction. > cogMethod := cogit cog: self stackTop selector: objectMemory nilObject]. > cogMethod asInteger > caseOf: { > [MethodTooBig] -> [flags := 1 + 16]. > [EncounteredUnknownBytecode] -> [flags := 1 + 32]. > [ShouldNotJIT] -> [flags := 1 + 64] } > otherwise: [self deny: (cogMethod asInteger between: MaxNegativeErrorCode and: NotFullyInitialized)]]. > (flags = 1 > and: [self maybeMethodHasCogMethod: self stackTop]) ifTrue: > [cogMethod := self cogMethodOf: self stackTop. > flags := cogMethod stackCheckOffset = 0 ifTrue: [7] ifFalse: [3]. > cogMethod cmRefersToYoung ifTrue: > [flags := flags + 8]. > alreadyCogged ifFalse: > [cogit freeMethod: cogMethod]]] > ifFalse: [flags := 0]. > self pop: 1 thenPush: (objectMemory integerObjectOf: flags) > > > and I wanted to execute it. > > So on compiledMethod I defined a method > > CompiledMethod >> xray > > <primitive: 216> > > > and I did (Point>>#degrees) xray > but when I execute I get a compiled method and not an integer. > > So I probably do something silly. > But I would like to understand what. > > Tx > > > _______________________________________________ > Pharo-vm mailing list -- pharo-vm(a)lists.pharo.org > To unsubscribe send an email to pharo-vm-leave(a)lists.pharo.org

Sept. 24, 2022