On May 26, 2010, at 5:37 PM, Charles Oliver Nutter wrote:
> 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;
> }
Well, that looks simple and EA-friendly.
> Is it possible for the non-final "metaclass" field to defeat EA in
> this case?
No, EA doesn't depend on final-ness.
> Are there any good switches we can use to get some
> visibility into EA decisions?
Good old LogCompilation will tell you when allocations are eliminated.
Also PrintEscapeAnalysis and PrintEliminateAllocations (non-product switches).
> 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.
We had to put special logic into the dynamic compiler to recognize and discount
the effects of such caching in Integer.valueOf. The caching is required by the
specification, useful for most apps, and noxious to the EA optimization.
> 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 :(
The mlvm project is looking for a few good grad students...
-- John
--
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.
