Merge pull request #870 from unoplatform/dev/jela/mem-doc

docs: Update GC docs

doc/features-profiling.md

@@ -50,7 +50,7 @@ A WebAssembly app has multiple categories of allocated memory:
 - The managed memory usage, which is the smallest portion of the overall used memory. This is the memory directly done by object allocations from managed code. It is the memory reported by `mprof-report` or the Xamarin Profiler. This memory can be queried by using the [`GC.GetTotalMemory`](https://learn.microsoft.com/en-us/dotnet/api/system.gc.gettotalmemory).
 - The WebAssembly module memory usage, which is the overall app memory usage as far as WebAssembly is concerned. This is similar to the committed memory in a Windows app. This contains:
   - The runtime's own native memory allocations
-  - The Garbage Collector memory, which is [directly impacted](xref:Uno.Development.Performance#webassembly-specifics) by the [GC parameters](https://learn.microsoft.com/xamarin/android/internals/garbage-collection#configuration).
+  - The Garbage Collector memory, which is [directly impacted](xref:Uno.Development.Performance#webassembly-specifics) by the [MONO_GC_PARAMS parameters](https://github.com/dotnet/runtime/blob/0bfb733c6419e78e55286e0d01c5994a337c486a/docs/design/mono/mono-manpage-1.md#environment-variables). Note that the garbage collector over-allocates WebAssembly memory for performance reasons.
   - All the files located in the `Package_xxxx/managed` folder. Each assembly file is directly loaded in memory by the .NET runtime, regardless of it being used at the app's startup or not. Reducing the assemblies file sizes can be acheived by configuring the [IL Linker](xref:uno.articles.features.illinker).
 
   The WebAssembly memory can be queried using the following JavaScript expression: `globalThis.Module.HEAPU8.length`, which gives the allocated memory in bytes. You can use [`JSImport`](xref:Uno.Wasm.Bootstrap.JSInterop#invoking-javascript-code-from-c) to read it from managed code.