Branch: refs/heads/Cog
Home: https://github.com/OpenSmalltalk/opensmalltalk-vm
Commit: ea59155db6c643d3a4de062f2a85bfa2d9f7f5ed
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ea59155db6c643d3a4…
Author: Eliot Miranda <eliot.miranda(a)gmail.com>
Date: 2018-12-03 (Mon, 03 Dec 2018)
Changed paths:
M platforms/Cross/plugins/SerialPlugin/sqNullSerialPort.c
A platforms/unix/plugins/SerialPlugin/Makefile.inc
M scripts/gitci
Log Message:
-----------
Fix the SerialPlugin build on linux (sqNullSerialPort.c must be excluded).
Make sure sqNullSerialPort.c will compile other than on Carbon Mac OS <blush>.
Have gitci check incoming if asked to do so.
**NOTE:** This service has been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/
Functionality will be removed from GitHub.com on January 31st, 2019.
wow time flies, its been 18 months since Ronie announced his
Minheadless VM branch...
[1] http://forum.world.st/Minheadless-VM-flavour-status-update-td4928091.html
I've been meaning this whole time to try it out. Recently in my
meandering thoughts on FreeRTOS port, I guessed Minheadless might make
a good starting basis to experiment with.
So a quick test on Ubuntu16.04.3(Windows10-WSL)...
Long ago I'd already done...
git clone git@github.com:OpenSmalltalk/opensmalltalk-vm.git
so I now did...
cd opensmalltalk-vm
git remote add ronie git@github.com:ronsaldo/opensmalltalk-vm.git
git fetch ronie
git checkout MinimalisticHeadless
./scripts/updateSCCSVersions
cd build.minheadless.cmake/x64/pharo.stack.spur/
./mvm
VM=`pwd`/release/dist/pharo
ls $VM
==> confirmed it exists
cd ~/pharo
wget http://files.pharo.org/image/70/latest-minimal-64.zip
unzip latest-minimal-64.zip
sudo $VM Pharo7.0-metacello-64bit-65cff7b.image eval "19 + 23"
==> 42 yay
Particularly interesting from [1] is "using the same CMake scripts for
building on the three platforms: Windows, Linux and OS X."
So I thought I'd also give it a try under Windows10-VisualStudio2017.
I hardly used VS before, so I'll detail what I did as a reminder for
myself (and also in case someone might be able to help if I get
stuck).
Under a windows cmd.exe prompt (having installed git and cloned
opensmalltalk-vm a long time ago)
cd opensmalltalk-vm
git remote add ronie git@github.com:ronsaldo/opensmalltalk-vm.git
git fetch ronie
git checkout -b MinimalisticHeadless ronie/MinimalisticHeadless
I watched video [2] about CMake integration with Visual Studio 10.
and checked the VS workloads configuration specified [2@1:13]
using [3].
There is a CMakeLists.txt file in the git root folder, so..
started VS > File > Open > Folder...
C:\Repos\OpenSmalltalk\opensmalltalk-vm
The CMake command run ([2]@2:13) was...
C:\...\cmake.exe -G "Ninja"
-DCMAKE_INSTALL_PREFIX:PATH="C:\Users\Ben\CMakeBuilds\...\x86-Debug"
-DCMAKE_CXX_COMPILER="C:/.../MSVC/14.14.26428/bin/HostX86/x86/cl.exe"
-DCMAKE_C_COMPILER="C:/.../MSVC/14.14.26428/bin/HostX86/x86/cl.exe"
-DCMAKE_BUILD_TYPE="Debug"
-DCMAKE_MAKE_PROGRAM="C:\...\CMAKE\Ninja\ninja.exe"
"C:\Repos\OpenSmalltalk\opensmalltalk-vm"
I changed the cmake configuration [2@2:27] to "x64-Debug".
For debug target [2@3:00] I chose "pharo.exe"
Hey, thats pretty cool [2@4:05] that switching between targets changes
the highlighting of #ifdef code.
I had a moment when I was missing the "Debug and Launch Settings" menu
item [2@4:40-4:55] and mentioned at [4], but maybe there was some
clash with previously experimenting with git cloning opensmalltalk-vm
from inside VS.
After closing VS and reopening my cmd.exe git'd opensmalltalk-vm it
showed up, but I didn't change any settings there.
Then (with x64-Debug & pharo.exe selected)
I went Cmake > Build All
==> 10 Errors, 9 Warnings, which I'll discuss in a followup post.
cheers -ben
[2] https://blogs.msdn.microsoft.com/vcblog/2016/10/05/cmake-support-in-visual-…
[3] https://docs.microsoft.com/en-us/visualstudio/install/modify-visual-studio
[4] https://blogs.msdn.microsoft.com/vcblog/2016/12/20/cmake-support-in-visual-…
[5] https://developercommunity.visualstudio.com/content/problem/234808/cmake-de…
The current default eden size for 64-bits is 8 Mb which is too small. The performance cost of generation scavenging on 64-bits is radically different at 8Mb vs e.g. 64Mb. For example, here are the GC stats and the time to run for recompiling the Morphic package in a trunk Squeak 640-bit image, collected by running
FileStream stdout print: [(PackageInfo named: 'Morphic') methods do:
[:mr| mr actualClass recompile: mr selector]] timeToRun; cr.
FileStream stdout nextPutAll:
(Smalltalk vm vmStatisticsReportString
replaceAll: Character cr with: Character linefeed)
squeak> 7061
uptime 0m 7s
memory 85,073,920 bytes
old 76,121,888 bytes (89.5%)
young 7,190,528 bytes (8.5%)
used 54,408,216 bytes (64%)
free 26,774,568 bytes (31.5%)
GCs 195 (38.2 ms between GCs)
full 0 totalling 0 ms (0% runtime), avg 0 ms
scavenges 195 totalling 82 ms (1.1% runtime), avg 0.4 ms
tenures 21,139 (avg 108 tenures per scavenge)
Code compactions
0
Aeolus.image$ spur64cfvm -eden 60m spurreader-64. <RecompileMorphicAndReport.st
squeak> 6968
uptime 0m 7s
memory 140,648,448 bytes
old 76,121,888 bytes (54.1%)
young 61,896,704 bytes (44%)
used 62,854,824 bytes (44.7%)
free 43,764,376 bytes (31.1%)
GCs 23 (318.5 ms between GCs)
full 0 totalling 0 ms (0% runtime), avg 0 ms
scavenges 23 totalling 30 ms (0.41% runtime), avg 1.3 ms
tenures 0
Code compactions
0
While the run-time varies very little (7 seconds to 6.97 seconds), the number of scavenges goes down enormously. The reason the run-time is relatively unaffected is because the generation scavenger is quite efficient. At an 8mb young space we see 195 scavenges with about a 1.1% runtime overhead. But at a 64mb young space we see 23 scavenges (a ratio of about 8, which mirrors the ratio of the sizes), but the run-time overhead is now only 0.41%; 82ms overhead vs 30ms overhead. So a larger young space is a good idea.
The suggestion here is that on 64-bit platforms we tailor the default young space size to the available memory. See e.g. https://stackoverflow.com/questions/2513505/how-to-get-available-memory-c-g which provides code above sysconf on Unix and GlobalMemoryStatusEx on WIN32 for obtaining the total amount of physical memory available. Therefore we could use a larger young space on systems with a lot more memory; for example 2Mb of young space per Gb of physical memory would give a 64-mb young space on 32Gb machines such as my fully loaded 2018 MacBook Pro Core i9.
--
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/issues/316