Multiple this$1 fields when mixing subclassing and inner classes

[David Holmes]

On 11/09/2019 10:43 pm, Stefan Reich wrote:
> Oh, because it doesn't affect the Java source level, right? Got it. Thanks

No, because it's not related to defining a specific platform 
specification - which is what JSRs are for. These days everything in 
OpenJDK is developed within the community, with larger projects handled 
within a JEP. Then ultimately there is, I believe, a JSR (or JSR update) 
for each actual release.

David

> On Wed, 11 Sep 2019 at 14:42, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     On 11/09/2019 10:30 pm, Stefan Reich wrote:
>      > I'm thinking about becoming a JCP member to turn this idea (merging
>      > this$x fields) into a JSR.
> 
>     This doesn't require a JSR, nor do you need to become a JCP member.
> 
>     This is just an enhancement request for the hotspot implementation
>     (assuming it is actually valid, viable and worthwhile).
> 
>     To work on this all you need to do is become an OpenJDK contributor:
> 
>     http://openjdk.java.net/contribute/
> 
>     If the issue is large enough then it may warrant a Java Enhancement
>     Proposal (JEP):
> 
>     https://openjdk.java.net/jeps/1
> 
>     David
>     -----
> 
>      > The JCP paperwork seems scary though, and I don't speak their
>      > programming language (legalese) enough to really get what is
>     demanded...
>      > https://jcp.org/aboutJava/communityprocess/JSPA2.pdf
>      >
>      > It seems I could become a JCP member as an individual without
>     having to
>      > pay a fee. Not sure what all the "IP" fuss is about. "Are you
>     willing
>      > and able to sign the JSPA and license IP"? License MY IP to
>     Oracle? Or
>      > the other way around? Who can help me out there?
>      >
>      > Greetings
>      >
>      > On Tue, 10 Sep 2019 at 01:30, Stefan Reich
>      > <stefan.reich.maker.of.eye at googlemail.com
>     <mailto:stefan.reich.maker.of.eye at googlemail.com>
>      > <mailto:stefan.reich.maker.of.eye at googlemail.com
>     <mailto:stefan.reich.maker.of.eye at googlemail.com>>> wrote:
>      >
>      >     Oh, I didn't know about those JDK 11 changes. That may in
>     fact break
>      >     the idea of merging the references. I'm sure it can still be
>     done,
>      >     but might require a spec change. And who's gonna pay for that?
>      >
>      >     :-D
>      >
>      >     Thanks
>      >
>      >     On Tue, 10 Sep 2019 at 01:17, David Holmes
>     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>      >     <mailto:david.holmes at oracle.com
>     <mailto:david.holmes at oracle.com>>> wrote:
>      >
>      >         On 10/09/2019 9:09 am, Stefan Reich wrote:
>      >          >     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.
>      >          >
>      >          >
>      >          > Can invokespecials on this$0/this$1 happen? I'm
>     struggling to
>      >         imagine a
>      >          > case for this.
>      >          >
>      >          > invokespecial invokes private instance methods, superclass
>      >         methods or
>      >          > constructors. Superclass methods don't apply, neither do
>      >         constructors.
>      >          > And calls to private methods happen through bridges (just
>      >         verified this
>      >          > for myself again :):
>      >          >
>      >          >        13: aload_0
>      >          >        14: getfield      #1                  // Field
>      >         this$0:Lbla;
>      >          >        17: invokestatic  #4                  // Method
>      >          > bla.access$000:(Lbla;)V
>      >          >
>      >          > So what remains?
>      >
>      >         This changed in JDK 11 with the addition of nestmates.
>     Now inner
>      >         classes
>      >         have direct private access, no bridges needed, and we use
>      >         invokespecial
>      >         or invokevirtual as appropriate. For private methods
>      >         invokevirtual is
>      >         mainly used now, but of course we don't do virtual dispatch -
>      >         there are
>      >         special rules for private method resolution and selection.
>      >
>      >         class A {
>      >             void m() {}
>      >             class InnerA {
>      >               void callM() { m(); }
>      >             }
>      >         }
>      >
>      >            void callM();
>      >               descriptor: ()V
>      >               flags: (0x0000)
>      >               Code:
>      >                 stack=1, locals=1, args_size=1
>      >                    0: aload_0
>      >                    1: getfield      #1                  // Field
>     this$0:LA;
>      >                    4: invokevirtual #13                 // Method
>     A.m:()V
>      >                    7: return
>      >                 LineNumberTable:
>      >                   line 4: 0
>      >
>      >          >     BTW what introspection tool did you use to show this?
>      >          >
>      >          > My own tools ("JavaX")... here's the example program:
>      >          > http://code.botcompany.de/1025166
>      >
>      >         Thanks for the pointer.
>      >
>      >         Cheers,
>      >         David
>      >
>      >          > Many greetings :)
>      >
>      >
>      >
>      >     --
>      >     Stefan Reich
>      >     BotCompany.de // Java-based operating systems
>      >
>      >
>      >
>      > --
>      > Stefan Reich
>      > BotCompany.de // Java-based operating systems
> 
> 
> 
> -- 
> Stefan Reich
> BotCompany.de // Java-based operating systems