I think both have different pros.
Java has higher peak JIT performance though after Rosalyn was introduced C# has made strides at closing that gap on many metrics.
GC algorithms are more advanced, namely ZGC and Shenandoah. I would elaborate but I don't want to turn this post into an actual essay.
JVM is more configurable. This is a double edged sword, it heavily favors users that have spent the time to really understand the platform but it has created a reputation of the JVM being hard to operate.
JVM class loaders and the new(ish) Jigzaw module system are very powerful, especially for shipping customized/cut-down JVM + stdlib when you need to do distribution.
JVM has better portability. .NET Core has obviously changed the game but other platforms are still treated second class to Windows in many ways.
GraalVM is reviving the guest language ecosystem of the JVM. Clojure, Scala and Kotlin have all remained reasonably strong but there was a dark period there for Jython/JRuby and friends. GraalVM is changing the tide here and I have already been able to leverage this over Nashorn to embed essentially native speed JS code into one of my Java programs.
CLR has better primitive types, JVM's project Vahalla may resolve this.
The CLR/.NET tends to introduce features at a quicker pace than the JVM/Java, this I feel is CLR's double edged sword. Async/await being the key example. It's been in the CLR for what feels like forever now vs JVM which is only now just getting close to landing Loom. However I feel like Loom is an infinitely better solution to the problem that leverages the unique advantages of JIT compiled VM languages that rely on relatively little unmanaged code.
The experience on the CLR is much more integrated assuming you are on the well trodden path. i.e VS + Windows 10.
MSIL is much much more pleasant than JVM bytecode in my experience and the community developed tooling for working with it is great.
Optimizing programs on CLR is easier than JVM, it takes comparatively less effort to write allocation free code and get great memory layout using primitive arrays etc for high performance code.
CLR interacts better with native code. JNI is poor in comparison. Project Panama could make this better on the JVM side.
This is by no means a complete list of ways the two differ, this is just my experiences having written a decent chunk of code for both.
FWIW I prefer the JVM but if I am forced not to use the JVM the CLR is the very next thing I propose.