Page file quota exhaustion observed on Itanium but not on Alpha.

[Brian Reiter]

OK,

On our Itanium systems (RX2800, OpenVMS 8-4, Update  v7.0, TCPIP 5-7 ECO 3) we are seeing one of the processes exitting with %LIB-F-INSVIRMEM, insufficient virtual memory.

This has never occurred on our Alpha systems (OpenVMS 7-3-2).

The issue seems to be arounf the creation and un mapping of global sections. The system service call $CRMPSC_GFILE_64 is used tp create a global section, this is then deleted using $DELTVA_64.

Reproducing the calls used shows a gradual exhausting of page file quota on the Itanium, no issues are observed when running the same program on the Alpha (7-3-2). I am unable to test Alpha 8-3 or 8-4, our DS15 running 8-3 failed last week.

Anyway, I've attached the code (Pascal) used to replicate the problem.

[John Gillings]

Brian,

   Nice reproducer. Interesting. I can't see anything obvious which might cause a leak. Does it leak if you just repeatedly map/unmap a single section, or does it take map 1000/unmap 1000?

   Maybe modify the program so it outputs PAGFILCNT ($GETJPI) at strategic places to narrow down the event and quantify the size of the leak?   Could it be an effect of rounding to whole pages?

  I'd also include the output LIB$STAT_VM - there's a possibility that you're checker boarding the heap (again, can't see where that might happen in your code, but it's worth looking).

[John Gillings]

Oh, just realised... something else that might be interesting.

Instead of MAP 1..1000 then UNMAP 1..1000

see what happens if you MAP 1..1000 and UNMAP 1000..1

This may make a difference in terms of how the VM system deals with deleting and possibly reusing memory.

[Brian Reiter]

Hi John.

I fell over the solution yesterday afternoon , it seems to be a leak around the use of the Pascal OPEN routine and lack of corresponding CLOSE.

Each mapping of the global section calls OPEN with a useraction to get the channel. The UNMAP routines just calls $DASSGN using the channel. The size of the type use to defined the file is (SECTION_FILE_TYPE) is 524 bytes.

Amending the code to pass the file handle backwards and forwards and adding a CLOSE of the appropriate file to the UNMAP routine stops the memory leak. It would seem there is a subtle difference in the Pascal RTL between VMS 8-3 and 7-3-2, possibly just between the Alpha and Itanium versions.

Anyway, thanks for the help

cheers

Brian

[John Reagan]

The Pascal RTL keeps an internal list of all open files.  It needs that in the event it has to do any automatic closing of files when they go out of scope or you unwind frames with open files.  One of the few places with platform-specific code is doing the atomic accesses on that list.  The code is thread-safe as well.  They are logically the same, but use somewhat different algorithms due to how they use specific instructions to update/manipulate the list. 

Also during that timeframe, I was probably porting to Itanium and made some structural changes for the port...

So I'm a little surprised by the difference you saw, but not totally shocked by it.

[Dennis Handly]

>The Pascal RTL keeps an internal list of all open files.  ... The code is thread-safe as well.

I couldn't implement procedure scoped files when I implemented threading in Pascal/iX.  Each stack was protected from the other threads due to the kernel design.  But it worked fine in Pascal/UX.

Looking back over the decades, I suppose I could have used a thread specific linked list to handle that but there was no hardware TLS.  Anyway after all that work, I'm not sure anyone ever used threading in those two PA-RISC Pascals.

Especially since all I/O would need to have explicit locking.