Clojure and Overtone Driving Minecraft | Hacker News Reader

Clojure and Overtone Driving Minecraft

blog.josephwilk.net

71 pointsmichaelsbradley15 comments

Open articleView on HN

Seems that your SSL certificate is untrusted. Is this intentional (personally signed?) or an error?

If you look at the certificate, it's issued to *.herokuapps.com, which indicates he's hosting it on Heroku.

> java -XX:MaxPermSize=1G

Really? I mean really?

New to java, but just wondering ... would that be due to intern()-ing (strings/symbols/etc.)?

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.

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.

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

Spigot complains if you launch with the default MaxPermSize. The developers there could make better suggestions as to why thats the case.

Spigot warning: ``` Warning, your max perm gen size is not set or less than 128mb. It is recommended you restart Java with the following argument: -XX:MaxPermSize=128M Please see http://www.spigotmc.org/wiki/changing-permgen-size/ for more details and more in-depth instructions. ```

There is almost an order of magnitude difference between 128MB and 1GB.

Good point, I'll update it to be more conservative for other people trying this out.

Yeah, don't do that. Run SpigotMC under Java 8 with the following flags:

-d64 (force a 64-bit data model, although usually this isn't necessary)

-server (use the server-optimized JVM instead of the desktop-optimized one, again, may not be necessary)

-Xmx1G (start with this heap memory limit and increase if necessary)

-XX:+UseConcMarkSweepGC (for multithreaded GC)

-XX:+CMSIncrementalMode (only use on computers that support 1 or 2 hardware threads)

-XX:+AggressiveOpts (enables additional JVM optimizations)

There's a ton of bad advice out there when it comes to JVM configuration and Minecraft. The above comes from my understanding of this somewhat dated Java GC tuning guide (http://www.oracle.com/technetwork/java/gc-tuning-6-140523.ht...) and sk89q's excellent Minecraft server tuning guide (http://www.sk89q.com/2013/03/improving-your-minecraft-server...), coupled with small-scale server profiling on my part.

I though that

  -XX:+AggressiveOpts

is a noop these days.

It depends on the JVM release. On my Windows 8.1 laptop running 1.8.0_31,this flag increases AutoBoxCacheMax from 128 to 20000 (which affects autoboxing and collections performance), and it lowers BiasedLockingStartupDelay from 20000 to 500 (which can effect multithreaded access to shared data - see http://www.oracle.com/technetwork/java/tuning-139912.html#se... for more details).

It isn't strictly necessary, but if you're trying to squeeze every possible drop of performance out of your Minecraft server, the experimental optimizations aren't a bad thing to enable. I will admit to doing only informal performance testing when it comes to the AggressiveOpts flag.

Thats really helpful, thanks! Will give it a try.

Reply on news.ycombinator.com