RFR (XS): 8066497: Update c.o.j.t.ByteCodeLoader to be able really reload given class

[David Holmes]

On 19/12/2014 3:51 PM, Pavel Chistyakov wrote:
> Hi David,
>
> In case of ByteCodeLoader we'd prefer to load class w/ given name and exact given bytecode. Even if parent loader can load class w/ such name, in general this class can have different bytecode. To prevent this situation we break delegation for our class name.
>
> Also, if we want to use parent loader we can get its instance and load class using it directly.

I don't quite understand why this needs to be done this way so I'm 
backing out of it - neither reviewing nor opposing.

David
-----

> -----------
> Thanks,
> Pavel
>
>
> ----- Original Message -----
> From: david.holmes at oracle.com
> To: vladimir.kozlov at oracle.com, hotspot-dev at openjdk.java.net
> Cc: pavel.chistyakov at oracle.com
> Sent: Friday, December 12, 2014 2:13:03 PM GMT +04:00 Abu Dhabi / Muscat
> Subject: Re: RFR (XS): 8066497: Update c.o.j.t.ByteCodeLoader to be able really reload given class
>
> On 12/12/2014 8:04 AM, Vladimir Kozlov wrote:
>> Pavel,
>>
>> I am resending it to whole hotspot so you can get more help/explanations.
>>
>> Thanks,
>> Vladimir
>>
>> On 12/10/14 4:03 AM, Pavel Chistyakov wrote:
>>> Hi David,
>>>
>>> Thanks for review.
>>>
>>> The intent was:
>>>
>>>    * be able to get */new/* instance of Class w/ given name and given
>>> bytecode for every /*new*/ instance of
>>>      ByteCodeLoader even if this class was already loaded by parent
>>> loader. For this reason, I overrided loadClass to
>>>      break delegation to parent loader for given className;
>
> I question why the parent should be able to load the class that is being
> "redefined"? If it can't, then breaking delegation is not necessary. If
> it can and you break delegation then you may be able to load the other
> variants of the class in new classloader instances, but depending on
> what you then do with the class you may get loader constraint violations.
>
> David H.
>
>>>    * make single class definition for ByteCodeLoader instance. Here
>>> holder field appears and DCL for it's thread safe
>>>      initialization.
>>>
>>>
>>> -------------
>>> Pavel
>>>
>>> On 09.12.2014 23:49, David Chase wrote:
>>>> I agree with your changes to loadClass, but I am not sure that this
>>>> will allow you to redefine an existing class.  My understanding of
>>>> how this would work is that it will allow you re-obtain the class
>>>> that was already loaded (but not to fail at this).  Actually
>>>> redefining a class requires use of JVMTI (or so I think).
>>>>
>>>> Was that your intent?
>>>>
>>>> David
>>>>
>>>>
>>>> On 2014-12-09, at 11:50 AM, Pavel
>>>> Chistyakov<pavel.chistyakov at oracle.com>  wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> please review changes
>>>>> for:https://bugs.openjdk.java.net/browse/JDK-8066497
>>>>> webrev:http://cr.openjdk.java.net/~iignatyev/pchistyakov/8066497/webrev.00/
>>>>> <http://cr.openjdk.java.net/%7Eiignatyev/pchistyakov/8066497/webrev.00/>
>>>>>
>>>>>
>>>>> Problem:
>>>>> ByteCodeLoader allows one to load class with given name from
>>>>> existing bytecode. But if this class is already loaded by e.g.
>>>>> system classloader it cannot be redefined using another bytecode
>>>>> array because of delegation of loadClass call to parent classloader.
>>>>>
>>>>> Solution:
>>>>> override loadClass to break delegation for given className.
>>>>>
>>>>> Testing: manual
>>>>>
>>>>> -------------------
>>>>> Thanks,
>>>>> Pavel
>>>