Vm-dev March 2018

vm-dev@lists.squeakfoundation.org

46 participants
218 discussions

[OpenSmalltalk/opensmalltalk-vm] FilePlugin>>primitiveFileAtEnd for non-regular files (#232)
by akgrant43 06 Apr '18

06 Apr '18

FilePlugin currently splits files in to two groups: 1) Stdio streams and 2) everything else. To test for the end of file, FilePlugin>>primitiveFileAtEnd: 1) Uses feof() for stdio streams. 2) Compares the current position to the file size for everything else. This returns the expected results for regular files, but fails for non-regular files, e.g.: (FileSystem / 'dev' / 'urandom') binaryReadStream next: 8. returns an empty array. On Unix, the proper way to check is to read past the end of the file and then call feof() to confirm that it is in fact at the end. Pharo has plenty of code that assumes that a file position >= the file size means that the file is at the end, and as stated above this generally works for regular files. This patch modifies FilePlugin>>primitiveFileAtEnd to: a) Keep the current behaviour of using the file position test for regular files. b) Keep the current behaviour of using feof() for stdio streams. c) Use feof() for non-regular files, e.g. /dev/urandom. This allows existing code to continue to function, and allows non-regular files to be tested correctly. After applying the patch, the example code above answers the expected result, e.g.: (FileSystem / 'dev' / 'urandom') binaryReadStream next: 8. " #[179 136 227 226 28 147 197 125]" On Windows, as far as I can tell, all files are regular, and the position test is used regularly, so no change is requried. Fogbugz: https://pharo.fogbugz.com/f/cases/21643/ You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/232 -- Commit Summary -- * FilePlugin>>primitiveFileAtEnd for non-regular files -- File Changes -- M platforms/Cross/plugins/FilePlugin/FilePlugin.h (2) M platforms/Cross/plugins/FilePlugin/sqFilePluginBasicPrims.c (30) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/232.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/232.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/232

5 31

VM simulator screen cast
by Clément Bera 05 Apr '18

05 Apr '18

Hi all, I made a screencast of myself using the Cog VM simulator to solve a bug in the Sista VM (including single stepping in machine code generated by the JIT) and published it on youtube: https://clementbera.wordpress.com/2018/03/07/sista-vm-screencast/ https://www.youtube.com/watch?v=hctMBGAXVSs It's not amazing, you have to deal with my French accent, but some of you might be interested. Best, -- Clément Béra https://clementbera.github.io/ https://clementbera.wordpress.com/ Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

3 3

