RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass()

[Rémi Forax]

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.ivanov at 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, forax at univ-mlv.fr wrote:
>> ----- Mail original -----
>>> De: "Vladimir Ivanov" <vladimir.x.ivanov at oracle.com>
>>> À: "Remi Forax" <forax at univ-mlv.fr>, "shilpi rastogi"
><shilpi.rastogi at oracle.com>
>>> Cc: core-libs-dev at openjdk.java.net, "John Rose"
><john.r.rose at oracle.com>, "Michael Haupt" <michael.haupt at oracle.com>,
>>> "paul sandoz" <paul.sandoz at oracle.com>, "Da Vinci Machine Project"
><mlvm-dev at 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.rastogi at oracle.com>
>>>>> À: core-libs-dev at openjdk.java.net, "John Rose"
><john.r.rose at oracle.com>,
>>>>> "Michael Haupt" <michael.haupt at oracle.com>,
>>>>> "paul sandoz" <paul.sandoz at oracle.com>, "Vladimir Ivanov"
>>>>> <vladimir.x.ivanov at 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>