RFR: aaload/aastore profiling

Tobias Hartmann tobias.hartmann at oracle.com
Fri Nov 15 11:47:58 UTC 2019

Hi Roland,

very nice. Here are some comments:
- macroAssembler_x86.cpp:3462, indentation is wrong
- c1_Runtime1.cpp:476, can you move this into the else branch (line 485) to avoid the is_flattened()
check and also move the assert into the two branches?
- ciMethod.cpp:697, can this assert be removed?
- ciObjArrayKlass.cpp: why are these checks required?
- parseHelper.cpp and parse2.cpp, this code is very hard to read - comments would be helpful :)
- TestLWorld.java:2318, can this be removed?
- ValueTypeTest.java, nice refactoring. I had something similar in the queue. Can lines 553, 565 be
- Should the C1 and interpreter profiling be guarded by EnableValhalla?

I've executed some testing, all passed! How did you verify performance?

Please file an enhancement for this so we can better keep track of related tasks.


On 14.11.19 10:55, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/valhalla/aaload-aastore-profiling/
> This patch adds profiling for aaload and aastore in order to improve
> code generation for inline types.
> Array type, element type whether the array is flat or null free are
> collected for both aaload and aastore. aastore already collects some
> profiling (element type). In practice, the new profile collection scheme
> at aastore replaces the old one.
> The patch includes changes to C2 so it leverages the new profiling. At
> an aaload, if profiling reports a single array type, c2 casts the array
> type to the profiled type if it helps avoid a flat array
> check. Otherwise, if profiling reports no accurate type for the array,
> c2 can cast the array to non flat or non null free based on profile
> data.
> MonomorphicArrayCheck is also modified to take advantage of the new
> profiling. So at an aastore, if profile data sugggests an array type,
> the array should be always casted to that array type.
> Roland.

More information about the valhalla-dev mailing list