Review Request: 7088913/7088952 : Additions to primitive wrappers

David Holmes david.holmes at oracle.com
Thu Sep 22 10:04:23 UTC 2011


On 22/09/2011 7:40 PM, Ulf Zibis wrote:
> Yep, not easy to make a right decision here.
>
> One if the questions might be, if SIZE/BYTES are meant as resolution
> (2**SIZE = number of distinct values) or as memory usage.
> I would say: SIZE should be meant as resolution, but BYTES as memory
> usage. This would add additional value to the new introduced constant.
> So:
> Boolean.SIZE = 1
> Boolean.BYTES = 4 (8 for 64-bit build)

I can support the SIZE == resolution position.

But BYTES can't mean "memory usage" as that is totally VM dependent and 
also has platform dependencies, and is not a constant as such due to the 
way different fields can be packed together.

The constants are Java language constants, not VM related, so I think 
that both SIZE and BYTES have to be resolution. Which still means to me 
that for boolean BYTES is ambiguous enough to be worth leaving out.

>> ... At the VM level they map to ints.
> This is not always true. Arrays of byte are mapped to byte[] in VM. For
> boolean, it's theoretically possible to map a boolean[32] to one int.

According to the VM spec booleans map to ints (Ref 3.11.1). But the VM's 
native representation could use bit-fields for booleans.

>> For that matter I'm not sure the addition of BYTES is worth the effort.
> Yes or not, I'm unsure. My first feeling was, there _must_ be some
> additional APIs to justify the change to a new release, here 8. ;-)

I'm tempted to make a tongue-in-cheek comment about adding lambdas, but 
I'll resist the temptation ;-)

> But I think, it's reasonable to have a short cut when calculating the
> footprint of some data, instead repeating SIZE/Bytes.SIZE in code.

But given that you can't calculate "footprint" this way the point seems 
somewhat moot.

Cheers,
David


hat
> said, there should be a clear definition, if BYTES is meant as
> VM-memory-footprint or persistent-storage-footprint e.g. by
> serialization, or we should have three:
> MEM_BYTES
> ARRAY_MEM_BYTES
> SERIALIZATION_BYTES



> -Ulf
>
>



More information about the core-libs-dev mailing list