Rarely are pointers 64-bit in Java objects

They have been doing this for quite some time and explain it here: https://wikis.oracle.com/display/HotSpotInternals/CompressedOops

forces the compiler to generate abstract code to call the correct function at run-time that tells me they probably aren't really thinking the problem through

So, the overhead you are talking about is essentially a vtable resolution? This isn't that they haven't thought the program through (since the operation still needs to be defined on the type), but that there is a generic operation being performed on a bunch of concrete implementations. That said, this doesn't come up all that often since, as you mentioned you "should already know your data and what operations are going to be done on it". Just "not knowing" isn't really the reason you do this in Java (some other languages seem to like this but Java doesn't lend itself to that kind of behaviour).

Completely irrelevant and off-topic

No, it is on-topic since you were talking about the cost of tracking a root set. My point was that it isn't much beyond what you would see anywhere else.

... and how exactly do you do that again? Right, you walk the tree from the root. Pointer fetch, potential I$ & D$ cache hit, etc., these are all over-head that is completely unnecessary when you use a (homogeneous) memory pool.

So, your concern isn't about GC, per se, but just any code running which is not directly related to the critical path? As long as you can keep your scope small (everything on the stack, for example), then you can do this well in native environments. As soon as you go outside of that domain, though, you are now doing some extra work and your locality will be poor. A GC can resolve this problem and do so dynamically. The benefits of this become more apparent as systems get larger since there is more of a problem which can be solved this way. Again, it really depends on what you are comparing this to, though: a single thread running in a tight loop, only operating on stack-allocated data will be hard to beat since it is already theoretically optimal, whereas a multi-threaded process dynamically allocating and passing work units around (potentially across NUMA nodes) will benefit substantially from a managed heap and GC.

Bringing this back on topic ... we're talking about games and Java. What is your experience shipping games again?

I am not a game developer, but I do a lot of low-level development, and have worked in a bunch of different languages, so I am challenging your broad claims. This isn't really supposed to be an "ad hominem" situation but you did fail to understand my point about the importance of arguing points, not people.

since Java isn't even available for consoles, for security[1] and performance reasons

So, this console issue is your actual concern? We are talking about desktop systems for this launcher. Besides, the real reason it isn't there is probably licensing. In fact, it was on the PS3. Performance shouldn't be this monumental issue (as we have discussed) and security is more just because we view "Java" as a monolithic thing. If you were to roll-up every security concern for an entire base OS (including user-space libraries, but probably not applications), then you would see that everything is insecure. Most environments where I have worked don't allow anything which isn't related to the core task on their systems or even inside their network for some combination of licensing and security concerns. That said, they all had substantial Java installations since that was related to their core businesses.