yes, adding @Hidden solves the first item of my list, but nevertheless changing the behavior of defineAnonymousClass does not solve the other items.
That said, i hijack this thread because i have not noticed that defineAnonymousClass behavior was changed. I should have started another thread about that. Rémi Le 11 mai 2016 15:10:02 CEST, Vladimir Ivanov <vladimir.x.iva...@oracle.com> a écrit : >Let me clarify: both proposed patches move invoker class out of >java.lang.invoke package, but add @Hidden on invoke_V instead. > >So, JVM should not list it in stack traces and you don't have to filter > >it out on your side. > >Moreover, I think the absence of @Hidden on >j.l.i.MethodHandleImpl.T.invoke_V was an overlook. > >Best regards, >Vladimir Ivanov > >On 5/11/16 3:59 PM, fo...@univ-mlv.fr wrote: >> ----- 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
