[Vm-dev] Is it important to fill identity-hash for Floats?

Igor Stasenko siguctua at gmail.com
Mon Jul 29 22:41:17 UTC 2013

On 30 July 2013 00:23, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 2013-07-29, at 23:59, Igor Stasenko <siguctua at gmail.com> wrote:
>> just a thought..
>> imo using identity hash field for instances of Float while probable,
>> but in fact really impractical.
>> in that sense, what you think about removing filling the identity hash field
>> and leave it always == 0.. saving some instructions to make float
>> allocation a bit faster?
>> i am talking about
>> genAllocFloatValue: dpreg into: resultReg scratchReg: scratch1
>> scratchReg: scratch2
> IMHO, turning Floats into the only objects in the system that cause severe collisions in IdentitySets / Dictionaries should not be done lightly. It's a step away from "every object is equal" which I think is an important principle.
> The VM should only "cheat without getting caught", as Dan put it. And there are options for that.
> For example, the better our JIT gets, the less intermediate floats need to be allocated because you can avoid boxing/unboxing them altogether, so that's an even larger win.
> And if we switched to immediate floats (e.g. in the 64 bit image format) the allocation issue would go away completely.
perhaps then it makes sense to also modify identityHash primitive to
check if receiver is Float
and use float value for it?
Then there is no collisions/cheating, and little speedup in floats allocation?
So identityHash primitive wear additional cost with checking that
header is actually compactfloat.
But given the amount of floats "floating around" :) comparing how
often #identityHash is used, i think it is fair tradeoff.

> I'm still curious: Assuming you tried it already, what kind of speedup do you get?
i did not tried.

> - Bert -

Best regards,
Igor Stasenko.

More information about the Vm-dev mailing list