----- Mail original ----- > De: "Vladimir Ivanov" <vladimir.x.iva...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr>, "shilpi rastogi" > <shilpi.rast...@oracle.com> > Cc: core-libs-...@openjdk.java.net, "John Rose" <john.r.r...@oracle.com>, > "Michael Haupt" <michael.ha...@oracle.com>, > "paul sandoz" <paul.san...@oracle.com>, "Da Vinci Machine Project" > <mlvm-dev@openjdk.java.net> > Envoyé: Mercredi 11 Mai 2016 14:50:25 > Objet: Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of > Unsafe.defineAnonymousClass() > > Remi, I'm curious why doesn't @Hidden on the invoker method solve your > problem? > > Best regards, > Vladimir Ivanov
Hi Vladimir, as far as i know @Hidden only work on the stackframe that correspond to a method marked with @Hidden, not for the stackframe on top of the stackframe marked. So having the invoker marked with @Hidden is not enough, but maybe i'm wrong. Rémi > > On 5/11/16 3:44 PM, Remi Forax wrote: > > Hi all, > > changing the behavior of defineAnonymousClass in 9 is huge burden for me > > and i believe for anybody that maintains a dynamic language runtime. > > > > As an implementer, being able to choose the package of an anonymous class > > is an important feature. > > I use to choose carefully the package name for: > > - filtering the stack trace element that will be shown or not to the user. > > This patch specifically broke the stack trace that my runtime will emit > > because it removes "java.lang.invoke". > > I'm not the only one to filter out stacktrace element that starts with > > "java.lang.invoke", Nashorn or JRuby do that too. > > I can modify the code to use the new StackWalking API if all the method > > handle form artifact are marked with an interface or something like > > this. > > > > - generate proxy in an existing package > > see https://github.com/forax/proxy2 > > > > - generate code specialization (specialization of an existing method for > > some primitive types) of an existing class in an existing package > > (for the specialization, i specialize the constant pool at runtime so i > > have no choice but to use defineAnonymousClass). > > > > > > I understand that being able to generate a class in any package do not work > > well with the jigsaw view of the world but that's why defineAnonymousClass > > is in Unsafe after all. > > > > regards, > > Rémi > > > > ----- Mail original ----- > >> De: "shilpi rastogi" <shilpi.rast...@oracle.com> > >> À: core-libs-...@openjdk.java.net, "John Rose" <john.r.r...@oracle.com>, > >> "Michael Haupt" <michael.ha...@oracle.com>, > >> "paul sandoz" <paul.san...@oracle.com>, "Vladimir Ivanov" > >> <vladimir.x.iva...@oracle.com> > >> Envoyé: Mercredi 11 Mai 2016 13:24:09 > >> Objet: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of > >> Unsafe.defineAnonymousClass() > >> > >> Hi All, > >> > >> Please review the following- > >> > >> https://bugs.openjdk.java.net/browse/JDK-8149574 > >> > >> Solution: Changed anonymous class package name with the package name of > >> its host class. > >> > >> Two approaches to solve this- > >> 1. Parse .class and get the class name index form constant pool and > >> patch it with new name > >> http://cr.openjdk.java.net/~srastogi/8149574/webrev.05/ > >> > >> 2. Create class with new name (With ASM) > >> http://cr.openjdk.java.net/~srastogi/8149574/webrev.06/ > >> > >> Which approach is better? > >> > >> Thanks, > >> Shilpi > >> > >> > >> > >> > _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
