review request (L): 7030453: JSR 292 ClassValue.get method is too slow
david.holmes at oracle.com
Mon Dec 5 02:25:28 UTC 2011
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
> 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.
More information about the core-libs-dev