The inherent problem is the garbage collector. It's non-deterministic- something that UHF can never cope with. Working around this issue is basically equivalent to re-inventing native allocators. Moreover, the language carries a lot of intrinsic overhead that cannot be reduced, where C++'s constructs are directly more efficient- for example, a Java member variable has to be another reference, even if in reality it could be allocated as part of the block, which is how it's done in C++. This enforces extra indirection/cache overhead/etc. This means that a Java UHF program would be inherently significantly harder to write, for poorer results, than a C++ equivalent.
Fundamentally, high performance determinism is in the design of C++. It's not in the design of Java.
Edit: What I meant by "part of the block". In C++, a class or struct is allocated as one, single, big chunk- effectively, it's an array. This means that indexing into that array almost arbitrarily is pretty much free- that is, accessing a member variable in C++ is equivalent to an array index, for any nesting. In Java, however, every member variable of class type must be pointed to. This means that classes in Java necessarily form linked lists, which are massively slower to access. Every member variable you access in Java is a pointer de-reference, which is terribly slow in comparison. Now, in C++, if you need it, you can make pointers members and access through them, but in Java there's no equivalent option to make members into an array. This means that Java enforces the slower, linked-list access semantics. The same principle applies for many other similar cases.
And a concurrent GC is only going to help with a non-maximally-concurrent program. If you have a program that's using 100% CPU, there's no way to GC it without reducing the amount available for the program.