Miniboxing compiler plugin in Maven

[dirk...@gmail.com]

Hello everyone,

I apologize in advance for my ignorance, but I can't seem to get Miniboxing to work in a Maven project in Scala IDE. I added the compiler plugin to the pom.xml as follows:

<plugin>
<groupId>org.scala-tools</groupId>
<artifactId>maven-scala-plugin</artifactId>
<executions>
{...}
</executions>
<configuration>
<compilerPlugins>
<compilerPlugin>
<groupId>org.scala-miniboxing.plugins</groupId>
<artifactId>miniboxing-plugin_2.11</artifactId>
<version>${miniboxing.version}</version>
</compilerPlugin>
</compilerPlugins>
<scalaVersion>${scala.version}</scalaVersion>
<args>
{...}
<arg>-P:minibox:warn-all</arg>
</args>
</configuration>
</plugin>

But neither Miniboxing warnings nor any Maven errors are emitted. The Miniboxing runtime components are included. What am I missing here? Is there maybe a Template/Example that i could take a look at? I really appreciate any help you can provide.

[Vlad Ureche]

Hi Dirk!

Thanks for pointing this out, there’s no documentation for maven at all! One more entry on the TODO list :)
In your maven file, the miniboxing plugin is only added as a dependency, but is not added to the Scala compiler configuration.

In sbt, what you wrote would be:

libraryDependencies += "org.scala-miniboxing.plugins" %% "miniboxing-plugin" % "0.4-SNAPSHOT"

whereas what you need is:

addCompilerPlugin("org.scala-miniboxing.plugins" %% "miniboxing-plugin" % "0.4-SNAPSHOT") // does libraryDependencies and affects scalacOptions

Now, since you mentioned you are using the Scala IDE, here’s what you could do

• Locate the miniboxing-plugin and miniboxing-runtime jars in the local ivy cache
  • in my case miniboxing-plugin was in /home/sun/.ivy2/cache/org.scala-miniboxing.plugins/miniboxing-plugin_2.11/jars/miniboxing-plugin_2.11-0.4-SNAPSHOT.jar
  • and miniboxing-runtime was in /home/sun/.ivy2/cache/org.scala-miniboxing.plugins/miniboxing-runtime_2.11/jars/miniboxing-runtime_2.11-0.4-SNAPSHOT.jar
• In the Scala IDE, right-click your project and go to Properties:
  • under Java Build > Libraries click Add External Jars... and add both jars above
  • under Scala Compiler, in the bottom text box called Additional command line parameters add -Xplugin:<path to miniboxing-plugin> -P:minibox:warn-all

Now rebuild your project and you should see warnings. Let me know if you encounter any issues.

HTH,
Vlad

PS: If the “-P:minibox:warn-all” output is too verbose, you can use “-P:minibox:warn” and it will restrict the warnings to your own code.

--
You received this message because you are subscribed to the Google Groups "Scala Miniboxing Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-miniboxi...@googlegroups.com.
To post to this group, send email to scala-mi...@googlegroups.com.
Visit this group at http://groups.google.com/group/scala-miniboxing.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-miniboxing/1402c9c8-7c04-4e98-be69-fbda57f88c0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

​

[Vlad Ureche]

Actually, are you generating the Scala IDE project files from maven? Or how is the Scala IDE project initialized?

If you want, log into the miniboxing gitter channel so we can chat directly.

Cheers,

Vlad

[dirk...@gmail.com]

Okay thank You, Vlad! Adding the plugin using the -Xplugin scala argument works.

I had one more error thrown by Scala IDE:
miniboxing-plugin.jar is cross-compiled with an incompatible version of Scala ...

The work-around can be found in the Scala IDE faq. You simply deactivate the 'withVersionClasspathValidator' flag in the Scala (IDE) Compiler settings.

The warnings are working and the compiler runs without complaint now.

However the performance results so far are not as expected. While @specialized gives me a 50% performance boost, @miniboxed decreases performance by 50%. Is it a problem having both @specialized and @miniboxed in the same project although the do not interact with one another?

Also I have two small questions concerning Miniboxing in general:

- Does Miniboxing work with user defined value types (unknown at compile time)? That would be the number one selling point over specialized - in my option.

- My main concern with boxing is not performance but memory: On a 64bit JVM, a Float is 7* bigger than a float i believe (128bit object header + 64bit reference). So my question is there a possibility to make Miniboxing work for class members at Runtime as well? Maybe by implicitly storing a type tag?

Cheers,
Dirk

[Vlad Ureche]

On Sun, Jun 7, 2015 at 3:13 PM, <dirk...@gmail.com> wrote:

Okay thank You, Vlad! Adding the plugin using the -Xplugin scala argument works.

I’m really glad to hear that! Congratulations for getting it working!

I had one more error thrown by Scala IDE:
miniboxing-plugin.jar is cross-compiled with an incompatible version of Scala ...

The work-around can be found in the Scala IDE faq. You simply deactivate the 'withVersionClasspathValidator' flag in the Scala (IDE) Compiler settings.

Or you can live with that warning… Miniboxing is cross-compiled against the latest two versions of Scala: 2.10.5 and 2.11.6, but the classpath validator is not smart enough to figure it out.
Btw, if there’s any incompatibility the miniboxing plugin will tell you:

$ mb-scalac x.scala
warning: The miniboxing plugin does not match the Scala revision. If you encounter errors, 
please use the Scala compiler version 2.11.6 or update the miniboxing plugin to a version 
which supports Scala 2.11.5-20141107-114204-b1e6f57b2b.

The warnings are working and the compiler runs without complaint now.

Cool!

However the performance results so far are not as expected. While @specialized gives me a 50% performance boost, @miniboxed decreases performance by 50%. Is it a problem having both @specialized and @miniboxed in the same project although the do not interact with one another?

Yes, that can be a major source of overhead. Miniboxing and specialization communicate via boxing, so if you have a miniboxed method calling a specialized one (or vice-versa) in the hot loop, there goes your performance. Now… warnings should let you know about this, but we recently had a major refactoring of the warnings system, and maybe some cases fell through the cracks.

Can you try the “-P:minibox:all” flag? It should minibox everything, including the previously-specialized classes.

Also I have two small questions concerning Miniboxing in general:

- Does Miniboxing work with user defined value types (unknown at compile time)? That would be the number one selling point over specialized - in my option.

What do you mean? Something like:

  type MyType = Float
  new Graph[MyType](...)

- My main concern with boxing is not performance but memory: On a 64bit JVM, a Float is 7* bigger than a float i believe (128bit object header + 64bit reference). So my question is there a possibility to make Miniboxing work for class members at Runtime as well? Maybe by implicitly storing a type tag?

If I understood well what you meant, yes, it applies to class members as well — i you have a member of type T, where T is marked as @miniboxed, it will be stored unboxed.

I’ll be on gitter if you want to chat directly.

Cheers,
Vlad

​