Nope, interned strings are no longer in PermGen since "forever" http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6962931. Also if you really care about this you'd likely be better of running Java 8u20 or later which automatically deduplicates Strings.

Reasons for running with -XX:MaxPermSize=1G that I can imagine:

  * you run Java 7 (which goes EOL in March)
  * and one of those:
    * your code base is twice as large as Eclipse and JBoss combined
    * you have a PermGen leak
    * you have no idea what you're doing

See https://blogs.oracle.com/jonthecollector/entry/presenting_th....

How the JVM handled class metadata changed in Java 8; the MaxPermGen argument is ignored on that version (http://java.dzone.com/articles/java-8-permgen-metaspace).

P.S. According to that second link, interned strings haven't been stored in the permanent generation since Java 7.

The code doesn't look optimized with respect to reflection (i.e. avoiding it); maybe a lot of gc churn as well. The latter is a fact of life if you do lots of computations with lots of immutable collections, so it's important to identify parts which can be refactored to use Clojure transients and/or other mutable objects, but without "polluting" the entire program with mutable state.

Oh, good point on the reflection optimisation. That will definitely be useful for squeezing a bit more performance out of the graphics. Will be interesting to profile and see where the pain points are. From my experience the worst performance points are within Bukkit and occur when any block has gravity calculations to perform. I purposely avoided lava + water due to this.