Multiple this$1 fields when mixing subclassing and inner classes

[David Holmes]

Hi Stefan,

On 10/09/2019 8:31 am, Stefan Reich wrote:
>> I'm curious as to where there has ever been deliberation of this?
> 
> Uh.. "whether", of course.

Glad you made that correction :) I would hazard a guess that it has 
never been deliberated. AFAIK the representation of fields in the JVM is 
a mechanical translation of what is in the classfile, with no attempt to 
be clever about aliasing. Even though they point to the same instance 
the different typed fields may still be needed to ensure correct method 
resolution for non-virtual invocations.

Cheers,
David

> On Tue, 10 Sep 2019 at 00:24, Stefan Reich <
> stefan.reich.maker.of.eye at googlemail.com> wrote:
> 
>> Consider these classes:
>>
>> class A {
>>    class InnerA {}
>> }
>> class B extends A {
>>    class InnerB extends InnerA {}
>> }
>>
>> When I run some introspection on B.InnerB, I find HotSpot producing this
>> object layout:
>>
>> Size of object B$InnerB: 24 bytes
>>    Field A$InnerA . this$1 is at offset 12
>>    Field B$InnerB . this$1 is at offset 16
>>
>> So the object has *two* outer references, one of type A and one of type B.
>>
>> That is all fair and good, but: These two references *will always point
>> to the same object*. This follows from the syntactic rules on the Java
>> level. (<< Crucial part of the argument, so - is this correct?)
>>
>> So, the question is: Wouldn't it save some RAM to just have one "this$1"
>> field?
>>
>> The only downside would be that accesses to this$1 from code inside InnerB
>> would require a cast, as the remaining this$1 field would formally only
>> have type A.
>>
>> I'm curious as to where there has ever been deliberation of this?
>>
>> Best regards,
>> Stefan
>>
>> --
>> Stefan Reich
>> BotCompany.de // Java-based operating systems
>>
> 
>