RFR: 8334779: Test compiler/c1/CanonicalizeArrayLength.java is timing out

[Dean Long]

On Mon, 24 Jun 2024 23:40:22 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> The timeout is cause by running the test with `-Xcomp -XX:+VerifyOops -XX:+PatchALot`.
> The test continuously deoptimize and recompile `java.lang.Throwable::<init>` method.
> `-XX:+VerifyOops ` adds a lot of external addresses because it use ExternallAddress for error messages.
> These messages are unique for each call to `verify_oop()` because they are constructed locally.
> I reduced number of loop iteration by 10 to get reasonable execution time (2 mins instead of 20 mins) and got next data:
> 
> Without VerifyOops:
>   External addresses table: 38 entries
> 
> With VerifyOops:
>   External addresses table: 125922 entries
> 
> Looks like most of the time VM is spending to grow/reallocate big growable array added by [JDK-8333819](https://bugs.openjdk.org/browse/JDK-8333819).
> Before that change these addresses were recorded locally in nmethod's relocation info. When nmethod was deoptimized, its relocation info was discarded together with nmethod.
> 
> Only on x86 we declared message address as ExternalAddress. Aarch64 uses movptr() to store address as simple pointer. ARM uses own InlineAddress with RelocInfo::none type of relocation. I verified other platforms: none is using ExternalAddress.
> 
> I suggest to use AddressLiteral with RelocInfo::none for x86. With that the global table is small even with -XX:+VerifyOops:
> 
>   External addresses table: 42 entries
> 
> 
> Tested tier1,  run test with corresponding flags to verify that time is similar to before [JDK-8333819](https://bugs.openjdk.org/browse/JDK-8333819)

Where are these strings actually located?  Do they need to be relocated if the CodeBuffer expands?

Can we assert that uses of ExternalAddress do not point inside the CodeBuffer/CodeBlob?  You might catch additional cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/19871#issuecomment-2187893564