----- Original Message -----
> From: "Tagir Valeev" <[email protected]>
> To: "Remi Forax" <[email protected]>
> Cc: "Brian Goetz" <[email protected]>, "Liam Miller-Cushon"
> <[email protected]>, "John Rose"
> <[email protected]>, "amber-spec-experts"
> <[email protected]>
> Sent: Mardi 3 Août 2021 06:52:45
> Subject: Re: [External] : Re: Minor improvement to anonymous classes
[...]
>
> By the way, are we speaking about anonymous classes only? I think,
> local classes could be updated in the similar manner.
yes, it's what Liam's patch does.
> 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?
For me, the behavior of local classes and anonymous classes should be aligned
as the patch of Liam does, and we should still allow static on local classes if
someone want to document that behavior in his code.
>
> Best regards,
> Tagir Valeev.
regards,
Rémi
>
> On Tue, Aug 3, 2021 at 2:47 AM <[email protected]> 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" <[email protected]>
>> > To: "Liam Miller-Cushon" <[email protected]>
>> > Cc: "Remi Forax" <[email protected]>, "John Rose" <[email protected]>,
>> > "amber-spec-experts"
>> > <[email protected]>
>> > 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.
