[GR-55097] Link update in native-image/Resources.md.

PullRequest: graal/18217

Author: olyagpl

docs/reference-manual/native-image/Resources.md

@@ -20,7 +20,7 @@ There are several ways a resource can be registered for inclusion and be made ac
 
 A resource configuration file contains information about the resources that you need to include in a native executable, encoded with patterns matching actual resources on your file system.
 Such a configuration file has to be named _resource-config.json_ and placed in the _META-INF/native-image/_ directory so that `native-image` will automatically make use of it.
-You can either generate it using the [Tracing Agent](AutomaticMetadataCollection/#tracing-agent), and then manually refine it, or create it from scratch.
+You can either generate it using the [Tracing Agent](AutomaticMetadataCollection.md#tracing-agent), and then manually refine it, or create it from scratch.
 You can choose one of the formats to specify the required resources (or combine them if necessary):
 1. Globs (**recommended**)
 2. Regular expressions (Regex) (**discouraged**)
@@ -56,7 +56,7 @@ Alternatively, the configuration file's path can be passed to `native-image` usi
 ### Globs
 
 You can write a glob pattern to specify any required resources in the `globs` section of the configuration file.
-Also, if you use the [Tracing Agent](AutomaticMetadataCollection/#tracing-agent) to generate the required configuration, it prints all entries in this format.
+Also, if you use the [Tracing Agent](AutomaticMetadataCollection.md#tracing-agent) to generate the required configuration, it prints all entries in this format.
 
 Globs are the recommended way to provide resources for `native-image` because they:
 * Have custom handling in `native-image` that can speed up a resource registration process

docs/reference-manual/native-image/guides/specify-class-initialization.md

@@ -119,11 +119,14 @@ The parser creates records and adds them to a `List<Talk>` collection.
     - Bootiful Spring Boot 3 by Josh Long
     ./buildtime-parser  0.00s user 0.00s system 53% cpu 0.016 total
     ```
+
     Check the file size which should decrease to around 6.4M!
-    ```
+    ```bash
     du -sh buildtime-parser
     ```
+
     The file size change is because Native Image runs the static initializer at build time, parsing the text block, and persisting only the `Talk` records in the executable.
+    
     As a result, the majority of the scanning infrastructure does not become reachable when Native Image statically analyzes the application and is, therefore, not included in the executable.
 
 Another valuable criterion for profiling applications more accurately is the number of instructions, which can be obtained using the [Linux `perf` profiler](../PerfProfiling.md).
@@ -164,6 +167,7 @@ Talks loaded using scanner:
 
 This demonstrates how Native Image can shift work from runtime to build time: when the class is initialized at build time, the text block is parsed when the executable is being built and only the parsed objects are included.
 This not only makes the executable smaller in file size, but also faster to run: when the executable runs, the `Talk` records already exist and only need to be printed.
+<br>
 
 To ensure native executables built with Native Image are as compatible as possible with the HotSpot behavior, application classes that cannot be safely initialized at build time, are initialized at runtime.
 You as a user, or a framework that you use, must explicitly request build-time initialization for certain classes to benefit from smaller file sizes and faster times to run.