> From: "-" <liangchenb...@gmail.com> > To: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Chen Liang" <li...@openjdk.org>, "core-libs-dev" > <core-libs-dev@openjdk.org>, "hotspot-dev" <hotspot-...@openjdk.org>, > "kulla-dev" <kulla-...@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:fo...@univ-mlv.fr | > fo...@univ-mlv.fr ] > wrote: >> ----- Original Message ----- >> > From: "Chen Liang" < [ mailto:li...@openjdk.org | li...@openjdk.org ] > >>> To: "core-libs-dev" < [ mailto:core-libs-dev@openjdk.org | >>> core-libs-dev@openjdk.org ] >, "hotspot-dev" < [ >>> mailto:hotspot-...@openjdk.org >>> | hotspot-...@openjdk.org ] >, [ mailto:kulla-...@openjdk.org | >> > kulla-...@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:li...@openjdk.org | >> > li...@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 ]
