Hacker News new | ask | show | jobs
by custardcream 4237 days ago
I'll add something here. The CLR is a PITA when it goes wrong. Its a total bastard to debug. JVM on the other hand has wonderful instrumentation capabilities at runtime.

At best you get a minidump out of a CLR process that is misbehaving and take it to bits inside VS. You may or may not catch it doing bad things. Most likely you'll find yourself with half the threads inside win32 and an 20 mins wait for symbol server to snag the symbols.
2 comments
c0brac0bra 4237 days ago
100000x this. While trying to track down a memory leak I discovered that while pretty much any guide out there on the internet points to using WinDg and referencing a Microsoft site for the symbol files, the .pdb doesn't actually exist.

As far as I can tell the symbol files got removed with one of the 4.5.x releases, and as early as June people were asking about them: https://social.msdn.microsoft.com/Forums/expression/en-US/7b...

Still no word... I'm no debugging expert, but it seems like you're SOL if you want to find a leak within managed code.

link
UK-AL 4237 days ago
Perfmon? Performance Counters? Tons of instrumentation for .net
link
custardcream 4237 days ago
That's of absolutely no use when the box is under heavy load. Perf counters just stop working.

We had a system wide thrashing problem with ReaderWriterLockSlim which doesn't work properly under load. Took 15 mins to log into the box to blast the process. Couldn't even get any performance info out of it. Happens on a JVM on Unix; no problem.

For ref the concurrent collections should not be trusted under heavy load in processes with more threads than CPUs. Its to be honest piss poor quality.

link