Memory Usage in Java

Thomas Stüfe thomas.stuefe at gmail.com
Mon Aug 11 05:25:59 UTC 2025


Adding to what Aleksey wrote...

On Fri, Aug 8, 2025 at 6:10 PM Kenneth Fogel <kfogel at dawsoncollege.qc.ca>
wrote:

> Please let me know where I might ask this question or find the answer if
> this is not the right place.
>
>
>
> In a book I am working on I am writing about how Java deals with memory
> allocation for the primitive types on a 64 bit CPU. I know the size of
> primitive variable types such as byte is 1, int is 4, etc. and that the
> size is related to the range of allowable values. From my C/C++ days I
> learned that the actual amount of RAM used was related to the word size of
> a CPU so that when a byte is read you are really reading a word. This meant
> to me that if I had 10 variables of type byte, not in an array, it would
> consume 80 bytes of RAM.
>

This would not be the case on C/C++ either. Any allocator that uses 8 bytes
for a single byte would be terrible.

On C++, 10 stack variables of type byte, sitting right alongside each
other, would still consume 10 bytes, unless you interleave them with other
variables that come with different alignment requirements. If you place
them on the heap with new or malloc as individual items, you would use more
memory, but that overhead depends on the libc allocator implementation.
Small allocations like this are typically placed into
segregated-fits-lists, which may or may not impose an overhead depending on
the train the allocation is placed into. But that has nothing to do with
the width of the memory access of the CPU.

Cheers, Thomas

>From my reading it appears to be the same in Java except for arrays. Is
> this accurate? For example, an int is 4 bytes but when Java runs on a 64
> bit CPU is it really reading and writing 8 bytes? If it is, can we say that
> the 4 bytes of padding is RAM dead space that cannot be used for anything
> else?
>
>
>
> Thank you for your time,
>
>
>
> Ken Fogel
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/discuss/attachments/20250811/f81b158e/attachment-0001.htm>


More information about the discuss mailing list