#Boolean Java size

91 messages Β· Page 1 of 1 (latest)

rocky magnet
#

Hi ! How much space does a boolean take up?

arctic pulsarBOT
#

<@&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>.

#
TJ-Bot
Hi ! How much space does a boolean take up?

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 boolean variable 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 boolean is 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:

rocky magnet
#

1 byte?

swift coral
#

actualy

#

up to 32 bits

rocky magnet
#

Why?

swift coral
#

an exception is boolean[] which is backed more tightly

#

in boolean[]s they take up 1 byte each

rocky magnet
#

So a short is internally stored as an integer too?

swift coral
#

it might be able to be packed into 16 bits in some cases, otherwise it takes up 32 bits

rocky magnet
#

But when ?

swift coral
#

if stored in a field it takes up 32 bits

#

as a local variable it iirc only takes up 16

rocky magnet
#

And a byte too?

#

If is a field takes up 32 bits?

#

Very interesting

swift coral
#

bytes take up iirc 8 bits as a local variable, 32 bits as a field

rocky magnet
#

I am wondering why takes up 32 bits as a field now πŸ˜‚

swift coral
#

iirc

#

every field takes up 32 bits

#

except for doubles and longs which take up 64 bits

west pilot
#

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

rocky magnet
#

So if it is a field takes up 8 bits not 32?

#

I am a bit confused

west pilot
#

Okay so do you know about alignment?

rocky magnet
#

Yes

west pilot
#

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

rocky magnet
#

Padding?

west pilot
#

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

rocky magnet
#

So all the primitive types that are smaller than int takes up 32 bits when they re a field just because JVM?

west pilot
#

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

rocky magnet
#

Where can I read more about these type of things? I am interested more

west pilot
#

The first blog link I think is a good one

#

Shipilev writes interesting stuff

fiery bronze
#

generally shipilev's jvm anatomy quarks is very interesting

#

going deep into internals

west pilot
#

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

fiery bronze
#

and the answer about how it actually works is usually it depends

#

stuff like optimizations are optional and really up to the underlying jvm

rocky magnet
#

VM is so scaryπŸ˜‚

west pilot
#

It should be

fiery bronze
#

the good thing is you dont have to care at all

west pilot
#

Notice how many things I just said I don't know

#

There are very few people who know all this stuff

rocky magnet
#

So we should say i dont care?πŸ˜‚

west pilot
#

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

stark sluice
#

they should make an ArrayList<Boolean> an dynamic bitset

west pilot
#

Famously making vector<bool> a bit set is one of the dumbest things that C++ did

fiery bronze
#

any details? not into c++ at all

west pilot
#

☟☟ 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...

β–Ά Play video
#

☟☟ 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 ...

β–Ά Play video
#

The second one here is a better reference

fiery bronze
#

yeah thanks

stark sluice
#

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

fiery bronze
#

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?

stark sluice
#

yeah they could offer a dynamic_bitset so that std::vector behaves exactly the same for every datatype

west pilot
manic smelt