PGFLQUOTA limit with NEW - DISPOSE

[John Reagan]

RE: Willem

Note it says the 'processwide pool', not delete the address space. The memory is still allocated and under control of the LIB$VM. I can't say for sure without trying, but a DELETE_ZONE followed by a similar CREATE_ZONE may very well use the same memory.

[John Reagan]

RE: John

When Pascal allocates a schema type (aka "run-time sized type") on the heap, it allocates additional storage that is at "negative" offsets from the pointer returned from NEW. That is where we store the discriminant values used by SIZE, UPPER, etc. You should only use NEW to allocate schema types from the heap.

[John Gillings]

re: Willem,

>so the memory will be re-usable (What >would happen if:
>
>* CREATE_VM_ZONE
>* DELETE_VM_ZONE
>* CREATE_VM_ZONE (same size) --> Will that
>use the same area just deleted?

Maybe! You have no control over what asynchronous threads might do between your DELETE and CREATE. They may allocate a chunk of whatever you just deallocated, leaving it too small to satisfy the CREATE request. If the pool hasn't been coalesced with other deallocations, and the requested zone is large, chances are you'll need to expand memory to satisfy the request.

Even if it seems to work most of the time, you can't depend on undocumented, coincident behaviour. If you really want to control virtual memory at that level, you need to drop down a level and work with $CRETVA, $DELTVA and maybe $MGBLSC. Not for the faint of heart!

What this whole issue comes down to is how to manage a data structure which potentially grows over time. Here are a few possibilities...

1) Design a data structure that can be expanded incrementally from discontiguous memory. For example, a list or tree with discrete elements.

2) Deallocate and reallocate a larger entity when necessary - down side is there is a limit to how big these entities can be in 32 bit space. P0 space is only 1GB, and if you need to allocate the new object first, then copy the contents of the old before deallocating it, that means you need twice the space! Not useful for objects over (say) about 100MB because there isn't enough headroom

3) Allocate an object that is as large as you'll ever need and manage the expansion yourself. This is "cheap" as memory you don't touch won't actually exist, BUT again you're limited by the 1GB P0 space.

4) Learn about 64bit pointers and memory regions. This all becomes a non-issue, as the memory regions are MUCH larger tha you're likely to ever need (but you need to make sure you have enough pagefile space to support the size of virtual memory).

re john: Test with LIB$GET_VM / LIB$FREE_VM

Doing your own GET_VM/FREE_VM can be useful in some circumstances, but you need to know how it interacts with your programming language. As John R has said, Pascal does a lot of things for you in the background, which mostly make life much easier and protect you from numerous pitfalls. You need a good reason to switch off the autopilot.

I'm fairly sure Pascal understands 64 bit addressing. This maybe as simple as adding an attribute ([QUAD,ADDRESS64]?) to the pointer of the object.