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

Pavel Chistyakov pavel.chistyakov at oracle.com
Fri Dec 19 05:51:52 UTC 2014


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.

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


More information about the hotspot-compiler-dev mailing list