Java is mature and regarded as high performance, even if it is a memory glutton.
(I also don't really think Java is that much slower but substitute a more precise guess and my statement stands. And I think Java and other GCed languages really do use ~2X as much RAM which is also unacceptable.)
Using Java over C++ would have meant a factor of 2 up-front performance cost. But it would also have meant significantly less time debugging, easier testing, faster iteration, better automated refactoring support... all of which would have added up to being able to spend more development effort finding the kind of algorithmic improvements that give you those 1000x speedups. I'm not at all convinced that the end result would have been slower.
Over sufficiently long runs, throughput is easily within the factor of 2 you mentioned. But over short timescales, thousands of times slower is completely plausible. Some C++ CLI application might run in 5 ms where the equivalent Java program takes 5 seconds.
IIRC there was some article recently challenging the assumption that Java programs commonly reach the optimized steady state at all. I can't find it though.
[1] Except V8 of course on the user-supplied JavaScript. I'd call that quite different than optimizing all Chrome's own code.
In the context of something like Chrome that's already willing to implement a custom process model, I don't think that there are business requirements where that kind of large overhead is unavoidable. Running an individual unix-style JVM process can indeed perform very poorly on the default settings. But that's not the only way to build a web browser.
And the gap is getting _wider_ as Java is an increasingly bad fit for modern CPUs due to the heavy pointer chasing nature of it. It desperately needs value types to stay competitive in a performance battle.