Use ArrayPool in CSTRMarshaler.ConvertToNative

[HJLeee]

This reduces temporary byte array creation during p/invoke string param marshaling.

[huoyaoyuan]

All of the marshallers in this file are quite legacy. There are many other opportunities to update.
I'd suggest to not touch it.

[jkotas]

Looks like this change is triggering a JIT bug:

https://helix.dot.net/api/2019-06-17/jobs/0e6c868f-9ce9-4ad2-8e79-f61acd524e57/workitems/System.Security.Cryptography.OpenSsl.Tests/console
https://helix.dot.net/api/2019-06-17/jobs/0e6c868f-9ce9-4ad2-8e79-f61acd524e57/workitems/System.Runtime.InteropServices.Tests/console

Assert failure(PID 34542 [0x000086ee], Thread: 498545 [0x79b71]): Assertion failed '((typeHistogram != nullptr) || (methodHistogram != nullptr)) && "Expected at least one handle histogram when inserting probes"' in 'System.StubHelpers.CSTRMarshaler:ConvertToNative(int,System.String,long):long' during 'Profile instrumentation' (IL size 263; hash 0xc31c0dcd; Instrumented Tier0)

    File: /Users/runner/work/1/s/src/coreclr/jit/fgprofile.cpp:2084

cc @dotnet/jit-contrib

[jkotas]

This reduces temporary byte array creation during p/invoke string param marshaling.

What's the signature you have encountered it with? Have you considered switching to LibraryImport to fix the problem? How does LibraryImport perf compare to what you get with this fix for the signature you have hit the problem with?

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

[HJLeee]

What's the signature you have encountered it with? Have you considered switching to LibraryImport to fix the problem? How does LibraryImport perf compare to what you get with this fix for the signature you have hit the problem with?

Thank you for LibraryImport tip.
Tizen applications and custom libraries still use DllImport directly as they should be built on .NET 6 base env. for compatibility in production.

We are trying to reduce GC count/pause during UI drawing and the temporary byte arrays during p/invoke are the top most garbage creation in System.Byte[] type.
(Let me put screenshot of nettrace after I clear internal firewall.)
I thought this could be easily reduced thanks to ArrayPool.

[huoyaoyuan]

Tizen applications and custom libraries still use DllImport directly as they should be built on .NET 6 base env.

Updating main branch would not improve .NET 6 environment. Such performance change typically doesn't meet the bar for backport. Moreover, 6.0 has reached EOL. If you provide your build, you can do update in your branch.

[HJLeee]

We'll use .NET 10 next year (hopefully)

[AaronRobinsonMSFT]

We'll use .NET 10 next year (hopefully)

At that point then LibraryImport can be used. I do not think it is appropriate to start changing these marshallers without clear and convincing data that it will substantially improve them. Additionally, if string marshalling is an issue, then I would consider doing manual marshalling where full control can be achieved. That is possible with DllImport already.

[agocke]

Closing, as we are unlikely to take any changes here.

[HJLeee]

Thank you for the time and consideration.