[External] : Re: Minor improvement to anonymous classes

[Brian Goetz]

Yes, local classes too.  Essentially, this is for translation of 
"effectively static" inner classes.

I think this is independent of explicit-static or not; explicit-static 
allows the programmer to capture intent and get more type checking as a 
result.  This is about generating better code.

On 8/3/2021 12:52 AM, Tagir Valeev wrote:
> Another possible semantics change is the object lifetime. The code
> might rely on prolonged lifetime of the surrounding object if there
> are soft/weak/phantom references. E.g., the outer object might be
> registered via Cleaner, and the change may cause freeing the resource
> earlier than expected. Likely, this is a very rare scenario but if it
> happens, it could be quite hard to identify the root cause, as the
> problem will appear only if the object is collected within the
> specific timeframe.
>
> By the way, are we speaking about anonymous classes only? I think,
> local classes could be updated in the similar manner. Especially given
> the fact that now local records don't capture the surrounding "this"
> but if we convert the record to an equivalent local class, it will
> capture:
>
> public class Test {
>    void test() {
>      record R() {} // does not capture Test instance
>      class C {} // captures Test instance
>    }
> }
>
> Or should we allow explicit 'static' modifier on local classes?
>
> Best regards,
> Tagir Valeev.
>
> On Tue, Aug 3, 2021 at 2:47 AM <forax at univ-mlv.fr> wrote:
>> We may have some trouble with the usual suspect, Serialization,
>> There are classes like exceptions or Swing UI classes that are marked as Serializable and can be implemented as an anonymous class.
>> In that case, removing the backpointer if it is not used may change the serialization format.
>>
>> And yes, an anonymous class do not have a "stable" name but people do not seem to care too much about that ...
>>
>> Rémi
>>
>> ----- Original Message -----
>>> From: "Brian Goetz" <brian.goetz at oracle.com>
>>> To: "Liam Miller-Cushon" <cushon at google.com>
>>> Cc: "Remi Forax" <forax at univ-mlv.fr>, "John Rose" <john.r.rose at oracle.com>, "amber-spec-experts"
>>> <amber-spec-experts at openjdk.java.net>
>>> Sent: Lundi 2 Août 2021 20:18:56
>>> Subject: Re: [External] : Re: Minor improvement to anonymous classes
>>> FWIW, making this fix not only reduces the memory leak risk, but has a
>>> number of nice follow-on benefits that can often trigger further
>>> follow-on benefits:
>>>
>>>   - fewer fields, so reduced footprint;
>>>   - fewer fields might mean more objects fall under the scalarization
>>> threshold, when applicable;
>>>   - less work in constructors;
>>>   - shorter constructors mean more constructors fall under the inlining
>>> threshold;
>>>   - more inlining might lead to other optimizations.
>>>
>>> So it wouldn't surprise me to see macro-level effects even on programs
>>> without memory leaks.
>>>
>>>> I filed https://bugs.openjdk.java.net/browse/JDK-8271623
>>>> <https://bugs.openjdk.java.net/browse/JDK-8271623> to track that
>>>> enhancement.