The eval-model documentation includes the following sentences about The Separate Compilation Guarantee:

“The practical consequence of this guarantee is that because effects are never visible, no module can detect whether a module it requires is already compiled. Thus, it can never change the compilation of one module to have already compiled a different module.”

Can anyone explain the second sentence?

I think it means that if module B depends on A, whether A is already compiled or not won’t change compilation of B

@paul I think the second sentence could be more clearly worded as “Thus, the compilation of one module cannot be affected by having already compiled a different module.”

I am having an interesting situation where a process that should not be increasingly using more and more memory, actually is. I have looked into vector-set-performance-stats! and current-memory-use and I can confirm that the memory is increasing. My question now is… is there a way to find out who is allocating this memory?

@pocmatos I recommend first (dump-memory-stats)

if that isn’t enough info, then you can build with more memory debugging info

  --enable-sgcdebug       use Senora GC for debugging (expensive debug mode)
  --enable-backtrace      3m: support GC backtrace dumps (expensive debug mode

@samth Thanks. I will give those a try.

@samth I assume I need to compile racket with both those flags?

as far as I understood, senora gc is the 3m gc right?

The reason I ask is because the build fails when I try to build racket with both flags.

Now: https://github.com/racket/racket/issues/2340

@pocmatos I think only --enable-backtrace is going to be useful, but it’s also a little flaky. FWIW, the dump-memory-stats function on RacketCS is reliable and always fully available.

@mflatt thanks. I will give --enable-backtrace a try. Haven’t managed to try RacketCS yet, but I will try to find the time asap.

@mflatt, right, it’s flaky as well as you said. --enable-backtrace on HEAD gives me : mprotect failed: 7f2e4dd68000, 65536, 1, 12 make[3]: *** [Makefile:85: in-place-setup] Aborted (core dumped)

By the way, what’s the status of racketcs? It seems that by saying that the memory dump function is reliable in cs, it implies that I should give it a try. What’s missing in cs?

https://m.youtube.com/watch?v=t09AJUK6IiM

I don’t know all the details about what functionality is missing in cs, the YouTube video has a useful status report

RacketCS works well enough that it’s worth a try