Create a new version of paste:

#!/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