[HN Gopher] How ZGC allocates memory for the Java heap
       ___________________________________________________________________
        
       How ZGC allocates memory for the Java heap
        
       Author : lichtenberger
       Score  : 58 points
       Date   : 2025-04-23 11:24 UTC (11 hours ago)
        
 (HTM) web link (joelsiks.com)
 (TXT) w3m dump (joelsiks.com)
        
       | gopalv wrote:
       | The 32x virtual memory to physical memory ratio plays into
       | relocation and colored pointers (i.e pointers where some bits
       | serve as flag bits).
       | 
       | Putting the actual data layouts in 44 bits out of 64 is a neat
       | trick which relies on the allocator being aware of the mappings
       | between physical and virtual addresses.
        
         | twoodfin wrote:
         | When your comment and the article refer to "physical"
         | addresses, those are physical in the context of the JVM, right?
         | To the OS they're virtual addresses in the JVM process space?
        
           | acchow wrote:
           | Correct. ZGC has no way to escape from the virtualization by
           | the kernel (assuming your hardware and kernel uses an MMU)
        
         | hinkley wrote:
         | In the beginning of the 32 bit revolution, when the future was
         | here but unevenly distributed, there was a lot of talk about
         | how 32 bit pointers would fundamentally change how people wrote
         | code. Among other things it got rid of a bunch of odd
         | bookkeeping, and if you don't have to do the bookkeeping you
         | don't have to write the code in a way that supports it, so you
         | can do other things.
         | 
         | Not too long after someone asked what sort of interesting
         | changes 64 bit will bring. And I've been keeping that question
         | in the back of my mind ever since.
         | 
         | Aliasing memory multiple times in order to do read or write
         | barriers and make GC much cheaper is a pretty good one. But
         | another one I know of is that one of the secrets of the L4
         | microkernel is that its IPC speed comes substantially from
         | reducing the amount of TLB work that needs to be done to switch
         | to another process running in a different address space. They
         | use the same address space and only swap out the access rights
         | which cuts the call overhead in half. It's pretty easy to put a
         | bunch of processes into a 64 bit address space and just throw
         | each one a randomly located 4GB slice of RAM.
        
           | twoodfin wrote:
           | Yeah, would love to see the CPU vendors invent some
           | primitives to let user code pull those kinds of privilege
           | isolation tricks within a single process and address space.
           | 
           | Something like: "From now on, code on these pages can only
           | access data on these pages, and only return to/call into
           | other code through these gates..."
        
             | hinkley wrote:
             | Thread based seems like it at least should be possible.
        
           | jdougan wrote:
           | Is that something like the memory protection scheme on the
           | Newton OS?
        
       | pron wrote:
       | For relevant upcoming changes see Automatic Heap Sizing for ZGC:
       | https://openjdk.org/jeps/8329758
        
       ___________________________________________________________________
       (page generated 2025-04-23 23:01 UTC)