5 ms·

> java -XX:MaxPermSize=1G Really? I mean really?

by needusername 12y ago

malkia 12y ago
New to java, but just wondering ... would that be due to intern()-ing (strings/symbols/etc.)?
- michaelsbradley 12y ago
  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.
  - josephwilk 12y ago
    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.
- xenophonf 12y ago
  See https://blogs.oracle.com/jonthecollector/entry/presenting_the_permanent_generation 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 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.
- needusername 12y ago
  Nope, interned strings are no longer in PermGen since "forever" http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6962931 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
  - deleted 12y ago
    [deleted]
josephwilk 12y ago
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/ http://www.spigotmc.org/wiki/changing-permgen-size/ for more details and more in-depth instructions. ```
- needusername 12y ago
  There is almost an order of magnitude difference between 128MB and 1GB.
  - josephwilk 12y ago
    Good point, I'll update it to be more conservative for other people trying this out.
xenophonf 12y ago
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.html 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-servers-performance/ http://www.sk89q.com/2013/03/improving-your-minecraft-server...), coupled with small-scale server profiling on my part.
- needusername 12y ago
  I though that -XX:+AggressiveOpts is a noop these days.
  - xenophonf 12y ago
    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#section4.2.5 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.
- josephwilk 12y ago
  Thats really helpful, thanks! Will give it a try.

> java -XX:MaxPermSize=1G Really? I mean really?

malkia 12y ago

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

michaelsbradley 12y ago
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.
- josephwilk 12y ago
  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.
xenophonf 12y ago
See https://blogs.oracle.com/jonthecollector/entry/presenting_the_permanent_generation 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 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.
needusername 12y ago
Nope, interned strings are no longer in PermGen since "forever" http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6962931 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
- deleted 12y ago
  [deleted]

josephwilk 12y ago

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/ http://www.spigotmc.org/wiki/changing-permgen-size/ for more details and more in-depth instructions. ```

needusername 12y ago
There is almost an order of magnitude difference between 128MB and 1GB.
- josephwilk 12y ago
  Good point, I'll update it to be more conservative for other people trying this out.

xenophonf 12y ago

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.html 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-servers-performance/ http://www.sk89q.com/2013/03/improving-your-minecraft-server...), coupled with small-scale server profiling on my part.

needusername 12y ago
I though that -XX:+AggressiveOpts is a noop these days.
- xenophonf 12y ago
  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#section4.2.5 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.
josephwilk 12y ago
Thats really helpful, thanks! Will give it a try.