review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler
John Rose
john.r.rose at oracle.com
Fri Jul 1 13:50:31 PDT 2011
On Jul 1, 2011, at 1:26 PM, Vladimir Kozlov wrote:
> Wrap new java dimension allocation into PreserveReexecuteState scope and restore stack.
Is this in case the initial allocation deoptimizes (due to some external event)? I suppose that should be tested with DeoptimizeALot.
Igor, the extraction from the dope array bothers me:
+ jint *j_dims = (jint*)dims->base(T_INT);
+ jint *c_dims = NEW_RESOURCE_ARRAY(jint, len);
+ memcpy(c_dims, j_dims, sizeof(jint)*len);
It is correct, but I'd rather see more use of Hotspot machinery, with stronger typing:
+ jint *j_dims = typeArrayOop(dims)->int_at_addr(0);
+ jint *c_dims = NEW_RESOURCE_ARRAY(jint, len);
+ Copy::conjoint_jints_atomic(c_dims, j_dims, sizeof(jint)*len);
Note that Copy::* strongly outnumbers memcpy in the opto directory. The distinction is mostly stylistic, but Copy:: is more strongly typed in this case.
(In other uses, Copy:: is more explicit and careful about some of the things we need to care about, such as overlaps and word-tearing.)
Also, use is_typeArray instead of is_array in the previous assert. That will make the cast to typeArrayOop safe.
-- John
More information about the hotspot-compiler-dev
mailing list