VectorBox enabling

[Vladimir Ivanov]

Nice work, Razvan!

> VectorBox enabling is now mostly complete and appearing to be functional. The VectorBox supports being able to generate objects for all supported Vector objects that have some intrinsic method. This includes GenericMask (subject to some limitation noted below). Additionally, VectorBox nodes can be removed along with their allocations in cases when the objects do not need created. I have tested BLAS (saxpy, sdot) and Sepia demo used in JavaOne and performance has not regressed.
> 
> Please see attached patch and if there are no concerns, I will merge tomorrow.
> http://cr.openjdk.java.net/~rlupusoru/panama/webrev_vectorbox_04/

src/share/vm/opto/macro.cpp:

+      vectorbox_remove_store(_igvn, fstore);
+      vectorbox_remove_store(_igvn, vstore);
+
+      vectorbox_remove_allocate(obj_alloc);
+      vectorbox_remove_allocate(arr_alloc);

+void PhaseMacroExpand::vectorbox_remove_allocate(Node* allocate) {
+  if (allocate != NULL && allocate->is_Allocate()) {
+    allocate->as_Allocate()->_is_scalar_replaceable = true;
+    allocate->as_Allocate()->_is_non_escaping = true;

Here's the problem I see with that: you try to persuade 
PhaseMacroExpand::eliminate_allocate_node that it's safe to scalarize 
the object (and remove the allocation). There are additional checks in 
PhaseMacroExpand::can_eliminate_allocation() & 
PhaseMacroExpand::scalar_replacement(), but even if they all pass, C2 
can't correctly scalarize the object anymore, because field stores are 
already removed.

For example, if a scalarizable object is referenced by a safepoint, C2 
replaces it with SafePointScalarObjectNode and attaches up-to-date field 
values to it, so runtime can re-materialize the instance if needed.

It won't work as intended anymore if you remove stores first.

And I'm curious how profitable _is_scalar_replaceable = true trick 
becomes when you change the order.

Best regards,
Vladimir Ivanov

> Note that in patch you will find some "FIXME" related to masks (namely mask shape and type recovery is not possible at times during intrinsification). After this patch, I will look into solving this problem by potentially having specialized masks for each type and shape combination (as is done for species).
> 
> The main limitations remaining with VectorBox are as follows:
> 
> -          If VectorBox is used by any non-intrinsified calls, stores to heap, or runtime calls via deopt, it will generate an object at the original call site. The plan is to move this to slow path when Vector API object identities can be ignored.
> 
> -          VectorBox for GenericMask does not set the Species field. This will either be fixed in a follow-up patch or the approach for specialized masks will be employed instead.


> 
> Thanks so much!
> 
> --Razvan
>