Re: UGA inside PGA, yes or no?

Yeah, the realfree memory allocator is possible thanks to mmap() and munmap() memory allocation means in modern kernels. So with old school heap managment you could only either grow or shrink the single process heap from its end and all your private allocations had to come from there (using malloc-like library calls that in turn called brk() syscall) ... so you couldn't release (really free) a chunk of private memory *somewhere in the middle of* the heap when you didn't need it anymore. Thus all private allocations (except special stuff like stack and private static variables) came from the same top level heap -> PGA -> UGA -> etc...).

But with realfree allocation mechanism, Oracle uses mmap() to allocate *independent
ranges* of private process memory and importantly use munmap() later when not needing that range of memory anymore. This was not possible with old school heap grow/shrink brk() system call. And given that database calls finish (CGA), even sessions within a process (UGA) can finish without a process exiting for various reasons, inculding reusing PX slave processes), so now it's possible to really free the unused ranges of memory back to the OS, without affecting other allocations.

I miss this stuff ;-)

--
Tanel Poder
CEO & Product Guy
http://gluent.com


On Thu, Feb 2, 2017 at 2:57 PM, Stefan Koehler <contact_at_soocs.de> wrote:



> Hey Mark,


>

> > If the UGA in not part of the PGA then why does a dump of the PGA Heaps

> produce the UGA Heap as part of its output?

>

> I agree with Jonathan. The dump code is very old and it dumps private

> heaps (top-level PGA, UGA and call heap) or recursive levels of it

> depending on

> the used level. In addition we also talk about some deep internals

> implementation here - mentioning/differing such details would confuse most

> people

> out there i guess. Just another example: You also say "memory for

> hash-aggregation is allocated in PGA" and not "memory for hash-aggregation

> is

> allocated in UGA and respectively in session heap -> kxs-heap-w -> QERGH

> hash-agg".

>

>

> > What does physically stored in the PGA mean anyway in this context since

> the PGA as far as I know is not a single contiguous chunk of memory to

> > begin with. Aren't the posted blocks just pointers and sizes of chunks

> of memory allocated from available memory on request?

>

> Now we are getting really deep, but this is based on how heap memory is

> handled by the OS (or better said on top of the stack) - do not only think

> about the PGA memory allocation (chunks in heaps) from Oracle's point of

> view. Let's keep it very simple and look at the graphic in this article

> (http://www.linuxjournal.com/article/6390?page=0,0) and read the

> following explanation:

>

> UNIX-based systems have two basic system calls that map in additional

> memory:

> * brk:brk() is a very simple system call. brk() simply moves that location

> forward or backward, to add or remove memory to or from the process.

> * mmap:mmap() is like brk() but is much more flexible. It can map memory

> in anywhere, not just at the end of the process.

>

> Now if you think about the dynamically (de-)allocated heaps, sub-heaps,

> sub-sub-heaps (from Oracle's point of view) and map this to how heap memory

> is

> handled by the OS - i think it makes sense to source out various PGA

> allocations into other top-level heaps to be able to free it "on the fly"

> and

> give it back to the OS.

>

> Best Regards

> Stefan Koehler

>


--
http://www.freelists.org/webpage/oracle-l