Description
Describe the bug
When the finalizer is called for CLR JvmObjectId objects, it calls the rm DotnetBackend method and this calls goes through the JvmBridge class. Because the rm call goes through JvmBridge.CallJavaMethod code path, it gets registered with JvmThreadPoolGC.TryAddThread.
Although this GC thread gets registered on the CLR side by the finalizer call, when the rm is handled by DotnetBackendHandler, it does not run in a org.apache.spark.api.dotnet.ThreadPool. On the CLR side there is a timer associated with JvmThreadPoolGC and when it runs, it attempts to call rmThread on any non-active threads. Because the finalizer's rm JVM call did not run in a org.apache.spark.api.dotnet.ThreadPool, the Java DotnetBackendHandler "rmThread" call will log an error and the CLR JvmThreadPoolGC will log a warning.
Although this won't cause applications to fail, it makes extra calls to the DotnetBackend as well as produce warning and error log lines which is not a good experience.