Minerva, C68 and memory mysteries
Posted: Sat Dec 14, 2019 2:38 pm
Hi,
today I have somewhat of a tricky C problem:
Up to now, I never saw a need to use the _mneed variable (which, to my understanding, hints the runtimes to the initial need for heap memory of the program) in one of my (many) C68 programs. I normally leave it at its default of 8k. (I must admit I haven't written programs for BBQLs or Minerva a lot recently, so most of these programs run on SMSQ/E)
Now I have one program which is fairly large, about 70k pure program size, 32k of stack and data space, which is allocating (and holding) rather large amounts of memory via malloc at sizes of about 400-500k. It doesn't set _mneed.
That works perfectly fine on a SGC QL running SMSQ/E, no hickups whatsoever.
It doesn't work at all on the very same QL running Minerva only. Even with a newly started machine that has no other programs running, one of the first allocations (a 32k chunk to save screen memory in) is returning NULL, which is puzzling me. At this point in time, FREE_MEM returns nearly the full 4MB. No good reason for malloc to fail.
When I set _mneed, though, the allocations work fine, and the program works, even on Minerva. (I do, however, not really like to set _mneed: The memory requirements of the program are mainly determined by data files loaded at run time and thus not at all constant or deterministic)
Does anyone have a clue what the mysterious difference between SMSQ/e and Minnie is when executing that program? I would assume the C runtimes uses mt.alchp to fetch the memory in both systems and simply fetches more, when needed, up to the limit set by _memmax - But there must be subtile differences why Minerva wants to see the memory pre-allocated at startup. Even if Minnie would be so crazy and put the program to the middle of the TPA, there should be enough contiguous space to fulfill the request)
Tobias
today I have somewhat of a tricky C problem:
Up to now, I never saw a need to use the _mneed variable (which, to my understanding, hints the runtimes to the initial need for heap memory of the program) in one of my (many) C68 programs. I normally leave it at its default of 8k. (I must admit I haven't written programs for BBQLs or Minerva a lot recently, so most of these programs run on SMSQ/E)
Now I have one program which is fairly large, about 70k pure program size, 32k of stack and data space, which is allocating (and holding) rather large amounts of memory via malloc at sizes of about 400-500k. It doesn't set _mneed.
That works perfectly fine on a SGC QL running SMSQ/E, no hickups whatsoever.
It doesn't work at all on the very same QL running Minerva only. Even with a newly started machine that has no other programs running, one of the first allocations (a 32k chunk to save screen memory in) is returning NULL, which is puzzling me. At this point in time, FREE_MEM returns nearly the full 4MB. No good reason for malloc to fail.
When I set _mneed, though, the allocations work fine, and the program works, even on Minerva. (I do, however, not really like to set _mneed: The memory requirements of the program are mainly determined by data files loaded at run time and thus not at all constant or deterministic)
Does anyone have a clue what the mysterious difference between SMSQ/e and Minnie is when executing that program? I would assume the C runtimes uses mt.alchp to fetch the memory in both systems and simply fetches more, when needed, up to the limit set by _memmax - But there must be subtile differences why Minerva wants to see the memory pre-allocated at startup. Even if Minnie would be so crazy and put the program to the middle of the TPA, there should be enough contiguous space to fulfill the request)
Tobias