#Boolean Java size
91 messages Β· Page 1 of 1 (latest)
<@&987246399047479336> please have a look, thanks.
Here is an AI assisted attempt to answer your question π€. Maybe it helps! In any case, a human is on the way π. To continue talking to the AI, you can use </chatgpt:1108714622413963314>.
In Java, the size of a boolean is not precisely defined by the language specification. The Java Language Specification states that a boolean represents one of two values: true or false, but it does not specify how many bits or bytes it occupies in memory.
Practically:
- A single
booleanvariable in Java typically occupies 1 byte when stored in an array or as a field in an object; this is due to memory alignment and addressing constraints of most JVM implementations. - However, the JVM may pack multiple booleans internally (e.g., in arrays) more efficiently.
- When it comes to object fields, a
booleanis often aligned to a byte boundary or more depending on the JVM. - For performance and memory layout reasons, booleans in objects often end up taking at least one byte.
If you need to optimize memory, using a BitSet or packing booleans into bits of an integer/byte array can be a good approach.
Useful links:
1 byte?
4 bytes
actualy
up to 32 bits
Why?
all types smaller than int are internally stored as integers
an exception is boolean[] which is backed more tightly
in boolean[]s they take up 1 byte each
So a short is internally stored as an integer too?
in some cases yes
it might be able to be packed into 16 bits in some cases, otherwise it takes up 32 bits
But when ?
if stored in a field it takes up 32 bits
as a local variable it iirc only takes up 16
bytes take up iirc 8 bits as a local variable, 32 bits as a field
I am wondering why takes up 32 bits as a field now π
iirc
every field takes up 32 bits
except for doubles and longs which take up 64 bits
It only has to take up 8, lots of places will make it take more for alignment or other stuff
But if it's a field in a value class or an element in an array it will take up just 8 bits/1 byte
Okay so do you know about alignment?
Yes
Okay so sometimes the JVM will use 32 bits for an 8 bit value. It happens
Either because it needs to do that for alignment
Padding?
Because it needs to do that in order to not think about alignment
Or because, at a certain level, byte isn't a real primitive
Like there are no bytecode instructions for byte math
It always expands to ints
But that generally doesn't matter much
Really what matters is "I have a billion booleans/bytes"
And how compact you can get away with making that
And the answer is always "as compact as the jvm can get away with, but you have no guarantees usually except for arrays"
I know I started talking about bytes there but I think it all applies to booleans too
So all the primitive types that are smaller than int takes up 32 bits when they re a field just because JVM?
I'm not sure about fields
Let's talk through reasons why that might be true today
Fields have concurrency guarantees. So if you set a field on one thread you should be able to observe that set on another thread given a set of conditions
And one problem with making a field only 8 bits is that usually that isn't atomically addressable by a CPU
That being said I don't think you need that property if it's a final field
Because you don't need to reason about changes after initial assignment
Except that right now final Fields aren't actually final
So it's possible that this addressability issue just can't be dodged right now
I genuinely don't know though
Where can I read more about these type of things? I am interested more
generally shipilev's jvm anatomy quarks is very interesting
going deep into internals
But the general rule of java is that you leave a lot of things to the VM. You can decide to be the kind of person who cares about what the VM does but the value proposition is that most people don't need to
and the answer about how it actually works is usually it depends
stuff like optimizations are optional and really up to the underlying jvm
VM is so scaryπ
It should be
the good thing is you dont have to care at all
Notice how many things I just said I don't know
There are very few people who know all this stuff
So we should say i dont care?π
To a certain extent yeah
I mean think about things that aren't memory consumption
When you run code is it fast or slow? Well it might be fast because you have three layers of compilers running on runtime profiler information
These compilers do things you will never understand
You can choose to dig into it, or you can choose to go "yeah that's fast enough" and pretend something rubbed fast grease on your code
Like I know about things like mega morphic call sites or inlining thresholds
And that information can help me
But I'll never fully understand the just in time compiler
It's not going to happen
they should make an ArrayList<Boolean> an dynamic bitset
Famously making vector<bool> a bit set is one of the dumbest things that C++ did
any details? not into c++ at all
ββ Awesome T-Shirts! Sponsors! Books! ββ
C++ Best Practices Workshops Near You:
Preview: https://youtu.be/Ipr6ntCAm9A
Sep 12-13 (Aurora, CO): https://cppcon.org/class-2026-best-practices/
Sep 21-22 (Kongsberg, NO): https://ndctechtown.com/tickets
Oct 14 (Breda, NL): https://cppunderthesea.nl/#workshops
A robust cross-platform IDE fo...
ββ Awesome T-Shirts! Sponsors! Books! ββ
C++ Best Practices Workshops Near You:
Preview: https://youtu.be/Ipr6ntCAm9A
Sep 12-13 (Aurora, CO): https://cppcon.org/class-2026-best-practices/
Sep 21-22 (Kongsberg, NO): https://ndctechtown.com/tickets
Oct 14 (Breda, NL): https://cppunderthesea.nl/#workshops
T-SHIRTS AVAILABLE!
βΊ The ...
The second one here is a better reference
yeah thanks
8 times less memory usage for having to use it differently, totally worth it
you know you can not get a reference to a bit, so do not try to, if you not know = skill issue
yeah dont really see how this is "one of the dumbest things" but I guess it would be worth to implement this optimisation separately from vector right?
yeah they could offer a dynamic_bitset so that std::vector behaves exactly the same for every datatype
Its partially just a cautionary tale about c++'s abi compatibility
unspecified, but usually either 1 byte or 4 bytes without counting padding