[OpenSmalltalk/opensmalltalk-vm] macos: Fix --trace for the PharoVM (#231)
by Holger Freyther 02 Apr '18

02 Apr '18

Introduce VMOPTIONLEN that can offset the extra '-' in the calculations. You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/231 -- Commit Summary -- * macos: Fix --trace for the PharoVM -- File Changes -- M platforms/iOS/vm/OSX/sqSqueakOSXApplication.m (16) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/231.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/231.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/231

3 5

Problem compiling SqueakFFI Plugin
by Javier Pimás 01 Apr '18

01 Apr '18

when generating the squeakffi plugin I get different sources than the ones in src/plugins dir. Mine generate a compiler error, because isImmediate is redefined, any idea? the original src/X64SysVFFIPlugin.c contains (~ line 460): #if !defined(isImmediate) #if VM_PROXY_MAJOR > 1 || (VM_PROXY_MAJOR == 1 && VM_PROXY_MINOR >= 13) extern sqInt isImmediate(sqInt anObject); #else # define isImmediate(anObject) 0 #endif #endif while mine gets: #if VM_PROXY_MAJOR > 1 || (VM_PROXY_MAJOR == 1 && VM_PROXY_MINOR >= 13) extern sqInt isImmediate(sqInt anObject); #else # define isImmediate(anObject) 0 #endif #if !defined(isImmediate) #endif Cheers, Pocho -- Javier Pimás Ciudad de Buenos Aires

2 2

Re: [Vm-dev] [Pharo-dev] Image crashing on startup, apparently during GC
by Esteban Lorenzano 01 Apr '18

01 Apr '18

hi, > On 24 Mar 2018, at 09:50, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > Le 23/03/2018 à 21:52, Eliot Miranda a écrit : >> Hi Damien, >> >> Indeed the image is corrupt at start-up. See below. >> >> >> Right. This VM is prior to the bug fixes in VMMaker.oscog-eem.2320: >> >> Spur: >> Fix a bad bug in SpurPlnningCompactor. >> unmarkObjectsFromFirstFreeObject, used when the compactor requires more >> than one pass due to insufficient savedFirstFieldsSpace, expects the >> corpse of a moved object to be unmarked, but >> copyAndUnmarkObject:to:bytes:firstField: only unmarked the target. >> Unmarking the corpse before the copy unmarks both. This fixes a crash >> with ReleaseBuilder class>>saveAsNewRelease when non-use of cacheDuring: >> creates lots of files, enough to push the system into the multi-pass regime. >> >> >> Pharo urgently needs to upgrade the VM to one more up to date than 2017 >> 08 27 (in fact more up-to-date than opensmalltalk/vm commit >> 0fe1e1ea108e53501a0e728736048062c83a66ce, Fri Jan 19 13:17:57 2018 >> -0800). The bug that VMMaker.oscog-eem.2320 fixes can result in image >> corruption in large images, and can occur (as it has here) at start-up, >> causing one's work to be irretrievably lost. >> > > Hi Eliot, > > I think that there is a lot of people who would like to get a newer > stable vm for Pharo 6.1 and 7. The problem is that it is hard to know > which VM are stable enough to be promoted as stable. > > Some weeks ago Esteban tried to promote a VM as stable and he had to > revert it the same day because a regression occurred in the VM. > > If you're able to tell us which vms are stable in those present at > http://files.pharo.org/vm/pharo-spur32/ and > http://files.pharo.org/vm/pharo-spur64/ it would be a great help. > > Even better would be for the pharo community to have a way to know which > vms are stable or not without having to ask you. there is no “stable” branch in Cog, and that’s a problem. “released” versions (the version you can find as stable) are not working for Pharo :( I tried to promote versions from end feb and that crashed. next week I will try again, maybe now they are stable enough… one thing is true: the versions that we consider stable (from oct/17) present problems that are already solved on latest. Esteban > > Have a nice day. > >> >> -- >> _,,,^..^,,,_ >> best, Eliot > -- > Cyril Ferlicot > https://ferlicot.fr >

6 10

SafeFFI concept
by Ben Coman 01 Apr '18

01 Apr '18

This idea is not fully formed. I've been nibbling away at composing this post for a month and thought I'd just send it out rather than let it drift on further. Its an idea that keeps resurfacing but I've not been in a position to follow it up, so I'm just sharing the rough outline. One of the great features of programming at the Image level is protection from memory access violations. We get to continue from errors after debugging them. However all bets are off when we use FFI. The bane of FFI are memory violations in the C-callout. Memory violations in FFI C callouts are harder than usual to diagnose since we lose our usual debugging environment. Its hard to recovery from a memory violation since the C callout has full access to VM's heap and thus everything is suspect. So the idea is the FFI callouts to execute in a separate child-process. That child-process has no access to the VM's memory so a memory violation in the C-callout could not crash the VM. Obviously there will be some performance penalty, but the question is to what degree. There are two reasons to use an external library via FFI. 1. Speed 2. Functionality Where its more about functionality than speed (e.g. git, libusb, libsodium, pdfium) application developers newly programming against an unfamiliar C library may be willing to trade speed for safety. Perhaps its used part-time like the Assert-VM during development, and production uses the standard higher performance FFI. The idea of executing FFI callouts in a child-process arose while reading about Linux's clone() function that the parent process can allocate memory for the stack of the child process. https://stackoverflow.com/questions/1083172/how-to-mmap-the- stack-for-the-clone-system-call-on-linux https://nullprogram.com/blog/2015/05/15/ The child-process might be a simple event loop waiting on a semaphore. My understanding of the FFI callout mechanism is that stack frame is constructed in the form expected by the function being invoked. With SafeFFI, when "fficallout" semaphore is being waited on, the child stack is static, so maybe the VM-parent-process could arrange the stack in the child-process such that sem_wait() returns not to line 005 but instead executes the required FFI-callout function. The "fficallout" semaphore is signalled from the Image once the stack frame has been constructed. 001 main() 002 { expose_child_function_addresses_to_parent_process(); 003 while(true) 004 { sem_wait(&fficallout); // Smalltalk image reconstructs stack frame here 005 printf("Dummy statement. Never gets here"); 006 } 007 } 008 009 demo_redirect() 010 { printf("SafeFFI demo success"); 011 } So how feasible would something like that be? cheers -ben P.S. For initial simplicity of the presentation I've avoided discussing return values and callbacks.

3 4

Cannot download a spur image using getGoodSpur64VM on linux
by Javier Pimás 31 Mar '18

31 Mar '18

Hi again! was trying to run this: /CogNOS/opensmalltalk-vm/image$ ./buildspurtrunkvmmaker64image.sh but it fails. The culpirit seems to be: /CogNOS/opensmalltalk-vm/image$ ./getGoodSpur64VM.sh checking for latest 64-bit VM on bintray... cannot find latest release on https://bintray.com/opensmalltalk/notifications Cheers! -- Javier Pimás Ciudad de Buenos Aires

4 5

[OpenSmalltalk/opensmalltalk-vm] Fixed typo in the download URL (#230)
by smalltalking 31 Mar '18

31 Mar '18

You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/230 -- Commit Summary -- * Fixed typo in the download URL -- File Changes -- M image/getGoodSpur64VM.sh (2) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/230.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/230.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/230

3 3

[OpenSmalltalk/opensmalltalk-vm] 804ed5: Fixed typo in the download URL
by GitHub 31 Mar '18

31 Mar '18

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 804ed5c609724be854c0b97332748b7a7c1f5e88 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/804ed5c609724be854… Author: Levente Uzonyi <leves(a)caesar.elte.hu> Date: 2018-03-22 (Thu, 22 Mar 2018) Changed paths: M image/getGoodSpur64VM.sh Log Message: ----------- Fixed typo in the download URL Commit: 79c0809998d55c2ae9b5ff3b1e1ac0190bef1602 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/79c0809998d55c2ae9… Author: Clement Bera <bera.clement(a)gmail.com> Date: 2018-03-31 (Sat, 31 Mar 2018) Changed paths: M image/getGoodSpur64VM.sh Log Message: ----------- Merge pull request #230 from smalltalking/Cog Fixed typo in the download URL Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/e8c753c88ca3...79…

1 0

VM stability / unit tests
by Phil B 30 Mar '18

30 Mar '18

While I've been enjoying the fantastic performance improvements we've seen from Cog onward, one thing I've been less excited about are some of the stability/functionality issues I've been running into. They are not numerous (maybe 1/2 dozen or so major ones in the last 5 years) but they are getting quite tedious to isolate and replicate. Recent examples that come to mind include the 64-bit primHighResClock truncation and 'could not grow remembered set' issues (My current joy is a case where I have an #ifTrue: block that doesn't get executed unless I convert it to an #ifTrue:ifFalse: with a noop for the ifFalse:.. I'll provide a reproducible test case as soon as I'm able. The specific issue isn't the issue, but rather that I keep hitting things like this that seem rather fundamental yet edge-casey at the same time) I don't expect perfection as a phenomenal amount of progress is being made by a small group of people but I am beginning to wonder if the existing unit tests are sufficient to adequately exercise the VM? I.e. so that the VM developers are aware that a recent change may have broken something or are the existing tests mainly oriented towards image and bytecode VM development? Just some food for thought and wanted to see if it's just me having these sorts of issues... Thanks, Phil

3 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev March 2018