On 2012-07-05, at 9:26 PM, Rémi Forax wrote:
> On 07/05/2012 10:42 PM, Jim Laskey wrote:
>> Fairly common patterns like
>>
>> var p = {
>> fontsize: 15,
>> lineheight: 22,
>> color: 0x000,
>> fontfamily: "Georgia, FreeSerif, Times, serif"
>> };
>>
>> p.color = "white";
>>
>> We need flexible slots without allocating 2x memory.
>>
>> For "for like" constructs we typically use static analysis to reduce
>> to integer.
>
> Not having such kind of analysis is almost a crime.
>
> Jim, do you have a paper explaining the static analysis you use,
> I have some trouble to keep mine linear.
>
Marcus Lagergren will be doing a talk at JavaOne on type specific optimizations
that we use.
>> With TaggedArray slots for frames we could use integer dynamically.
>
> yes, but performance will be awful (ok, better than using boxing but 2x
> or 3x slower
> than C or Java) if you don't have any kind of type propagation.
We're seeing 2x using C2, but the benefit is that if you have to roll over into
another type (ex. box) you can use the same slot.
One subtlety I should point out, the plan is to have the copy method optimized
to inline small copies, so that constant length copies of 1-4 (or so) will be
native memory to memory moves. This means you can move values,
object/frame/stack to object/frame/stack without any type checking (1-1 with
C/Java.)
>
>>
>> Cheers,
>>
>> -- Jim
>
> cheers,
> Rémi
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
