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

David Holmes 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 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

More information about the core-libs-dev mailing list