Warn when boxing value classes

[japgolly]

Most of us know that when you create a value class, there are cases in which the compiler will box/instantiate them. The specific rules are much less known than the fact that it can occasionally happen.

Could we please have an option for scalac to produce a warnings when it will box a value class? That way when we see the warnings we have the opportunity to either modify to our code to avoid boxing, or accept boxing by adding something @noWarn or @unchecked.

[dwalend]

This feature is critical for my work to getting Scala working on a (small, limited) ARM9. I'm writing control feedback loops, and every allocation I remove cuts the loop latency by several milliseconds. My plan B is looking at the compiled code. I can't teach that to the kids, but a compile time warning would let them find the problems themselves and let me teach them how to fix them.

[chaotic3quilibrium]

Tysvm for taking the time to open this issue. By just surfacing the fact the compiler has engaged in boxing will be quite educational for those who are seeking performance impacts and optimization opportunities. Additionally, it will allow many more use cases/test cases to be explicitly identified such that sophisticated compensation mitigations can be designed and shared more clearly. And those will eventually lead to more opportunities to upgrade the compiler to better avoid the boxing.

tl;dr This is a great way to get a focus on producing tons of concrete boxing cases so as to improve the compiler's ability to identify said cases and avoid boxing.

[dwalend]

This may be out of scope for this feature request: Could we have an annotation that would warn us about any allocations within a block of code?

I'm writing code in a tight control loop on some limited hardware. Memory allocation seems to be the biggest source of poor performance - each object created adds a fistfull of milliseconds, and eventually the garbage collector is going to stop the whole works. I want to build up that tight control loop in a way that allocates as little memory as possible. Outside that loop I really don't care.

Detecting autoboxing will help me a lot, but I could use even more.

What are use cases where someone cares only about autoboxing?

[Rich2]

Could this be behind a compiler flag? I can see it potentially adding a lot of unhelpful boilerplate.

[dwalend]

@Rich2 - I believe that's the intent

an option for scalac

[mbeckerle]

Can't find an upvote button. But I vote for this feature.

In all cases where we use value classes, it's inner-loop code where we're using it to avoid overhead like boxing, but get some of the scala advantages of real types.

We actually want it to be an error if our value classes are boxed, ever. The whole point is to avoid that. So if this is a scalac option, having 3 states: warn, nowarn, error would be great.

[som-snytt]

Duplicates #9504 which has fewer digits.

I'll leave it open while I look for a quick enough fix. (This ticket has a greater sense of urgency, or insurgency.)

@dwalend 2.13.9 includes -Wperformance scala/scala#9889 which rolls up -Wnonlocal-return and -Wcaptured (which is also new).