[mvt] RFR MVTTest refactor

[Paul Sandoz]

> On 7 Jun 2017, at 02:11, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> This looks great! The very fact that the test works seems promising - of course there will be intermediate 'unwanted' boxing (which we'll want to get rid of), but it seems like the prototype can handle some degree of combinators well, which should enable some real world end to end testing.
> 
> 

Yes, i’ll add a few more test methods, unless i run into something tricky i’ll just push ‘em without a webrev.


> I think you should be a Valhalla committer - in case you have any issue please ping me and I'll push for you.
> 

Thanks, i have access. Pushed.

—

How can we tell if unwanted boxing is going on? is there a HotSpot XX flag we can use to trace the vbox/vunbox actions?

As an experiment i removed the -Xint flag from the MVTTest and it passes, including if i up the loop iterations to 100000, which means C2 should be kicking in.

—

I notice a difference between the declaration of a minimal value type in the JDK tests:

  @jvm.internal.value.DeriveValueType
  final class Point {

And that in some VM tests:

  public __ByValue final class Point {

How much should we depend on the more direct javac functionality for such tests? rather than going through the indirect MVT route for our tests?

Paul.