I don't think it would be that much helpful. Emulators usually struggle with speed, not with memory or slow start. The execution speed wasn't measured in the benchmark for good reason. Normally JIT compiled Java performs adaptive optimizations and the execution speed can become faster so it better suits program's real execution profile.
You might ask: why not run the program on real life input, save the execution profile and optimize GraalVM output depending on that? Indeed that is possible. But Oracle keeps that part of GraalVM proprietary (in fact selling such improvements are probably the most important part of their GraalVM related business, Oracle is not one of those companies which would make open source software just to be nice).
Of course benefit of such optimizations is minimal for containerized server applications that GraalVM is mainly used for, because they are not CPU bound, so for normal users it doesn't really matter. But I think that emulator is one of things where it would actually matter quite a lot.
You might ask: why not run the program on real life input, save the execution profile and optimize GraalVM output depending on that? Indeed that is possible. But Oracle keeps that part of GraalVM proprietary (in fact selling such improvements are probably the most important part of their GraalVM related business, Oracle is not one of those companies which would make open source software just to be nice).
Of course benefit of such optimizations is minimal for containerized server applications that GraalVM is mainly used for, because they are not CPU bound, so for normal users it doesn't really matter. But I think that emulator is one of things where it would actually matter quite a lot.