[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