From a practical viewpoint, there are only a couple of real implementations that currently exist: Microsoft's C++/CLI and (sort of) Clang/LLVM. As already mentioned, C++/CLI isn't really exactly C++. In theory, it's C++ with an almost-conforming set of extensions; practically, almost no real C++/CLI code is compatible with C++, so its being nearly conforming makes little real difference. Likewise, despite the name, LLVM isn't so much a virtual machine as a set of tools for creating virtual machines. As such, Clang/LLVM isn't so much an implementation as a toolkit that could be used to create such an implementation.
From a theoretical viewpoint, there's honestly not as much real controversy as it might look like. What's actually happened is pretty simple: Java advocates (it seems to be mostly Java advocates, anyway) spent years trying to come up with benchmarks that would show Java beating C and/or C++. In a few cases, they doctored benchmarks in pretty obvious ways to get the results they wanted, but they had to manipulate the benchmarks in pretty obvious ways to accomplish that. Since they couldn't get the results they wanted from real code, they started to follow an alternate route: writing about the possibility that a JIT could give performance benefits under at least some circumstances.
In doing this, however, they generally ignored one crucial point: the majority of optimization is independent of the target processor -- especially the most important (and, unfortunately, the most expensive) optimizations. This means JIT compilers have relatively little benefit compared to up-front compilers (even in theory), and they have a fairly high cost compared to up-front compilers, because the user has to wait while any expensive optimization happens. Because of that, most JIT compilers are pretty much forced to skip doing the most expensive optimizations, because in nearly every case they cost more than they (even hope to) gain. In the case of an up-front compiler, you can amortize the cost of that expensive optimization across many executions, but with a JIT compiler you have to repeat it at (essentially) every execution instead. As a result optimizations that are entirely practical for an up-front compiler become completely useless for a JIT compiler.