Can anyone say if it is normal that the majority of syscalls in a racket process are mprotect? I just happened to notice the 50% of the time of the process syscalls are dedicated to mprotect.

This is typical of one of my racket places: $ sudo strace -c -p 2123 strace: Process 2123 attached strace: [ Process PID=2123 runs in x32 mode. ] strace: [ Process PID=2123 runs in 64 bit mode. ] ^Cstrace: Process 2123 detached % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 51.50 0.316650 1 244298 mprotect 30.99 0.190553 2 105547 mmap 14.68 0.090264 1 105502 munmap 2.30 0.014165 0 184388 1441 rt_sigreturn 0.33 0.002006 0 21246 futex 0.14 0.000852 0 11485 epoll_wait 0.06 0.000366 0 2883 getrusage ------ ----------- ----------- --------- --------- ---------------- 100.00 0.614856 675349 1441 total

This looks actually like I am allocating way too much memory…

@pocmatos that’s how the GC implements the write barrier

Wishlist: nicer CSS for @tabular

BTW, the mprotect implementing GC stuff has bit me before. Some other software I have installed sets the sysctl parameter vm.max_map_count to a lowish value and causes the Racket VM to eventually die.

@samth where’s the best place to learn more about the racket gc?

http://www.cs.utah.edu/plt/publications/ismm09-rwrf.pdf and http://www.cs.utah.edu/plt/publications/ismm04-wf.pdf

Awesome, that’s what I was going to ask for, if you had pointed me to https://docs.racket-lang.org/reference/garbagecollection.html :slightly_smiling_face:

@mflatt Any reason why (ffi-lib "portaudio") would fail on windows when portaudio is placed in the Racket/lib directory?

I am seeing some kind of race condition with the use of places and it’s hard to pinpoint what it could be. When a race condition happens I see a D status in htop and the following top syscalls in strace: % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 69.59 0.203671 17 12339 mprotect 23.13 0.067702 0 306439 92277 futex

I think the mprotect call might be a red herring. The futex is the think I need to look into. Are GCs in anyway interacting between different places? I assumed each one had their own GC but might be wrong.

yes, they have separate gcs

My first guess is that “portaudio.dll” imports other DLLs that have not been loaded first. I’d use Dependency Walker to look at the dependencies.

Oh, that’s an interesting idea.

And that might be why it works on most windows machines.

So this might be because of @jbclements’s library. (And windows being…windows…)

Odd, it can’t find a bunch of API-MS-WIN-CORE-* libraries.

@mflatt Can you remind me which window of dependency walker is the one I should be looking at?

@samth thanks. this will be an interesting debugging session then… sigh

Okay, it looks like MSVC100 is missing…maybe.

That would make sense. I think “msvc100.dll” is a redistributable DLL from Microsoft that is meant to be provided with executables and libraries created by Visual Studio. Installing various software packages will cause it to be installed already.

@pocmatos @samth is right, but there is also a GC for the shared memory space, where place channels, make-shared-bytes, etc. are allocated. Idk if that is relevant to your case at all (this is very low-level for me).

@philip.mcgrath that’s good to know. today I will put my gdb-fu to work and debug racket to see where all of there futex calls are coming from.