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 > _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
