RFR: Implement value type buffering for the interpreter
karen.kinnear at oracle.com
Fri Jun 23 19:48:17 UTC 2017
This looks excellent, thank you for doing this so carefully. And thank you
for the cleanups and diagnostic information.
I had a few minor questions/comments. I do not need to see any updates - feel
free to check this in with or without changes.
line 98 comment - could you possibly change "Done with _pool_lock" to
"Done with" could be translated as you have completed using the _pool_lock.
2. I could use help understanding the JDK10 change to root walking
that meant that you needed to store the java_mirror in the mark word.
Is there a bugid or comments in the source that I could read up on this?
Is the intent here that it is faster to just read the mirror than to
follow the valueKlass field to retrieve the mirror? So this is a memory/GC pause
time tradeoff and today we have that memory available?
It looks like the existing OopClosure is still being passed the reference heap address not
the mirror for non-buffered types - or did I read this incorrectly?
3. InterpreterRuntime::vwithfield line 254
I didn't understand why this wasn't a CHECK_0)?
4. mutexLocker.cpp, instanceKlass.cpp and oopMapCAche.cpp - these locks changed to not look for safepoint
Do we need these changes in hs10?
Why did you disable -Xcomp ?
> On Jun 20, 2017, at 4:50 PM, Frederic Parain <frederic.parain at oracle.com> 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