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

[Vladimir Ivanov]

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