
<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"-" <liangchenblue@gmail.com><br><b>To: </b>"Remi Forax" <forax@univ-mlv.fr><br><b>Cc: </b>"Chen Liang" <liach@openjdk.org>, "core-libs-dev" <core-libs-dev@openjdk.org>, "hotspot-dev" <hotspot-dev@openjdk.org>, "kulla-dev" <kulla-dev@openjdk.org><br><b>Sent: </b>Thursday, May 23, 2024 2:56:58 PM<br><b>Subject: </b>Re: RFR: 8242888: Convert dynamic proxy to hidden classes<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr">Hmm, I think Proxy being hidden in stacktraces might be an advantage; the same happens for lambdas.<div>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.</div></div></blockquote><div><br></div><div>Flexible unloading has a high cost in term of memory, the class + methods, etc need their own metaspace.</div><div>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.<br data-mce-bogus="1"></div><div>That's why lambda proxies does not use the flexible unloading anymore.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div>I still believe the flexible unloading advantage justifies the migration to hidden classes.</div><br><div>Chen</div></div></blockquote><div><br data-mce-bogus="1"></div><div>Rémi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 23, 2024 at 6:43 AM Remi Forax <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">----- Original Message -----<br>

> From: "Chen Liang" <<a href="mailto:liach@openjdk.org" target="_blank">liach@openjdk.org</a>><br>

> To: "core-libs-dev" <<a href="mailto:core-libs-dev@openjdk.org" target="_blank">core-libs-dev@openjdk.org</a>>, "hotspot-dev" <<a href="mailto:hotspot-dev@openjdk.org" target="_blank">hotspot-dev@openjdk.org</a>>, <a href="mailto:kulla-dev@openjdk.org" target="_blank">kulla-dev@openjdk.org</a><br>

> Sent: Thursday, May 23, 2024 1:28:01 PM<br>

> Subject: Re: RFR: 8242888: Convert dynamic proxy to hidden classes<br>

<br>

> On Thu, 23 May 2024 03:28:30 GMT, Chen Liang <<a href="mailto:liach@openjdk.org" target="_blank">liach@openjdk.org</a>> wrote:<br>

> <br>

>> Please review this change that convert dynamic proxies implementations to hidden<br>

>> classes, intended to target JDK 24.<br>

>> <br>

>> Summary:<br>

>> 1. Adds new implementation while preserving the old implementation behind<br>

>> `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.<br>

>> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in<br>

>> native code; I updated native code to reuse that ClassLoader for Proxy support.<br>

>> 3. ProxyGenerator changes mainly involve using Class data to pass Method list<br>

>> (accessed in a single condy) and removal of obsolete setup code generation.<br>

>> <br>

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

>> <br>

>> Comment: Since #8278, Proxy has been converted to ClassFile API, and<br>

>> infrastructure has changed; now, the migration to hidden classes is much<br>

>> cleaner and has less impact, such as preserving ProtectionDomain and dynamic<br>

>> module without "anchor classes", and avoiding java.lang.invoke package.<br>

> <br>

> A CSR targeting 24 describing the compatibility concerns and behavioral<br>

> differences is here, somehow not linked by skara:<br>

> <a href="https://bugs.openjdk.org/browse/JDK-8332770" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8332770</a><br>

> The incompatibilities were much greater in the previous iterations of this<br>

> issue, such as in dynamic modules, serialization, and in proxy class protection<br>

> domain. Now these aspects are addressed by this patch, the only real one left<br>

> is the change in stack trace. Feel free to raise other incompatibilities you<br>

> have discovered.<br>

<br>

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.<br>

This will solve the both the problem of the stacktrace and the problem of the roundtrip proxyClass != Class.forName(proxyClass.getName()).<br>

<br>

Rémi<br>

<br>

> <br>

> -------------<br>

> <br>

> PR Comment: <a href="https://git.openjdk.org/jdk/pull/19356#issuecomment-2126869679" rel="noreferrer" target="_blank">https://git.openjdk.org/jdk/pull/19356#issuecomment-2126869679</a><br>

</blockquote></div><br></blockquote></div></div></body></html>