On Wed, May 26, 2010 at 7:32 PM, John Rose <[email protected]> wrote:
> EA is a fragile optimization. Caching optimizations in factory methods can
> inhibit it.
>
> Does your factory method do anything other than create a new RubyFloat on
> every call?
Just as easy to show as to explain:
public static RubyFloat newFloat(Ruby runtime, double value) {
return new RubyFloat(runtime, value);
}
public RubyFloat(Ruby runtime, double value) {
super(runtime, runtime.getFloat());
this.value = value;
}
Is it possible for the non-final "metaclass" field to defeat EA in
this case? Are there any good switches we can use to get some
visibility into EA decisions?
Fixnum, of course, does have numerous caching behaviors. If we remove
them, low-valued numeric operations become considerably slower without
EA, but I'm not sure we've ever been able to see EA solve this case.
I hope there's a university out there somewhere about to announce
they've added value types to OpenJDK...we're going to fall behind
other dynlang impls that have fixnums and flonums :(
- Charlie
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
