RFR: Implement value type buffering for the interpreter

[David Simms]

Kudos on the loop testing, like the targeted testing . Good work on the 
static init fixes and testing.

Minor comments:

  * globals.hpp:4097 "sizeof(long long)", is at least 64bits, but not
    fixed size: do you mean BytesPerLong or longSize ?
  * ValueTypesBufferMaxMemory=128, global fixed limit
      o "doesn't feel right", but I admit to not having a better answer.
        Needs more user testing: TODO, we did talk off list about this,
        discussed combination of global + per-thread options.
      o Should "Global VTBuffer Pool statistics" include a failure
        statistic to help with performance evaluation/tuning ?
  * vtBuffer.hpp:40 "_index;" - I can guess what all the other fields
    are at a glance, but a short comment here would be nice

I was wondering if "InterpreterFrameClosure" changes didn't trigger a 
problem in the ValueOops whitebox testing (frame oop maps)...that test 
feels a little on the fragile side.

Looks good, nice work, long live Value Type TLGC :-)

/David Simms


On 20/06/17 22:50, Frederic Parain wrote:
> Greetings,
>
> Here's a webrev implementing value type buffering for the interpreter.
>
> http://cr.openjdk.java.net/~fparain/vt-buffering/webrev.01/
>
> Buffering allows the interpreter to allocate values in a thread local
> buffer to avoid Java heap allocations. Memory recycling is performed
> on method exit and sometimes on backward branches.
>
> Format of buffered values is almost identical to the format of
> Java heap allocated values, so most code won't see any difference
> between a buffered value and a not buffered value. The only difference
> is in the first word of the header. Because of a change in GC closures
> in JDK10, the first word now stores a reference to the Java mirror
> of the value class in order to keep it alive. In JDK9, this operation
> was performed through the klass pointer in the header, but the GC
> team has removed this closure.
>
> Buffering can be monitored using NMT or a new diagnostic command.
>
> All tests pass and Sergey has already tested the patch with his
> benchmark (and reported several bugs that are now fixed, thank
> you Sergey).
>
> Unfortunately, the changeset also includes a number of fixes not
> related to buffering, like code clean up and access to uninitialized
> static value fields.
>
> Thanks,
>
> Fred