Multiple this$1 fields when mixing subclassing and inner classes

[David Holmes]

On 10/09/2019 8:46 am, Stefan Reich wrote:
> Hi David,
> 
> thanks for your answer.
> 
>  > 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.
> 
> I think this is not a counterargument. We just change an access to a 
> field this$1 of type B into
> an access to a field this$1 with type A followed by a cast to B. The 
> result will be the same in both cases, including the real and formal 
> type. Method invocation is not affected.

But you're not talking about bytecode here you're talking about inside 
the VM. If there is an invokespecial on this$1 of type A then the 
constant pool lookup of its type will be A and we will resolve the call 
based on A's methods. If it were of type B then the resolution process 
would be different. There's nowhere to "insert a cast" here.

BTW what introspection tool did you use to show this?

Cheers,
David

> Many greetings :)
> 
> 
> On Tue, 10 Sep 2019 at 00:39, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     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
>     <mailto: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
>      >>
>      >
>      >
> 
> 
> 
> -- 
> Stefan Reich
> BotCompany.de // Java-based operating systems