March 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] FFI Struct Argument Pass By Value Fails on Mac 64 bit

by Todd Blanchard

I got pulled off to do some $ work and haven't got back to this but I would like to get back to it. Has there been any progress on this in the publicly available 64bit VM? I see there is a completely separate FFI plugin for 32 vs 64 and worry 64 is still not quite ready for real work. > On Dec 3, 2017, at 7:18 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > > On 27 November 2017 at 00:24, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: > > i'm getting the idea that we should probably write a test suite/library for FFI > > I noticed these... > * https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/p… <https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/p…> > * https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/Cross/… <https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/Cross/…> > * https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/Cross/… <https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/Cross/…> > > These look like c-code test frames for FFI. Could these be built by the OpenSmalltalk CI to be normally shipped with the VM so that Image-side CI can test against them? > > And also some general info... > * https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/p… <https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/p…> > > > >> On Nov 24, 2017, at 12:54 AM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >> >> >> On 24 November 2017 at 13:16, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >> >> >> On 22 November 2017 at 21:59, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >> >> >> On 22 November 2017 at 13:38, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >> >> I've been trying to track this down for a couple weeks now. > >> >> I have concluded that structs passed by value to functions on the 64 bit VM are not properly populated. The struct's memory is all zero'd. >> >> I found this while trying to work with LibClang and found that functions that fetched code locations from code ranges always returned invalid zero'd locations. After spending some time with lldb I have traced the problem into the native code and found that the argument is not correct. >> >> I've carved out the wee bit of clang to reproduce this in a tiny library. >> >> The gist of it is below and the entire file is included. Basically the struct passed to the function clang_getRangeStart is zero'd memory regardless of the data I send from the image side. > > > My last analysis discovered something interesting about strings defined inside shared libraries being handled differently, but only later realised I had chased the wrong rabbit down the hole. > > I've now investigated the premise you actually poses, and I agree, that structs being zero is some cases. > The attached zipfile containing libstruct.c a few comparison cases - three "good" layouts that work fine and one "bad" that mostly gets zeros but sometimes other weird numbers. There is a Makefile with three main targets: > 1. make layout - statically compiles libstruct.c and runs produced a.out to display structure layouts > > 2. make run - downloads Pharo, starts it loading LibStruct.st <http://libstruct.st/> , then you manually run LibStruct>>>LibStructTest>>#testStructs and observe structure values on console > > 3. make debug - starts LLDB to run Pharo with breakpoints pre-configured for when you run #testStructs. > Note Pharo will freeze and you need to move to LLDB. Try these commands... > frame variable > call print_struct(&GoodStruct1_fmt, &aStruct) > continue > > That works on Ubuntu 16.04 64 bit. > You will need to tune it for OSX. > clang and lldb are required. > > ================================ > The offsets configured in the class variables of all ExternalStructs > correctly matches that reported by the C code test frame results here... > > $ make layout > clang -g libstruct.c > ./a.out > > GoodStruct1: > uint32_t:int1: 01 4 > uint32_t:int2: 05 4 > GoodStruct2: > uint32_t:int1: 01 4 > uint32_t:int2: 05 4 > void*:ptr_data: 09 8 > GoodStruct3: > void*:ptr_data: 01 8 > uint32_t:int1: 09 4 > uint32_t:int2: 13 4 > BadStruct: > void*:ptr_data1: 01 8 > void*:ptr_data2: 09 8 > uint32_t:int1: 17 4 > uint32_t:int2: 21 4 > > ================================ > > $ make run > clang -g -o libstruct.so -shared -fPIC libstruct.c > getpharo/pharo-vm/lib/pharo/5.0-201707201942/pharo getpharo/Pharo.image ../LibStruct.st <http://libstruct.st/> > > Now manually browse to and run LibStruct>>>LibStructTest>>#testStructs > LibStructTest>>testStructs > |good1Struct good2Struct good3Struct badStruct | > > good1Struct := GoodStruct1 new int1: 2; int2: 3. > good2Struct := GoodStruct2 new int1: 2; int2: 3; ptr_force_int: 4. > good3Struct := GoodStruct3 new int1: 2; int2: 3; ptr_force_int: 4. > badStruct := BadStruct new int1: 2; int2: 3; ptr_force_int1: 4; ptr_force_int1: 5. > > self assert: (LibStruct tryGood1: good1Struct) equals: 6. > self assert: (LibStruct tryGood2: good2Struct) equals: 6. > self assert: (LibStruct tryGood3: good3Struct) equals: 6. > "Problem exposed in next line" > self assert: (LibStruct tryBad: badStruct) equals: 6. > > which on console produces... > > GoodStruct1: > uint32_t:int1: 01 4 = 02 00 00 00 > uint32_t:int2: 05 4 = 03 00 00 00 > GoodStruct2: > uint32_t:int1: 01 4 = 02 00 00 00 > uint32_t:int2: 05 4 = 03 00 00 00 > void*:ptr_data: 09 8 = 04 00 00 00 00 00 00 00 > GoodStruct3: > void*:ptr_data: 01 8 = 04 00 00 00 00 00 00 00 > uint32_t:int1: 09 4 = 02 00 00 00 > uint32_t:int2: 13 4 = 03 00 00 00 > BadStruct: > void*:ptr_data1: 01 8 = 00 00 00 00 00 00 00 00 > void*:ptr_data2: 09 8 = 00 00 00 00 00 00 00 00 > uint32_t:int1: 17 4 = 29 03 03 00 > uint32_t:int2: 21 4 = 00 00 00 00 > > Comparing GoodStruct3 and BadStruct, it seems one pointer is handled fine, but not two. > The first time this is run after Image boots seems like BadStruct gets some random data. > > ================================ > In same image, subsequent runs of LibStruct>>>LibStructTest>>testStructs > give only all zeros for BadStruct, as Todd observed. > > GoodStruct1: > uint32_t:int1: 01 4 = 02 00 00 00 > uint32_t:int2: 05 4 = 03 00 00 00 > GoodStruct2: > uint32_t:int1: 01 4 = 02 00 00 00 > uint32_t:int2: 05 4 = 03 00 00 00 > void*:ptr_data: 09 8 = 00 00 00 00 00 00 00 00 > GoodStruct3: > void*:ptr_data: 01 8 = 00 00 00 00 00 00 00 00 > uint32_t:int1: 09 4 = 02 00 00 00 > uint32_t:int2: 13 4 = 03 00 00 00 > BadStruct: > void*:ptr_data1: 01 8 = 00 00 00 00 00 00 00 00 > void*:ptr_data2: 09 8 = 00 00 00 00 00 00 00 00 > uint32_t:int1: 17 4 = 00 00 00 00 > uint32_t:int2: 21 4 = 00 00 00 00 > > > cheers -ben > > <FFI64StructTest.zip>

