Memory Usage in Java

[Remi Forax]

----- Original Message -----
> From: "Florian Weimer" <fweimer at redhat.com>
> To: "Dallman, John" <john.dallman at siemens.com>
> Cc: "Shipilev, Aleksey" <shipilev at amazon.de>, "Kenneth Fogel" <kfogel at dawsoncollege.qc.ca>, "discuss"
> <discuss at openjdk.org>
> Sent: Saturday, August 9, 2025 8:12:53 PM
> Subject: Re: Memory Usage in Java

> * John Dallman:
> 
>> On any remotely modern processor architecture, ten byte-sized
>> variables will only occupy ten bytes of space. The way they get
>> fetched into the processor is somewhat complicated but ensures that
>> several of them will normally be fetched in one read.
> 
> That's not true for local variables, though.  I don't know if Hotspot
> has a clear preference, but other compilers tend not to use byte-level
> access for local variables.  The reasons vary.  Register pair or
> multi-register stores and loads are usually not available at the byte
> level, and the instruction encoding for byte accesses might be less
> compact.

Yes,

Java is weird because you have this mixed execution, part of the code is executed by the interpreter, part of the code is JITed to assembly code.

In the interpreter, the local variables are 32 bits values (or a pair of 32 bits values for long and double), this is how the bytecode works.
In fact, it's even weirder because the bytecode has no concept of local variable declaration, a variable is "created" when the interpreter execute a store at an index (the size of all the local variables of a method is in the .class format).

For the JITed code, local variables are not stored on the stack but inside CPU registers, apart if there are not enough registers but this is quite rare with usual 64 bits CPUs.

So in both cases, local variable values are represented as 32/64 bits.

> 
> Thanks,
> Florian

regards,
Rémi