RFR: 8314999: IR framework fails to detect allocation

[Marc Chevalier]

Bring the `ALLOC(_ARRAY)?(_OF)?` IR framework regex in the modern era!

Rather than matching on the OptoAssembly, we now match before macro expansion. Ideed, matching on OptoAssembly is fragile: between the register being assigned the class to allocate and the actual call to `_new_instance_Java`, there might
be register spill, making the match hard, and fragile. Now, these regex are applied before macro expansion.

To make that work, I needed to adapt the dump_spec of `AllocateNode` to print the allocated class, in case it is a precise constant. This is also nice to have as a human reading the output.

The new feature is also slightly more precise in case we want to match the allocation of a given class (that is `ALLOC(_ARRAY)?_OF`). It used to be along the lines of:

"precise .*" + IS_REPLACED + ":"

which is actually too lenient: it only assert the suffix is what is expected. On the plus side, if we wanted to have `MyClass`, then `some/package/MyClass` would match, but on the other hand, `ItLooksLikeButIsNotMyClass` would also match. The new regex use a word boundary:

"precise .*\\b" + IS_REPLACED + ":"

which make it a bit more specific: the given name cannot be extended with only letters: there must be a non-letter char. For instance, `ItLooksLikeButIsNotMyClass` wouldn't work anymore, since there is no word boundary between `ItLooksLikeButIsNot` and `MyClass`.

It is not quite fool-proof since a package path can still be extended, e.g.

@IR(counts = {IRNode.ALLOC_OF, "some/package/MyClass", "1"})

will also match allocations of `a/prefix/some/package/MyClass`.

I think it's an acceptable limitation.

Let's have a little preview of the new `dump_spec`. For instance, it could have been something like:

 140  Allocate  === 120 117 137 8 1 (93 138 23 1 1 10 43 43 10 43 ) [[ 141 142 143 150 151 152 ]] rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top, bool ) Test$MyClass::<init> @ bci:13 (line 41) Test::test @ bci:5 (line 46) !jvms: Test$MyClass::<init> @ bci:13 (line 41) Test::test @ bci:5 (line 46)

and now it is

 140  Allocate  === 120 117 137 8 1 (93 138 23 1 1 10 43 43 10 43 ) [[ 141 142 143 150 151 152 ]]  precise java/util/HashSet: 0x00007fe2244ccd28 (java/lang/Cloneable,java/io/Serializable,java/lang/Iterable,java/util/Collection,java/util/Set):Constant:exact * rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top, bool ) Test$MyClass::<init> @ bci:13 (line 41) Test::test @ bci:5 (line 46) !jvms: Test$MyClass::<init> @ bci:13 (line 41) Test::test @ bci:5 (line 46)

The
`precise java/util/HashSet: 0x00007fe2244ccd28 (java/lang/Cloneable,java/io/Serializable,java/lang/Iterable,java/util/Collection,java/util/Set):Constant:exact *` part is new. It is meant to be like what we can see in  `ConP`.

-------------

Commit messages:
 - IR ALLOC before macro expansion

Changes: https://git.openjdk.org/jdk/pull/24093/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24093&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314999
  Stats: 70 lines in 6 files changed: 29 ins; 13 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/24093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24093/head:pull/24093

PR: https://git.openjdk.org/jdk/pull/24093