March 1, 2018

Re: [Pharo-dev] Help not losing my changes :(

by Alistair Grant

If this is the same as a known problem, just close the error and try to commit again. Cheers, Alistair On 1 March 2018 at 16:58, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I took the latest version of Pharo 70 and I coded some cleanings > and when I change the remote to pull from Pharo I got a lot of fetch > and load happening > But I do not know if I should merge incoming. > probably. > > And then I got an error IceVersionDoesNotExist: there is no versoin > for package: SunitUI-Testing in commit 00db9 > > > Now when I commit my work I get KeyNotFound: key 'Metacello-Cypress' > not found in Dictionary > I often get this KeyNotFound error. > > What can I do to avoid losing my work. > > Stef >

March 1, 2018

[Pharo 7.0-dev] Build #636: 21454-remove-newAutoAcceptTextEntryForgetTextsetTextgetEnabledhelpentryCompletion

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #636 was: SUCCESS. The Pull Request #993 was integrated: "21454-remove-newAutoAcceptTextEntryForgetTextsetTextgetEnabledhelpentryCompletion" Pull request url: https://github.com/pharo-project/pharo/pull/993 Issue Url: https://pharo.fogbugz.com/f/cases/21454 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 1, 2018

Help not losing my changes :(

by Stephane Ducasse

I took the latest version of Pharo 70 and I coded some cleanings and when I change the remote to pull from Pharo I got a lot of fetch and load happening But I do not know if I should merge incoming. probably. And then I got an error IceVersionDoesNotExist: there is no versoin for package: SunitUI-Testing in commit 00db9 Now when I commit my work I get KeyNotFound: key 'Metacello-Cypress' not found in Dictionary I often get this KeyNotFound error. What can I do to avoid losing my work. Stef

March 1, 2018

Re: [Pharo-dev] [Request for comment] Hermes package

by tesonep＠gmail.com

Nice Idea, I have added comments to the packages, classes and methods. This will be in the new version that will be integrated with the new Traits implementation. I am still cleaning some comments that Denis and Pavel have done and we can integrate it. Then we change the name, I liked BootstrapCodeLoader, I think I can find a non conflicting prefix. Cheers. On Thu, Mar 1, 2018 at 4:29 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > +1 > > On Thu, Mar 1, 2018 at 2:42 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > While it is very bootstrap oriented library it would be better to rename > it > > to BootstapCodeLoader. > > Or PharoBootstrap-CodeLoader because we already use this prefix > > > > 2018-03-01 13:20 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> > >> Hermes is a private binary format that is used to load compiled code > >> when there is no compiler during the bootstrap. > >> So basically hermes is loading the compiler to be able to compile > >> other packages. > >> > >> Stef > >> > >> On Wed, Feb 28, 2018 at 4:55 PM, Alexandre Bergel > >> <alexandre.bergel(a)me.com> wrote: > >> > Side question: What is Hermes? > >> > > >> > Alexandre > >> > > >> >> On Feb 28, 2018, at 1:42 AM, Torsten Bergmann <astares(a)gmx.de> > wrote: > >> >> > >> >> ... to all participating authors of the Hermes package: > >> >> > >> >> PLEASE COMMENT YOUR CLASSES SO WE CAN CLEAN UP AND PREPARE A > >> >> POLISHED PHARO 7 RELEASE > >> >> > >> >> So many uncommented classes in there today... > >> >> > >> >> We can do better and we should. I dont ask for detailed documentation > >> >> but a single comment why the class is there or what it should care > >> >> about is often already enough. > >> >> > >> >> If you have time to write code then you also have the time to write > >> >> a simple class comment! > >> >> > >> >> So please do you homework (which is a general request to authors > >> >> of other packages as well) > >> >> > >> >> Bye > >> >> T. > >> >> > >> > > >> > > >> > > > > -- Pablo Tesone. tesonep(a)gmail.com

March 1, 2018

Integration deadlock?

by Stephane Ducasse

I have a change that crosscuts calypso and iceberg. I will produce a PR and each project should check because else I will get stuck waiting in an integration deadlock. https://pharo.fogbugz.com/f/cases/21459/Fixing-last-users-of-theNonMetaclass

March 1, 2018

Re: [Pharo-dev] How can I introduce a new package in Pharo 70

by Cyril Ferlicot

On Thu, Mar 1, 2018 at 4:28 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi > > I would like to gather all refactoring-based deprecated methods and I > need to introduce a package in Pharo 70. > How do I do that? > Hi, You need to: - Add the package to the related baseline (Else it will not be loaded during the bootstrap) - In Iceberg add the package to the project. In the package tab, use "Add package" - Synchronize full repository to commit > Stef > -- Cyril Ferlicot https://ferlicot.fr

March 1, 2018

Re: [Pharo-dev] [Request for comment] Hermes package

by Stephane Ducasse

+1 On Thu, Mar 1, 2018 at 2:42 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > While it is very bootstrap oriented library it would be better to rename it > to BootstapCodeLoader. > Or PharoBootstrap-CodeLoader because we already use this prefix > > 2018-03-01 13:20 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> Hermes is a private binary format that is used to load compiled code >> when there is no compiler during the bootstrap. >> So basically hermes is loading the compiler to be able to compile >> other packages. >> >> Stef >> >> On Wed, Feb 28, 2018 at 4:55 PM, Alexandre Bergel >> <alexandre.bergel(a)me.com> wrote: >> > Side question: What is Hermes? >> > >> > Alexandre >> > >> >> On Feb 28, 2018, at 1:42 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> >> >> ... to all participating authors of the Hermes package: >> >> >> >> PLEASE COMMENT YOUR CLASSES SO WE CAN CLEAN UP AND PREPARE A >> >> POLISHED PHARO 7 RELEASE >> >> >> >> So many uncommented classes in there today... >> >> >> >> We can do better and we should. I dont ask for detailed documentation >> >> but a single comment why the class is there or what it should care >> >> about is often already enough. >> >> >> >> If you have time to write code then you also have the time to write >> >> a simple class comment! >> >> >> >> So please do you homework (which is a general request to authors >> >> of other packages as well) >> >> >> >> Bye >> >> T. >> >> >> > >> > >> >

March 1, 2018

How can I introduce a new package in Pharo 70

by Stephane Ducasse

Hi I would like to gather all refactoring-based deprecated methods and I need to introduce a package in Pharo 70. How do I do that? Stef

March 1, 2018

Re: [Pharo-dev] "External module not found" while loading metacello project

by Cyrille Delaunay

Yeah this was imprecise Here is our build process: To get a mac pharo vm, we use this url: https://files.pharo.org/get-files/61/pharo-mac-stable.zip To get a pharo image, we use the one retrieved with: wget --quiet -O - get.pharo.org/61+vm | bash I juste made a test with fresh image and vm retrieved using the above links. But I was not able to reproduce ! So I guess there might be something wrong during our build process (in between getting image + vm AND getting our source code loaded) Or maybe we are not really getting these images and vms. I will investigate more and come back if I have more elements 2018-03-01 11:05 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > whet is this âlatest vmâ ? how do you get it? > which 6 image are you getting? > > Esteban > > > On 1 Mar 2018, at 10:39, Cyrille Delaunay <cy.delaunay(a)gmail.com> wrote: > > Hello, > > I am getting the error "External module not found" while trying to load a > metacello project. > I am running the latest 32 bits pharo 6 image and vm available with > zeroconf script. > The concerned external module seems to be "libgit" (self ffiCall: #(int > git_libgit2_init())) > But the plugin seems to be available within the vm folder: > > <Screen Shot 2018-03-01 at 10.37.39 AM.png> > > The issue can be reproduced with any metacello project. > For example, from the catalog, you can load the configuration of > VoyageMongo. > Then inspect: > > Metacello new > configuration: 'VoyageMongo'; > version: #development; > repository: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo60'; > load. > > I am able to collect to following information using the System reporter: > > Image > ----- > /Users/cdelaunay/Work/synectique-images/demo/synintegration/61/Java-OnWeb- > Demo/Java-OnWeb.image > Pharo6.0 > Latest update: #60535 > Unnamed > > Virtual Machine > --------------- > /Users/cdelaunay/Work/synectique-images/demo/synintegration/61/Java-OnWeb- > Demo/pharo-mac-vm/Pharo.app/Contents/MacOS/Pharo > CoInterpreter VMMaker.oscog-eem.2254 uuid: 4f2c2cce-f4a2-469a-93f1-97ed941df0ad > Jul 20 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: > 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 > VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Date: Thu Jul 20 12:42:21 2017 -0700 $ Plugins: 201707201942 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > > Mac OS X built on Jul 20 2017 21:45:23 UTC Compiler: 4.2.1 Compatible > Apple LLVM 6.1.0 (clang-602.0.53) > VMMaker versionString VM: 201707201942 https://github.com/ > OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul 20 12:42:21 2017 -0700 > $ Plugins: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk- > vm.git $ > CoInterpreter VMMaker.oscog-eem.2254 uuid: 4f2c2cce-f4a2-469a-93f1-97ed941df0ad > Jul 20 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: > 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 > > Virtual Machine Commandline Options > ----------------------------------- > none > > Loaded VM Modules > ----------------- > AioPlugin VMConstruction-Plugins-AioPlugin-eem.18 (i) > B2DPlugin VMMaker.oscog-eem.2252 (i) > BitBltPlugin VMMaker.oscog-eem.2243 (i) > FT2Plugin Freetype-Plugin-EstebanLorenzano.70 (e) > FilePlugin VMMaker.oscog-nice.2233 (i) > FloatArrayPlugin VMMaker.oscog-eem.2254 (i) > JPEGReadWriter2Plugin VMMaker.oscog-eem.2243 (e) > LargeIntegers v2.0 VMMaker.oscog-eem.2079 (i) > LocalePlugin VMMaker.oscog-eem.2064 (e) > Matrix2x3Plugin VMMaker.oscog-eem.1975 (i) > MiscPrimitivePlugin VMMaker.oscog-eem.2254 (i) > SecurityPlugin VMMaker.oscog-eem.2166 (i) > SocketPlugin VMMaker.oscog-eem.2064 (i) > SqueakFFIPrims > SurfacePlugin Jul 20 2017 (e) > UnixOSProcessPlugin VMConstruction-Plugins-OSProcessPlugin.oscog-dtl.56 > (i) > ZipPlugin VMMaker.oscog-eem.2243 (i) > > VM Built-in Modules > ------------------- > ADPCMCodecPlugin VMMaker.oscog-eem.2079 (i) > AioPlugin VMConstruction-Plugins-AioPlugin-eem.18 (i) > AsynchFilePlugin VMMaker.oscog-eem.2030 (i) > B2DPlugin VMMaker.oscog-eem.2252 (i) > BMPReadWriterPlugin VMMaker.oscog-eem.1975 (i) > BitBltPlugin VMMaker.oscog-eem.2243 (i) > DSAPrims CryptographyPlugins-eem.12 (i) > DropPlugin VMMaker.oscog-eem.1975 (i) > FFTPlugin VMMaker.oscog-eem.2243 (i) > FilePlugin VMMaker.oscog-nice.2233 (i) > FloatArrayPlugin VMMaker.oscog-eem.2254 (i) > GeniePlugin v2.0 15 June 2017 VMMaker.oscog-eem.2243 (i) > HostWindowPlugin VMMaker.oscog-eem.2064 (i) > IA32ABI VMMaker.oscog-eem.2156 (i) > LargeIntegers v2.0 VMMaker.oscog-eem.2079 (i) > Matrix2x3Plugin VMMaker.oscog-eem.1975 (i) > MiscPrimitivePlugin VMMaker.oscog-eem.2254 (i) > SecurityPlugin VMMaker.oscog-eem.2166 (i) > SocketPlugin VMMaker.oscog-eem.2064 (i) > SoundCodecPrims VMMaker.oscog-eem.1975 (i) > SoundGenerationPlugin VMMaker.oscog-eem.2079 (i) > SoundPlugin VMMaker.oscog-eem.2218 (i) > SqueakFFIPrims > StarSqueakPlugin VMMaker.oscog-eem.2079 (i) > UnixOSProcessPlugin VMConstruction-Plugins-OSProcessPlugin.oscog-dtl.56 > (i) > VMProfileMacSupportPlugin VMMaker.oscog-eem.2079 (i) > ZipPlugin VMMaker.oscog-eem.2243 (i) > > Virtual Machine Parameters > -------------------------- > #1 417575824 end (v3)/size(Spur) of old-space (0-based, read-only) > #2 2457904 end (v3)/size(Spur) of young/new-space (read-only) > #3 422576128 end (v3)/size(Spur) of heap (read-only) > #4 nil nil (was allocationCount (read-only)) > #5 nil nil (was allocations between GCs (read-write) > #6 0 survivor count tenuring threshold (read-write) > #7 1 full GCs since startup (read-only) > #8 1103 total milliseconds in full GCs since startup (read-only) > #9 906 incremental GCs (SqueakV3) or scavenges (Spur) since startup > (read-only) > #10 537 total milliseconds in incremental GCs (SqueakV3) or scavenges > (Spur) since startup (read-only) > #11 745995 tenures of surving objects since startup (read-only) > #12 0 12-20 were specific to ikp's JITTER VM, now 12-19 are open for use > #13 0 12-20 were specific to ikp's JITTER VM, now 12-19 are open for use > #14 0 12-20 were specific to ikp's JITTER VM, now 12-19 are open for use > #15 0 12-20 were specific to ikp's JITTER VM, now 12-19 are open for use > #16 431742214 12-20 were specific to ikp's JITTER VM, now 12-19 are open > for use > #17 0 12-20 were specific to ikp's JITTER VM, now 12-19 are open for use > #18 436 12-20 were specific to ikp's JITTER VM, now 12-19 are open for use > #19 2936531 12-20 were specific to ikp's JITTER VM, now 12-19 are open > for use > #20 3697347243026912 utc microseconds at VM start-up (actually at time > initialization, which precedes image load). > #21 322 root table size (read-only) > #22 0 root table overflows since startup (read-only) > #23 0 bytes of extra memory to reserve for VM buffers, plugins, etc > (stored in image file header). > #24 33554432 memory threshold above which shrinking object memory (rw) > #25 16777216 memory headroom when growing object memory (rw) > #26 2 interruptChecksEveryNms - force an ioProcessEvents every N > milliseconds (rw) 27 number of times mark loop iterated for current > IGC/FGC (read-only) includes ALL marking > #28 0 number of times sweep loop iterated for current IGC/FGC (read-only) > #29 0 number of times make forward loop iterated for current IGC/FGC (read-only) > 30 number of times compact move loop iterated for current IGC/FGC > (read-only) > #31 3 number of grow memory requests (read-only) > #32 1 number of shrink memory requests (read-only) > #33 316 number of root table entries used for current IGC/FGC (read-only) > #34 2683771912 number of allocations done before current IGC/FGC > (read-only) > #35 3227 number of survivor objects after current IGC/FGC (read-only) > #36 454659763 millisecond clock when current IGC/FGC completed (read-only) > #37 0 number of marked objects for Roots of the world, not including Root Table > entries for current IGC/FGC (read-only) > #38 0 milliseconds taken by current IGC (read-only) > #39 0 Number of finalization signals for Weak Objects pending when current IGC/FGC > completed (read-only) > #40 4 BytesPerOop for this image > #41 6521 imageFormatVersion for the VM > #42 50 number of stack pages in use > #43 0 desired number of stack pages (stored in image file header, max > 65535) > #44 3801936 size of eden, in bytes > #45 0 desired size of eden, in bytes (stored in image file header) > #46 1048576 machine code zone size, in bytes (Cog only; otherwise nil) > #47 0 desired machine code zone size (stored in image file header; Cog > only; otherwise nil) > #48 0 various header flags. See getCogVMFlags. > #49 256 max size the image promises to grow the external semaphore table > to (0 sets to default, which is 256 as of writing) > #50 nil nil; reserved for VM parameters that persist in the image (such as eden > above) > #51 nil nil; reserved for VM parameters that persist in the image (such as eden > above) > #52 131072 root table capacity > #53 3 number of segments (Spur only; otherwise nil) > #54 31023112 total size of free old space (Spur only, otherwise nil) > #55 0.33333298563957214 ratio of growth and image size at or above which > a GC will be performed post scavenge > #56 130532 number of process switches since startup (read-only) > #57 23738 number of ioProcessEvents calls since startup (read-only) > #58 244260 number of ForceInterruptCheck calls since startup (read-only) > #59 241874 number of check event calls since startup (read-only) > #60 437141 number of stack page overflows since startup (read-only) > #61 42 number of stack page divorces since startup (read-only) 62 compiled > code compactions since startup (read-only; Cog only; otherwise nil) > #63 148 total milliseconds in compiled code compactions since startup (read-only; > Cog only; otherwise nil) > #64 2492 the number of methods that currently have jitted machine-code > #65 3 whether the VM supports a certain feature, MULTIPLE_BYTECODE_SETS > is bit 0, IMMTABILITY is bit 1 > #66 4096 the byte size of a stack page > #67 0 the max allowed size of old space (Spur only; nil otherwise; 0 > implies no limit except that of the underlying platform) > #68 28.26872246696035 the average number of live stack pages when scanned > by GC (at scavenge/gc/become et al) > #69 50 the maximum number of live stack pages when scanned by GC (at scavenge/gc/become > et al) > #70 1 the vmProxyMajorVersion (the interpreterProxy VM_MAJOR_VERSION) > #71 14 the vmProxyMinorVersion (the interpreterProxy VM_MINOR_VERSION) > > > > -- > Cyrille Delaunay > > > -- Cyrille Delaunay

March 1, 2018