review request (L): 7030453: JSR 292 ClassValue.get method is too slow
forax at univ-mlv.fr
Mon Dec 5 01:03:13 UTC 2011
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:
>>> Hi John,
>>> 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.
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
how to do that right. Personally, I don't.
More information about the core-libs-dev