RFR(XS): 8163973: VM Anonymous classes should not call Class File Load Hooks
Rachel Protacio
rachel.protacio at oracle.com
Wed Aug 17 15:56:14 UTC 2016
Hi David and Coleen,
Thank you for the reviews. I've updated the change as requested:
http://cr.openjdk.java.net/~rprotacio/8163973.01/
Rachel
On 8/16/2016 10:04 PM, Coleen Phillimore wrote:
>
>
> On 8/15/16 11:36 PM, David Holmes wrote:
>> Hi Rachel,
>>
>> On 16/08/2016 6:48 AM, Rachel Protacio wrote:
>>> Hello,
>>>
>>> Please review this change, which makes sure class file load hooks are
>>> not called for VM anonymous classes. See
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/038353.html
>>>
>>> for justification.
>>>
>>> Passes JPRT and RBT.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163973
>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8163973.00/
>>
>> This:
>>
>> 112 // VM Anonymous classes - defined via
>> unsafe.DefineAnonymousClass - should not
>> 113 // call back to a CFLH
>> 114 if (host_klass == NULL) {
>> 115 stream = prologue(stream,
>>
>> suggests that "prologue" can only do CFLH related things. If that is
>> true then it would be much clearer in my opinion if prologue were
>> renamed to something more explicit - like check_class_file_load_hook
>> ? Otherwise, the host_klass should be passed in to prologue and the
>> anonymous class check internalized there.
>
> I agree with David here. This was sort of bothering me about your
> change when we talked about it before. If the prologue did more than
> call the CFLH then you'd have to pass host_klass down, since we know
> that's all it does, the name of the function should be changed.
> David's name looks good to me.
>>
>> Also I don't think you need to explain where VM anonymous classes
>> come from, it suffices to simply say "Skip class file load hook
>> processing for VM anonymous classes"; or if the prologue is renamed
>> then simply "Skip this processing for VM anonymous classes". :)
>
> Thanks,
> Coleen
>>
>> Thanks,
>> David
>>
>>> Thank you!
>>> Rachel
>
More information about the hotspot-runtime-dev
mailing list