Request for review: 8004698: Implement Core Reflection for Type Annotations
peter.levart at gmail.com
Tue Jan 22 17:27:56 UTC 2013
On 01/22/2013 06:08 PM, Joel Borggrén-Franck wrote:
> On Jan 22, 2013, at 6:01 PM, Peter Levart <peter.levart at gmail.com> wrote:
>> On 01/22/2013 01:47 PM, Joel Borggrén-Franck wrote:
>>> Hi Peter,
>>> Thanks for your comments, see inline,
>>> On 01/19/2013 06:11 PM, Peter Levart wrote:
>>>> I see, there is a dilema how to cache type annotations. To satisfy
>>>> single-annotation-returning methods and repeating annotation logic, a
>>>> HashMap would be a logical choice, but it has much bigger footprint than
>>>> simple arrays of annotations...
>>> I don't prioritize footprint for classes that have runtime visible type annotations. Those classes should be very few, and as a user you are making an explicit choice of adding metadata when you use runtime visible (type) annotations.
>>> So here is my list of priorities (and by un-annotated I mean without runtime visible annotations):
>>> - Unannotated classes/fields/methods should have as small as possible extra footprint, this is most important.
>> Hello Joel,
>> I imagine there will be additional places where references to Map<Class<? extends Annotation>, Annotation> will be added to hold cached annotations. To satisfy your priority #1 I would consistently make sure that when there are no annotations to put into the map, a singleton Collections.emptyMap() reference is put in place. This is currently not so for regular annotations (should be corrected). I know of runtime tools that "scan" classes for particular annotations, just to find out that majority of them are without annotations. If empty instances of HashMap(16) pop-up as a result of such scan, lots of memory is wasted.
> Good suggestion.
>>> - Classes/fields/methods without type annotations should have negligible footprint over classes/fields/methods with only regular annotations.
>> You meant "Classes/fields/methods *with* type annotations should have negligible footprint over classes/fields/methods with only regular annotations", right?
> No :)
> As I suspect class/filed/methods with runtime visible regular annotations will be 100x (or 1000x??) more common than with runtime visible type annotations the most common scenario will be
> 1) No annotations
> 2) Only regular annotations
> So there should be very little overhead from having no type annotations. IE in the order of an extra pointer that is null.
Ah, I understand that sentence now ;-).
... extra pointer that is null (not cached yet) or
Collections.emptyMap() (cached but empty)....
More information about the core-libs-dev