RFR: 8242888: Convert dynamic proxy to hidden classes

[forax at univ-mlv.fr]

> From: "-" <liangchenblue at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Chen Liang" <liach at openjdk.org>, "core-libs-dev"
> <core-libs-dev at openjdk.org>, "hotspot-dev" <hotspot-dev at openjdk.org>,
> "kulla-dev" <kulla-dev at openjdk.org>
> Sent: Thursday, May 23, 2024 2:56:58 PM
> Subject: Re: RFR: 8242888: Convert dynamic proxy to hidden classes

> Hmm, I think Proxy being hidden in stacktraces might be an advantage; the same
> happens for lambdas.
> The main advantage of hidden classes compared to an explicit class with
> classData is that it supports flexible unloading, which might be useful for
> Proxy.

Flexible unloading has a high cost in term of memory, the class + methods, etc need their own metaspace. 
While on paper it seems great, I've my doubt that it's a good idea to use that option for proxies given that the Proxy API allows an umbounded number of proxy classes. 
That's why lambda proxies does not use the flexible unloading anymore. 

> I still believe the flexible unloading advantage justifies the migration to
> hidden classes.

> Chen

Rémi 

> On Thu, May 23, 2024 at 6:43 AM Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> ----- Original Message -----
>> > From: "Chen Liang" < [ mailto:liach at openjdk.org | liach at openjdk.org ] >
>>> To: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.org |
>>> core-libs-dev at openjdk.org ] >, "hotspot-dev" < [ mailto:hotspot-dev at openjdk.org
>>> | hotspot-dev at openjdk.org ] >, [ mailto:kulla-dev at openjdk.org |
>> > kulla-dev at openjdk.org ]
>> > Sent: Thursday, May 23, 2024 1:28:01 PM
>> > Subject: Re: RFR: 8242888: Convert dynamic proxy to hidden classes

>>> On Thu, 23 May 2024 03:28:30 GMT, Chen Liang < [ mailto:liach at openjdk.org |
>> > liach at openjdk.org ] > wrote:

>> >> Please review this change that convert dynamic proxies implementations to hidden
>> >> classes, intended to target JDK 24.

>> >> Summary:
>> >> 1. Adds new implementation while preserving the old implementation behind
>> >> `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
>> >> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in
>> >> native code; I updated native code to reuse that ClassLoader for Proxy support.
>> >> 3. ProxyGenerator changes mainly involve using Class data to pass Method list
>> >> (accessed in a single condy) and removal of obsolete setup code generation.

>> >> Testing: tier1 and tier2 have no related failures.

>> >> Comment: Since #8278, Proxy has been converted to ClassFile API, and
>> >> infrastructure has changed; now, the migration to hidden classes is much
>> >> cleaner and has less impact, such as preserving ProtectionDomain and dynamic
>> >> module without "anchor classes", and avoiding java.lang.invoke package.

>> > A CSR targeting 24 describing the compatibility concerns and behavioral
>> > differences is here, somehow not linked by skara:
>>> [ https://bugs.openjdk.org/browse/JDK-8332770 |
>> > https://bugs.openjdk.org/browse/JDK-8332770 ]
>> > The incompatibilities were much greater in the previous iterations of this
>> > issue, such as in dynamic modules, serialization, and in proxy class protection
>> > domain. Now these aspects are addressed by this patch, the only real one left
>> > is the change in stack trace. Feel free to raise other incompatibilities you
>> > have discovered.

>> I wonder if instead of using hidden classes, we should not use usual named
>> classes and add a new Lookup.defineClass() that takes a classData as parameter.
>> This will solve the both the problem of the stacktrace and the problem of the
>> roundtrip proxyClass != Class.forName(proxyClass.getName()).

>> Rémi


>> > -------------

>>> PR Comment: [ https://git.openjdk.org/jdk/pull/19356#issuecomment-2126869679 |
>> > https://git.openjdk.org/jdk/pull/19356#issuecomment-2126869679 ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240523/926a8572/attachment.htm>