#9 Reclearing system RAM on F$SRqMem

[Boisy Pitre]

Some years back, I put some code into F$SRqMem which did the following:

foreach BLOCK of 8 DAT block pointers at D.SysDAT
{
if (BLOCK = $333E) // block is free
{
foreach PAGE in D.SysMem corresponding to that block
{
clear the byte
}
}
else
{
look in D.BlkMap and get block marker byte for block
if it is not marked as RamInUse
{
foreach PAGE in D.SysMem corresponding to that block
{
byte at PAGE = byte marker
}
}
}
}

The gist of all of this is that each time an F$SRqMem is being done (which is done at least every time a process is created or device initialized), the system map is 'redrawn' based upon the state of the system's DAT image.

Now why I did this, I cannot remember. I seem to vaguely recall that there was a case where the system memory page table (that is, 256 byte page table that determines the free/available state of system RAM) would get out of sync with the actual state of SysDAT.

Given that this is a significant slowdown, I just feel better commenting it out of fsrqmem.asm for now, and waiting to see just what spurned this. I wouldn't want to release NitrOS-9 with this commented out, so I am filing this as a bug report to remind me (and others) that this is experimental!

[Robert Gault]

Logged In: YES
user_id=859353
Originator: NO

The most likely source for page table and sysdat getting out of sync would be some vdg/window operation that uses memory but does not release it and/or marks incorrectly either the page table and/or sysdat.

Clearly, fsrqmem should not need to 'redraw' the memory maps if all modules that change it did so correctly. Perhaps we should create a new direct page variable that flags a change in the memory map. Fsrqmem could check the flag to see if the map should be redrawn. This would only happen if some module or system call other than fsrqmem changed system memory.

More to the point, if this code is commented out and there are essentially no people testing the new code looking for memory bleed, what is the point of changing the code?

[Boisy Pitre]

Logged In: YES
user_id=42881
Originator: YES

The problem is, I don't recall the scenario that required this code to be added in the first place. My hope is that by commenting the code, I can run into the problem again and identify a better, more targeted way of fixing it. I seem to recall Alan DeKok and I working on this issue, but this was years back. It wasn't a common occurrence, but something triggered it.

I guess I should be post-whipped for not documenting this better!

[Boisy Pitre]

Logged In: YES
user_id=42881
Originator: YES

Just a note: 3.2.8 will be released with this code still commented out.