Test fails with `Java.Lang.OutOfMemoryError: C heap space` on Oracle 17

[masesdevelopers]

Describe the bug
Some tests fails with the error Java.Lang.OutOfMemoryError: C heap space

To Reproduce
Steps to reproduce the behavior:

1. Run build.yaml
2. Wait end of execution
3. Scroll down list of results
4. See error (https://github.com/masesgroup/KNet/actions/runs/17715865354)

Expected behavior
The tests shall work for every JDK distribution tested

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• OS
  • Windows - Version: [e.g. Windows 11]
  • MacOS - Version: [e.g. 14]
  • Linux
    • Distribution: Ubuntu or other
    • Version: GitHub version
• .NET
  • .NET Framework
  • .NET 8
  • .NET 9
• JVM
  • Oracle - Version: 17
  • GraalVM - Version: [e.g. 11]
  • Temurin - Version: [e.g. 11]
  • Zulu - Version: [e.g. 11]
  • Microsoft - Version: [e.g. 11]
  • Corretto - Version: [e.g. 11]
  • Other
    • Distribution:
    • Version:

Additional context
See masesgroup/JNet#717 for another error with Oracle 17

[masesdevelopers]

Seems that the exception is raised when it is enabled the usage of *Buffer classes (ByteBuffer, IntBuffer, end so on) even increasing the Heap memory allocated at application startup.

[masesdevelopers]

.NET Framework reports the following callstack:

Failed with Java.Lang.OutOfMemoryError: C heap space
   at MASES.JCOBridge.C2JBridge.JVMInterop.JavaObject.InvokeWithSignature(String methodName, String signature, Object[] args, Object& result)
   at MASES.JCOBridge.C2JBridge.JVMInterop.JavaObject.InvokeWithSignature(String methodName, String signature, Object[] args)
   at MASES.JCOBridge.C2JBridge.JCOBridgeDirectBuffer`1..ctor(IJavaObject jvmObject, IntPtr memoryPointer, Int64 capacity, Int64 limit)
   at MASES.JCOBridge.C2JBridge.JVMInterop.JVMWrapper.GetDirectBuffer[T](IJavaObject obj, IntPtr dataPointer, Int64 capacity, Int64 limit)
   at MASES.JCOBridge.C2JBridge.JVMInterop.JVMWrapper.NewDirectBuffer[T](T[] data, Boolean useMemoryControlBlock, Int64 currentCapacity, Int64 limit, MemoryStream stream, EventHandler`1 disposeEvent, Int32 ttl)
   at MASES.JCOBridge.C2JBridge.JVMInterop.JVMWrapper.NewDirectBuffer(MemoryStream stream, Boolean useMemoryControlBlock, EventHandler`1 disposeEvent, Int32 ttl)
   at Java.Nio.ByteBuffer.From(MemoryStream stream, Boolean useMemoryControlBlock, EventHandler`1 disposeEvent, Int32 timeToLive)
   at MASES.KNet.Producer.KNetProducer`4.DataSerialize[T,TJVMT](ISerializer`2 serializer, String topic, T data, Headers headers) in /_/src/net/KNet/Specific/Producer/KNetProducer.cs:line 315
   at MASES.KNet.Producer.KNetProducer`4.ToProducerRecord(ProducerRecord`4 record, ISerializer`2 keySerializer, ISerializer`2 valueSerializer) in /_/src/net/KNet/Specific/Producer/KNetProducer.cs:line 302
   at MASES.KNet.Producer.KNetProducer`4.Send(ProducerRecord`4 record) in /_/src/net/KNet/Specific/Producer/KNetProducer.cs:line 325
   at MASES.KNetTest.Program.ProduceSomethingBuffered() in /_/tests/net/General/KNetTest/Program.cs:line 582
   at MASES.KNetTest.Program.Main(String[] args) in /_/tests/net/General/KNetTest/Program.cs:line 149

which clarify the source of the error.

[masesdevelopers]

Apply the solution of masesgroup/JNet#717 (comment)

[masesdevelopers]

Seems that the exception is raised when it is enabled the usage of *Buffer classes (ByteBuffer, IntBuffer, end so on) even increasing the Heap memory allocated at application startup.

masesgroup/JNet#717 and masesgroup/JNet#722 are both related to the hypothesis above; the issue are closed with the last update of JCOBridge, so it is possible to avoid #1141 when a new version of JNet will be available