RFR: 8314999: IR framework fails to detect allocation [v2]

[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...

Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:

  more compact printing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24093/files
  - new: https://git.openjdk.org/jdk/pull/24093/files/07928fa2..e1245125

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24093&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24093&range=00-01

  Stats: 96 lines in 5 files changed: 84 ins; 6 del; 6 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