review request (L): 7030453: JSR 292 ClassValue.get method is too slow

[David Holmes]

On 5/12/2011 11:03 AM, Rémi Forax wrote:
> On 12/05/2011 01:27 AM, Joe Darcy wrote:
>> On 12/4/2011 2:13 PM, Rémi Forax wrote:
>>> On 12/04/2011 08:38 PM, Joe Darcy wrote:
>>>>
>>>> Are there alternatives to adding two new fields to java.lang.Class?
>>>> I assume most Class'es won't have ClassValue information associated
>>>> with them.
>>>
>>> If you use Groovy, JRuby or Nashorn in your code, all visible classes
>>> will use this two fields.
>>>
>>> Any alternative will slow down the access to the class value.
>>
>> In the mean time, all the non-Groovy, non-JRuby, non-Nashorn, etc.
>> uses of class Class and all the classes not visible in those
>> environments when they are being used will be larger.
>>
>> Adding the fields may be the right time/space trade-off, but I think
>> the point merits some discussion given how many Class objects get
>> created and the relative proportion of Java executions where
>> ClassValue is currently used.
>>
>> The more reasonable time/space trade-off can change over time of course.
>>
>
> I agree but as I said, in that case, I think it's better to take a look
> to the big picture
> and see if not only class values fields but also annotations related
> fields or reflection related fields can be moved.

This is currently being looked at with a general aim of reducing the 
size of Class instances. So adding back some size would need strong 
justification.

David
-----


> Also, if we don't provide a fast ClassValue, people will create their
> own concurrent weak hash map
> using class as key that will be worst because it seems that only few
> people knows
> how to do that right. Personally, I don't.
>
> Rémi
>