Start up "Minecraft" with memory allocation for dynamic maps

#!/bin/bash
# Startup for minecraft when using a lot of memory for
# dynamic maps for re-rendering.

cd "$( dirname "$0" )"

# This is set for 2-3 players.
## Important: Higher "New" / "Eden" generally improves performance with little to no penalty.
## Garbage collection in Eden depends on the living objects (which are important), not on junk.
## Higher heap/"tenured" means longer garbage collections. Garbage collecting here depends on
## the size of tenured space -- so the more junk, the longer.
##

unused="\
    -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution \
    -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -Xloggc:GC.log \
    -XX:+CITime -XX:+PrintCompilation \
    -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses \
    -XX:+TraceClassLoading -XX:+TraceClassUnloading \
"

# 7% min free is too low.
# No indication that "max free" is even listened to -- I've never seen the heap shrink.

# Remember the goal: Memory when needed, but keep the number of pages allocated low enough that
# swap does not clobber the other running programs.
#
# If you have a 1 or 2 processor system: add incremental.
# ** UPDATE: Looks like incremental may help a lot more than it should.
# Need to test -- one feedback so far that it makes big help on a 8 CPU system
#
# Dynamic map wants a very large amount. It looks like it wants survivor size
# of at least 40 *2 = 80 mib; that's up from the previous 12.5.
# Correction: During render, it wants at least 60, if not 70 * 2 = 120 to 150 mib. For both survivors,
# plus another 400+ for eden. That's crazy.
#
# Update: At least 100 MB during render, for temporaries. So survivor space of 200 MB...
#
# The best way to think of "survivor size": How much temporary stuff will you have at a time. If you use
# more temporary stuff than this, some of it will be considered "permanent".
#
# Old was: New 100, survivor 6, so 6+2=8 pieces. Each is 12.5. Target survivor is half that -- 6.25. We want 35
# instead of 6.25, or 70 instead of 12.5. Thats ... a lot.
#
# If we have 6 pieces -- 2 survivors, and 4 for eden -- and each piece is 70, that's 420Mib for new.
# Survivor ratio is 6-2 = 4.
#
# If you don't like doing that calculation, tell oracle to fix sun's old stuff.
# So lets see if we can play with dynmap.
# 200 per survivor, 600 for eden.
# That's 1 gig for new, survivor ratio 3.

#   -Xms165m -Xmx500m \
#   -XX:NewSize=100m -XX:SurvivorRatio=6 \

java \
    -d32 -server \
    -XX:CompileThreshold=3000 \
    -XX:+UseConcMarkSweepGC -XX:+UseParNewGC \
    -XX:MaxHeapFreeRatio=20 \
    -XX:MinHeapFreeRatio=12 \
    -XX:NewSize=1g -XX:SurvivorRatio=3 \
    -Xms1300m -Xmx2000m \
    -XX:MaxTenuringThreshold=4 \
    -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution \
    -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -Xloggc:GC.log \
    -jar server-myst-ebxl.jar nogui test144-final

exit 0

# -XX:ParallelCMSThreads=n

# Comments for that java line: ** WARNING -- BADLY OUT OF DATE **
java \
    -d32 -server \              # For up to 2.5 GB servers
    -XX:+UseConcMarkSweepGC -Xincgc \   # define the garbage collector
    -XX:ParallelGCThreads=4 \       # Parallel GC
    -Xms300m -Xmx1g \           # Start the server with 300MB. Go up to 1 GB.
    -XX:NewSize=300m \          # Use 300 MB for "new" (eden plus survivor spaces).
                        # This means about 650 MB max for long-term.
                        # Observed behavior is around 350mb long-term when the server is stable.

# Things to figure out:
# How much memory to give to eden (for new and short lived objects) versus survivor
# How many times an object "survives" before being promoted
# Tune for the "normal" case of players moving over approximately a 3x3 to 5x5 chunk area
# (Remember, the game loads r=9 chunks around you for normal (that's 17x17 chunks)
# up to r=15 for far (31x31!!!!) for far. Yes, you can and probably will move to new areas
# and flush it all, but that is rare. Tune for the common.
# Keep in mind: 31x31 * 16x16 * 80 (average world height) * 4 bytes per location
# is 75MiB! -- 16x16x4 = 1MiB, 31*31*80 is 76880
# That's minimum long-term memory just for sitting in one chunk
# Now consider that each time you change a chunk boundary, 16x16x4 x 31x80 -- one row of 31 new chunks
# is loaded into short term space -- 2MB added to short term/removed from long term every time you move a little.
#
# Now consider that 4 bytes per location is probably a low estimate.
# And, this doesn't take into account animals living in those chunks
# Animals = longterm, hostile mobs = short term.
# A large farm will raise this amount.
#
# Bottom line: Moving over 40x40 blocks in your base can be 4 chunks by 4 chunks
# or approximately 16 rows of new data. That's about half of the long-term data for sitting still.

    -XX:+PrintGCHeapAtGC -XX:+PrintTenuringDistribution -XX:MaxTenuringThreshold=6 \
    -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -Xloggc:GC.log \ # Log and collect info
    -XX:PermSize=65m -XX:MaxPermSize=95m \  # Classes, VM overhead, etc. Raise this if you add mods.
    -jar server-myst-ebxl.jar nogui main    # The server file

## java -Xms1250m -Xmx1250m -d32 -server -XX:+PrintGCHeapAtGC -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -Xloggc:GC.log -XX:+PrintGCTimeStamps -jar server-myst-ebxl.jar nogui main

## -XX:ParallelGCThreads=8 -XX:+TraceClassUnloading -XX:+UseParallelGC
# -Xms1g -Xmx1g -XX:PermSize65m -XX:MaxPermSize65m -Xmn100m