[10] RFC: Relaxing access restrictions for VM annotations
Vladimir Ivanov
vladimir.x.ivanov at oracle.com
Wed Feb 22 22:47:17 UTC 2017
> I do not know about the VM side, but you do not have to load the annotation to do the accessibility check,
> from the annotation name you can find the package and from the package you can find the module,
> so you do not have to delay until the class is loaded to find its module (if i've understand your issue).
Yes, that's what I did in webrev.01 [1]. The downsides are:
(1) it uses info from the class file which haven't been validated yet;
(2) some sensitive code is duplicated.
That's why I'm uncomfortable with that approach.
There's no problem with getting to the class representing the
annotation. The problem is with the class which _uses_ that annotation
and it is being loaded when decisions are made. E.g., @Contended affects
instance layout of the class being loaded and its effects should be
applied before the loading is finished.
Best regards,
Vladimir Ivanov
[1] http://cr.openjdk.java.net/~vlivanov/vm_annotations/webrev.01/
ClassFileParser::precompute_package_and_module() &
ClassFileParser::is_annotation_accessible()
> ----- Mail original -----
>> De: "Vladimir Ivanov" <vladimir.x.ivanov at oracle.com>
>> À: "hotspot-dev at openjdk.java.net developers" <hotspot-dev at openjdk.java.net>
>> Envoyé: Mardi 21 Février 2017 15:36:26
>> Objet: [10] RFC: Relaxing access restrictions for VM annotations
>
>> FYI I've been experimenting with relaxing restrictions on VM annotations
>> - Java annotations which affect how VM work - @ReservedStackAccess,
>> @Contended, @Stable, etc (most of them are located in
>> jdk.internal.vm.annotation in 9).
>>
>> Right now, VM ignores any annotation unless it is declared on a class
>> from privileged context (JDK classes or VM anonymous classes).
>>
>> Some features introduced adhoc flags to relax the restriction (e.g.,
>> -XX:RestrictContended & -XX:RestrictReservedStack), but with modules
>> there's a universal way to expose them in controlled manner: rely on
>> annotation class accessibility checks. In order to make some annotation
>> available in non-privileged context, it is enough to add relevant export
>> to java.base module (e.g., --add-exports
>> java.base/jdk.internal.vm.annotation=ALL-UNNAMED).
>>
>> The problem I faced was that accessibility checks are performed on
>> already loaded classes, but annotations are used during class parsing
>> and the checks have to be performed against the class being loaded.
>>
>> One option is to re-implement accessibility checking logic and extract
>> all necessary information from ClassFileParser.
>>
>> Another approach is to collect VM annotations during parsing and after
>> the class is loaded apply them one-by-one doing accessibility checks. It
>> works fine for most of the existing annotations, but problematic for
>> @Contended - it affects instance layout which is computed during parsing.
>>
>> So, after some experiments, I decided to try different approach:
>> optimistically assume all annotations are accessible and re-parse the
>> class if any used annotation is not available:
>>
>> http://cr.openjdk.java.net/~vlivanov/vm_annotations/webrev.00
>>
>> The benefit is that parsing & accessibility checking logic stay the
>> same. Also, it enabled sanity checking logic for annotation usages
>> almost for free.
>>
>> Overall, I'm quite satisfied with the result, but stumbled upon some
>> nuisance when implementing re-parsing (e.g., tracing framework needs
>> access to ClassFileParser and it brings unnecessary changes into
>> ClassFileParser::parse_instance_klass_from_stream).
>>
>> Before investing into polishing the change, I'd like to discuss the
>> approach I chose.
>>
>> Any problems with class file re-parsing or annotation resolution in VM I
>> overlooked?
>>
>> Maybe there are strong arguments for other options (#1: accessibity
>> checks in ClassFileParser & #2: apply annotations after the class is
>> loaded)?
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
More information about the hotspot-dev
mailing list