* ford-fusion: (259 commits)
clay: remove scaffolding
kiln: make otas continue even if they failed to apply
metadata-store: add cleanup utility, use on-poke:def instead of no-op
clay: flop syntax error trace
landscape/img/codeeval.png: typo in filename
invite-view: reinstate as potato
goad: don't crash on pre-OTA sign
chat-store: responded to comments, cleaned up
-test: support other desks (full beams in args)
arvo: use date instead of kelvin
hoon: re-fix +slab; /tests: fix clay tests
kiln: don't implicitly create syncs
gall: don't make large stack trace
ames: use +cut in +encrypt
pill: solid
dojo: print generator type errors
Squashed commit of the following:
ci: fix herb tests; update pills
ford,kiln: nicer errors
dojo: too many nouns
...
Signed-off-by: Philip Monk <phil@pcmonk.me>
* master:
vere: bump version to 0.10.7
libsigsegv: disable stack vma check
vere: bump version to 0.10.6
ci: add travis as trusted user
jets: use appropriate macro
noun: add -C to control memo cache size
jets: restore fond/play/peek hooks
jam: add commented-out functionality to count size of atom
jets: cap memo cache and remove peek, play, and fond jets
noun: add functions to count size of noun
This patches libsigsegv to not check the stack vma on Linux, since that
involves reading procfs, and we make very heavy use of sigsegv. This
eliminates most of urbit's performance discrepancy between Linux and
MacOS. These are the benchmarks used; note this is a local MBP vs a
cloud Linux server, and the MBP is almost certainly faster hardware.
We take two benchmarks, one of which decrements 10 million times and the
other simply allocates 125MB of memory. These are the results:
cpu-heavy == =/ n 10.000.000 |-(?~(n n $(n (dec n))))
mem-heavy == =a (bex 1.000.000.008)
macos, cpu-heavy: 6 seconds
macos, mem-heavy: 1 second
linux-before, cpu-heavy: 30 seconds
linux-before, mem-heavy: 160 seconds
linux-after, cpu-heavy 9 seconds
linux-after, mem-heavy 1.3 seconds
This represents a 3x speedup for the cpu-heavy operation and a 120x
speedup for the memory-heavy operation.
This check was used to try to distinguish stack overflow from other
forms of segmentation fault. In the comments in src/handler-unix.c, it
describes three heuristics it uses, depending on what's available from
the OS. In the linux-i386 case, all three are availble, so we simply
disable the slow one. This correctly recognizes stack overflow if you
simply alloca(10000000000).
