Skip to ContentSkip to Footer
Start of content
- Community Home
- >
- Servers and Operating Systems
- >
- Operating System - OpenVMS
- >
- PGFLQUOTA limit with NEW - DISPOSE
Operating System - OpenVMS
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
-
- Forums
-
- Advancing Life & Work
- Advantage EX
- Alliances
- Around the Storage Block
- HPE Ezmeral: Uncut
- OEM Solutions
- Servers & Systems: The Right Compute
- Tech Insights
- The Cloud Experience Everywhere
- HPE Blog, Austria, Germany & Switzerland
- Blog HPE, France
- HPE Blog, Italy
- HPE Blog, Japan
- HPE Blog, Middle East
- HPE Blog, Russia
- HPE Blog, Saudi Arabia
- HPE Blog, South Africa
- HPE Blog, UK & Ireland
-
Blogs
- Advancing Life & Work
- Advantage EX
- Alliances
- Around the Storage Block
- HPE Blog, Latin America
- HPE Blog, Middle East
- HPE Blog, Saudi Arabia
- HPE Blog, South Africa
- HPE Blog, UK & Ireland
- HPE Ezmeral: Uncut
- OEM Solutions
- Servers & Systems: The Right Compute
- Tech Insights
- The Cloud Experience Everywhere
-
Information
- Community
- Welcome
- Getting Started
- FAQ
- Ranking Overview
- Rules of Participation
- Tips and Tricks
- Resources
- Announcements
- Email us
- Feedback
- Information Libraries
- Integrated Systems
- Networking
- Servers
- Storage
- Other HPE Sites
- Support Center
- Aruba Airheads Community
- Enterprise.nxt
- HPE Dev Community
- Cloud28+ Community
- Marketplace
-
Forums
-
Blogs
-
Information
-
English
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
02-04-2008 11:36 AM
02-04-2008 11:36 AM
Re: PGFLQUOTA limit with NEW - DISPOSE
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
02-04-2008 11:51 AM
02-04-2008 11:51 AM
Re: PGFLQUOTA limit with NEW - DISPOSE
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
02-04-2008 07:07 PM
02-04-2008 07:07 PM
Re: PGFLQUOTA limit with NEW - DISPOSE
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.
>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.
A crucible of informative mistakes
- « Previous
-
- 1
- 2
- Next »
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
End of content
United States
Hewlett Packard Enterprise International
Communities
- Communities
- HPE Blogs and Forum
© Copyright 2021 Hewlett Packard Enterprise Development LP