Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass()
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 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" >>> À: "Remi Forax" , "shilpi rastogi" > >>> Cc: core-libs-...@openjdk.java.net, "John Rose" >, "Michael Haupt" , >>> "paul sandoz" , "Da Vinci Machine Project" > >>> 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" >>>>> À: core-libs-...@openjdk.java.net, "John Rose" >, >>>>> "Michael Haupt" , >>>>> "paul sandoz" , "Vladimir Ivanov" >>>>> >>>>> 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
Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass()
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" À: "Remi Forax" , "shilpi rastogi" Cc: core-libs-...@openjdk.java.net, "John Rose" , "Michael Haupt" , "paul sandoz" , "Da Vinci Machine Project" 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" À: core-libs-...@openjdk.java.net, "John Rose" , "Michael Haupt" , "paul sandoz" , "Vladimir Ivanov" 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
Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass()
- Mail original - > De: "Vladimir Ivanov" > À: "Remi Forax" , "shilpi rastogi" > > Cc: core-libs-...@openjdk.java.net, "John Rose" , > "Michael Haupt" , > "paul sandoz" , "Da Vinci Machine Project" > > 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" > >> À: core-libs-...@openjdk.java.net, "John Rose" , > >> "Michael Haupt" , > >> "paul sandoz" , "Vladimir Ivanov" > >> > >> 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
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 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" À: core-libs-...@openjdk.java.net, "John Rose" , "Michael Haupt" , "paul sandoz" , "Vladimir Ivanov" 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
Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass()
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" > À: core-libs-...@openjdk.java.net, "John Rose" , > "Michael Haupt" , > "paul sandoz" , "Vladimir Ivanov" > > 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
