Memory Usage in Java
Remi Forax
forax at univ-mlv.fr
Fri Aug 8 18:09:21 UTC 2025
----- Original Message -----
> From: "Alex Buckley" <alex.buckley at oracle.com>
> To: "discuss" <discuss at openjdk.org>
> Sent: Friday, August 8, 2025 7:30:26 PM
> Subject: Re: Memory Usage in Java
> On 8/8/2025 9:47 AM, Remi Forax wrote:
>> C (and Java) tricks you to think that a "short" has a single
>> representation but this is not true,
>> it has two representations, one on stack (local variables) and one on
>> heap (fields and array elements).
> ...
>> That's why in Java, the result of the addition of two shorts is an int,
>> short s = ...
>> short s2 = ...
>> s + s2. // this is an int
>
> The reason why the result of adding two shorts is an int is _because the
> JLS says so_. The physical representation of short values on the stack
> and on the heap -- whether in 1995 or 2025 -- is immaterial to the
> strongly typed result of a numeric operator.
>
> You could ask _why_ the JLS promotes each short to int before performing
> the addition, then adds two ints producing an int. The answer is that
> preferring to operate on 32-bit values made sense in 1995 and is still
> acceptable today.
But why it makes sense in 1995 (or today) to do that ?
It makes sense because on the runtime side you have to do a conversion, if there is no integer promotion, the runtime has to convert the resulting 32bits integer back to a 16bits integer.
So to nudge users on the right path, to make the performance model more explicit, the JLS explains to users how the sausages are made, i.e. that the runtime has to do an integer promotion when you want to do arithmetic operation of a 16bits value.
>
> Alex
Rémi
More information about the discuss
mailing list