RFR: Implement value type buffering for the interpreter
david.simms at oracle.com
Mon Jun 26 14:04:26 UTC 2017
Kudos on the loop testing, like the targeted testing . Good work on the
static init fixes and testing.
* 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 :-)
On 20/06/17 22:50, Frederic Parain wrote:
> Here's a webrev implementing value type buffering for the interpreter.
> 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.
More information about the valhalla-dev