Review Request: 7088913/7088952 : Additions to primitive wrappers
david.holmes at oracle.com
Thu Sep 22 03:04:23 PDT 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.
> 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 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
> 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:
More information about the core-libs-dev