Branch: refs/heads/fix_BitBlt_Issue_447
Home: https://github.com/OpenSmalltalk/opensmalltalk-vm
Commit: 7225aecbb30015cd60b2fd8a4520726c343381e8
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/7225aecbb30015cd60…
Author: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>
Date: 2019-11-21 (Thu, 21 Nov 2019)
Changed paths:
M src/plugins/BitBltPlugin/BitBltPlugin.c
Log Message:
-----------
Attempt to Fix Issue #447 - BitBlt signed int overflow
Generate the plugin from VMMaker.oscog-nice.2587 which declare `dx dy sx sy` as sqInt rather than int.
Branch: refs/heads/Cog
Home: https://github.com/OpenSmalltalk/opensmalltalk-vm
Commit: 9320a52ef11fd144697c561eed3eff1412951777
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/9320a52ef11fd14469…
Author: Eliot Miranda <eliot.miranda(a)gmail.com>
Date: 2019-11-21 (Thu, 21 Nov 2019)
Changed paths:
A build.macos64x64/gdbarm64/clean
M platforms/Cross/plugins/GdbARMPlugin/GdbARMPlugin.h
M platforms/Cross/plugins/GdbARMPlugin/sqGdbARMPlugin.c
M platforms/Cross/plugins/GdbARMv8Plugin/GdbARMv8Plugin.h
M platforms/Cross/plugins/GdbARMv8Plugin/sqGdbARMv8Plugin.c
M processors/ARM/gdb-8.3.1/sim/aarch64/simulator.c
Log Message:
-----------
Get the GdbARMv8Plugin to check the pc against minWriteMaxExecAddr correctly
and update its pc after execution. It now steps and runs properly.
Modify instruction access/pc dereference in the gdb code to use the support
routine in sqGdbARMv8Plugin.c.
With these changes GdbARMv8AlienTests can run testNFib4 et al.
[ci skip]
I saw an interesting tweet on "GildaVM: a Non-Blocking I/O Architecture for
the Cog VM" [1]
which shows the VM running multiple interpreter-threads.
Where is the paper shown on page 23 available?
Side thought, if "usually, 1% of objects survive their first scavenge" [2]
as a "breadth-first traversal of objects from the remembered table (a table
holding all old objects referencing new objects) and the stack"
that implies only a small percentage object mutations were in old space (??)
which makes wonder if each interpreter-thread had its "own" new-space,
then scavenging each new-space could run independently in
parallel-native-threads?
Thus a global lock may only(?) be needed to mutate a shared old-space and
minimize .
This ignores the execution-engine needing to update method-lookup tables.
Could native-threads start with their own copy of a warmed up JIT and then
work independently?
cheers -ben
[1]
https://www.slideshare.net/esug/gildavm-a-nonblocking-io-architecture-for-t…
[2]
https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-colle…
Branch: refs/heads/Cog
Home: https://github.com/OpenSmalltalk/opensmalltalk-vm
Commit: 9336eea43c07382f5b3c0032a1ddf86f154c06a8
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/9336eea43c07382f5b…
Author: Eliot Miranda <eliot.miranda(a)gmail.com>
Date: 2019-11-19 (Tue, 19 Nov 2019)
Changed paths:
A build.macos32x86/gdbarm64/conf.COG
A build.macos32x86/gdbarm64/makeem
M platforms/Cross/plugins/GdbARMv8Plugin/sqGdbARMv8Plugin.c
M processors/ARM/exploration64/Makefile
Log Message:
-----------
Get the 32-bit version of ARMv8 exploration64 to work.
Stop running in the GdbARMv8Plugin as soon as anything is logged.
[ci skip]