We have had a few customers run into this issue where they are using the J# ThreadEnd objects and see problems with the GC running a lot. If you look at the actual callstack that is calling the GC, it will be the finalizer thread cleaning up this ThreadEnd as we see here:
0:036> k Child-SP RetAddr Call Site 05cef478 00000000`1bf31dc5 mscorwks!GCInterface::CollectGeneration 05cef480 00000642`7f66bdc6 vjslib_ni!com.ms.vjsharp.lang.ThreadEnd.Finalize()+0x35 05cef4e0 00000642`7f4ebf2b mscorwks!FastCallFinalizeWorker+0x6 05cef510 00000642`7f4ec075 mscorwks!FastCallFinalize+0xbb 05cef590 00000642`7f4f16e2 mscorwks!MethodTable::CallFinalizer+0x69 05cef5e0 00000642`7f4f1524 mscorwks!SVR::CallFinalizer+0x72 05cef640 00000642`7f4f146b mscorwks!SVR::DoOneFinalization+0x84 05cef700 00000642`7f61fb1b mscorwks!SVR::FinalizeAllObjects+0x9b 05cef7c0 00000642`7f5264cc mscorwks!SVR::FinalizeAllObjects_Wrapper+0x1b 05cef7f0 00000642`7f52693d mscorwks!ManagedThreadBase_DispatchMiddle+0x12c 05cef900 00000642`7f608455 mscorwks!ManagedThreadBase_DispatchOuter+0x31 05cef940 00000642`7f4a71bc mscorwks!ManagedThreadBase_DispatchInCorrectAD+0x15 05cef970 00000642`7f44b939 mscorwks!Thread::DoADCallBack+0xd0 05cefab0 00000642`7f4f15f6 mscorwks!ManagedThreadBase_DispatchInner+0x51 05cefb00 00000642`7f4f146b mscorwks!SVR::DoOneFinalization+0x156 05cefbc0 00000642`7f4b679d mscorwks!SVR::FinalizeAllObjects+0x9b 05cefc80 00000642`7f5264cc mscorwks!SVR::GCHeap::FinalizerThreadWorker+0xbd 05cefcc0 00000642`7f52693d mscorwks!ManagedThreadBase_DispatchMiddle+0x12c 05cefdd0 00000642`7f463c36 mscorwks!ManagedThreadBase_DispatchOuter+0x31 05cefe10 00000642`7f4b6d64 mscorwks!ManagedThreadBase_NoADTransition+0x42
From this we can see that the Finalize method of ThreadEnd is calling the collection. This is something that these threads do.
The only way around this, if this is causing a problem, is to switch from using Java threads to .NET Threads instead as they don't call GC.Collect().
This problem has been mentioned a few times, including on Maoni's blog