One of the most difficult problems in using specialization is finding out when something went wrong and the code reverts
to using boxed primitives. This gave birth to a very useful post by Alex Prokopec explaining the quirks of specialization.
Some of these quirks also apply to miniboxing. Yet, there is an important difference. To see it, one should ask the question “what is a quirk?” for specialization. A quirk, as Alex’s explanation shows, is a design or technical limitation that results
in a seemingly correct compilation, but that produces suboptimal code. From this perspective, we can say that:
Quirk = limitation + silent failure
As everything else, miniboxing and specialization have to make compromises. These can occur at different levels, from well-understood
design decisions that sacrifice certain code patterns all the way to purely technical limitations where the problem is simply not worth the
effort to solve.
But there is a second ingredient: the silent failure. Without silently failing, specialization would just point the user into the
right direction by providing a workaround or explaining why a limitation occurred. Yet, not doing so made it much harder to use,
allowing only an elite of the Scala community to benefit from the unboxed generics. If only specialization could TALK…
Well, miniboxing does talk :)
A new feature of the miniboxing plugin is that it talks to you about performance. And how you can improve it. And this will
expose all the code where it was not able to correctly specialize generics.
For example, here are a few cases:
When the type arguments do not allow an unambiguous choice between primitives and references:
when adding an annotation could benefit the transformation:
at the definition site:
at the use site:
when a technical limitation prevents the plugin from compiling the code:
when a class you might expect to be specialized won’t be:
or when a the code is just suboptimal:
Finally, in some cases specialization is lost because some class or method in the library wasn’t miniboxed: