RFR (M): Add missing compiler checks

Zoltán Majó zoltan.majo at oracle.com
Wed Jun 14 10:55:04 UTC 2017


please review the following change:

The change adds some (or hopefully all) checks that C2 currently does 
not generate but will most likely be required by the MVT specification. 
I tested the change with JPRT (x86_64), no failures have appeared. I'm 
currently running the hotspot/compiler JTREG tests locally.

A few notes about the change:

- Moving _element_klass from ObjArrayKlass to ArrayKlass is necessary 
because that way the klass of the array elements is found at the same 
offset in both ObjArrayKlass and ValueArrayKlass instances (and we need 
the offset to implement type checks). However, _element_klass is now 
present in TypeArrayKlass as well (where it is not needed). Maybe a 
better way to organize the class hierarchy would be to put 
_element_klass into a new common subclass X of [Obj|Value]ArrayClass; 
both X and TypeArrayKlass would then be direct subclasses of ArrayKlass. 
Maybe it's better to deal with this aspect once the we're closer to the 
final specification/design of MVT.

- The change adds a type check to InterpreterRuntime::value_array_store. 
I assumed (and expect) vastore will behave similarly to aastore and 
requires the element type of src/dst to match. Please let me know if 
that is an incorrect assumption.

- The bytecodes vdefault/vwithfield can throw an OutOfMemoryError if no 
space is available for allocation. With the current C2 implementation 
allocations can be delayed to a later point in the program (e.g., when a 
deoptimization happens). If no free memory is available at that point to 
allocate memory for a value type, the OOME will appear later than the 
vdefault/vwithfield bytecode that actually caused it. Tobias and I 
discussed about this aspect and it's likely that this is not a problem 
as re-allocation of scalar-replaced objects is similar and is also 
performed at deoptimization. However, more investigation is needed to 
confirm that.

Thank you!

Best regards,


More information about the valhalla-dev mailing list