CLISYMTBL and Virtual memory footprint.

[Dave PNCGIS]

We run very tight on virtual memory space because of the size of our application images. I need to bump up CLISYMTBL to allow for one process that creates a large number of symbols. Doe CLISYMTBL actually allocate its value in pagelets to the users virtual memory footprint, or is it just pointers that use memory when symbols are created?

[John Gillings]

Dave,

If you're running on Alpha or Itanium virtual memory shouldn't be an issue. 64 bits is BIG.

The CLISYMTBL lives in P1 space. Although it will increase your virtual memory consumption (and will require page file backing), any limits you're experiencing are likely to be in P0 space, orthogonal to P1. See $GETJPI items FREP0VA and FREP1VA.

Long term, look at your application with a view to moving large data structures into P2 space, the size of which is only limited by your wallet.

[H.Becker]

Pagelets for the symbols to be created. It all lives in P1. With SDA and clue proc/layout you can see the "CLI Data", it has the size of CLISYMTBL (rounded to pages, I assume). It is just above the user mode stack.

Making it bigger usually doesn't create a problem. Your application images usually are in P0. But it is possible to have a big portion of the application in P1, in the "Shareable Linkage Area": images installed with shared address data.

SDA> sh proc/region=1 shows what's free in P1. This usually is different for different processes. CLISYMTBL sets the size for ALL processes. If you "dynamically" change it, it only effects newly created processes.