[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 28630b: The extra +1 in size parameter passed to mprotect(...

Holger Freyther holger at freyther.de
Fri Dec 23 18:33:25 UTC 2016


> On 23 Dec 2016, at 01:46, Ben Coman <btc at openinworld.com> wrote:
> 
> Just curious about the behaviour and performance of mprotect and VirtualProtect.  Would it be feasible to use on each FFI callout so that aberrant memory access from C code cannot corrupt the Smalltalk Image, but generate an exception that could be handled in-Image?

Hi Ben,

* syscall overhead (e.g. mprotect is not part of the VDSO)
* lock/unlock of Page Table Entries (PTEs)
* walking page table entries
* modifying page table entries
* merging/combining virtual memory areas now (allocation)
* cache/tlb being invalidated


E.g. for FreeBSD the chain is like this with a lot of details on the way

* sys_mprotect[1] the syscall after the dispatch
* vm_map_protect[2] for the VM subsystem
* AMD64's pmap_protect[3] implementation various ways to invalidate the TLB in it

holger



[1] https://github.com/freebsd/freebsd/blob/releng/10.3/sys/vm/vm_mmap.c#L657
[2] https://github.com/freebsd/freebsd/blob/releng/10.3/sys/vm/vm_map.c#L1924
[3] https://github.com/freebsd/freebsd/blob/releng/10.3/sys/amd64/amd64/pmap.c#L3906


More information about the Vm-dev mailing list