How to revise "Pinning cases" section?

docs/src/main/asciidoc/virtual-threads.adoc

@@ -122,21 +122,21 @@ So, there is a memory cost associated with this creation.
 Suppose you run in a constrained environment, such as containers. In that case, monopolization can quickly become a concern, as the high memory usage can lead to out-of-memory issues and container termination.
 The memory usage may be higher than with regular worker threads because of the inherent cost of the scheduling and virtual threads.
 
-[[pinning]]
-==== Pinning cases
-The promise of "cheap blocking" might not always hold: a virtual thread might _pin_ its carrier on certain occasions.
-The platform thread is blocked in this situation, precisely as it would have been in a typical blocking scenario.
-
-According to link:{vthreadjep}[JEP 425] this can happen in two situations:
-
-- when a virtual thread performs a blocking operation inside a `synchronized` block or method
-- when it executes a blocking operation inside a native method or a foreign function
-
-It can be reasonably easy to avoid these situations in your code, but verifying every dependency you use is hard.
-Typically, while experimenting with virtual threads, we realized that old versions of the link:{pgsql-driver}[postgresql-JDBC driver]
-results in frequent pinning.
-Most JDBC drivers still pin the carrier thread.
-Even worse, lots of widespread libraries are pinning and would require code changes.
+// [[pinning]]
+// ==== Pinning cases
+// The promise of "cheap blocking" might not always hold: a virtual thread might _pin_ its carrier on certain occasions.
+// The platform thread is blocked in this situation, precisely as it would have been in a typical blocking scenario.
+//
+// According to link:{vthreadjep}[JEP 425] this can happen in two situations:
+//
+// - when a virtual thread performs a blocking operation inside a `synchronized` block or method
+// - when it executes a blocking operation inside a native method or a foreign function
+//
+// It can be reasonably easy to avoid these situations in your code, but verifying every dependency you use is hard.
+// Typically, while experimenting with virtual threads, we realized that old versions of the link:{pgsql-driver}[postgresql-JDBC driver]
+// results in frequent pinning.
+// Most JDBC drivers still pin the carrier thread.
+// Even worse, lots of widespread libraries are pinning and would require code changes.
 
 [[pooling]]
 ==== The pooling case