Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Miniboxing should interoperate with specialization #108
... at least for
Suggested by @alexandru in the miniboxing mailing list: https://groups.google.com/d/msg/scala-miniboxing/dJDmxtPnwCg/cqh7Tm7xnhEJ
The problem is that the function application requires boxing, although the caller is miniboxed and the
The first problem is that
Currently, the miniboxing transformation occurs before specialization, so it would be specialization's responsibility to redirect the call from
Now, according to the definition of optimized stack initiators in the miniboxing tutorial, which is also applicable to specialization, a receiver of type
Now, how to fix this?
A proposed solution is to create a specialized bridging method, that miniboxing can call:
But what about that tuple of tags? Isn't that expensive?
Yes, it is. An optimized implementation is:
The above two-layered structure will be amenable to inlining in the caller, thus potentially optimizing the code for call sites where the tags are known statically. On the other hand, it does two steps of dispatching, thus significantly slowing down execution.
An alternative implementation would be:
The second solution encourages the HotSpot vm to compile of the
To sum up, it is not clear which solution would be better, if either would be better at all. I think benchmarks should decide between the two implementations. Over the next few days I will implement both solutions and make a compiler flag to trigger one or the other, so we can benchmark.
Of course, the best solution would be to allow miniboxing stubs in specialization, thus allowing miniboxing to optimally call into specialized code. This would actually provide wonderful performance, but that would require binary incompatible changes to the Scala library...
@alexandru, sorry for the radio silence these last few days -- I had a few distractions and I've been thinking about the best solution for this problem -- I think I have a solution that will be significantly better -- only introducing overheads when creating a function, not when calling it. I'm looking into this now.