# Jvmargs, a sanity checker for JVM options

**URL:** <https://discourse.chef.io/t/jvmargs-a-sanity-checker-for-jvm-options/3775>\
**Category:** Chef Infra (archive)\
**Created:** [March 21, 2013, 8:53am UTC](https://discourse.chef.io/t/jvmargs-a-sanity-checker-for-jvm-options/3775 "2013-03-21T08:53:43Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bryan\_Berry](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/bryan_berry/32/213_2.png) [@Bryan\_Berry](https://discourse.chef.io/u/Bryan_Berry)\
**Post date:** [March 21, 2013, 8:53am UTC](https://discourse.chef.io/t/jvmargs-a-sanity-checker-for-jvm-options/3775/1 "2013-03-21T08:53:43Z")

</div>

hey folks,

i have written a little gem to parse JVM options and would love some  
feedback on it. Managing JVM options in a cookbooks is a total PITA  
and I hope this makes it easier. This is less than alpha quality, i am  
posting it here to get some feedback, not to notify others of a  
production-ready tool. I foresee it being used in Java-related  
cookbooks to provide a set of application-specific defaults and then  
make it easy to override or add to them in recipe code.

> **[bryanwb/jvmargs](https://github.com/bryanwb/jvmargs)**
>
> sane parser of java command-line arguments. Contribute to bryanwb/jvmargs development by creating an account on GitHub.

This library parses JVM options so that any given option is only  
stored once. It does this by breaking each option into one of the  
three option categories:

1. standard, ex: -server, -enablesystemassertions
2. nonstandard, ex: -Xmx128M, -Xint
3. unstable, ex: -XX:-DisableExplicitGC, -XX:AltStack=128M
4. directive, ex: -Dcom.sun.management.jmxremote

JVMArgs will ensure that only one value is stored for any given  
option. Here is a quick example

args = JVMArgs::Args.new("-XX:-DisableExplicitGC", "-Xmx256M")

# "-XX:-DisableExplicitGC" is now stored in args

args.add("-XX:+DisableExplicitGC")  
args.add("-Xmx2G")

# the settings are now "-XX:+DisableExplicitGC" and "-Xmx2G"

---

<div class="post-metadata">

**Author:** ![Jesse\_Campbell](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/jesse_campbell/32/251_2.png) [@Jesse\_Campbell](https://discourse.chef.io/u/Jesse_Campbell)\
**Post date:** [March 21, 2013, 1:18pm UTC](https://discourse.chef.io/t/jvmargs-a-sanity-checker-for-jvm-options/3775/2 "2013-03-21T13:18:37Z")

</div>

hey, been looking for something like this to come along, looks like a very  
clean, sane way to handle it 😃

in your todo you have ensure min and max heap should be the same. why is  
this?

i didn't dig to far into the code, but will it support parsing a space  
delimited string, as the current tomcat and tomcat6 cookbooks expect, or  
will the cookbook be expected to handle that?

thanks!

On Thu, Mar 21, 2013 at 4:53 AM, Bryan Berry [bryan.berry@gmail.com](mailto:bryan.berry@gmail.com) wrote:

> hey folks,
> 
> i have written a little gem to parse JVM options and would love some  
> feedback on it. Managing JVM options in a cookbooks is a total PITA  
> and I hope this makes it easier. This is less than alpha quality, i am  
> posting it here to get some feedback, not to notify others of a  
> production-ready tool. I foresee it being used in Java-related  
> cookbooks to provide a set of application-specific defaults and then  
> make it easy to override or add to them in recipe code.
> 
> [GitHub - bryanwb/jvmargs: sane parser of java command-line arguments](https://github.com/bryanwb/jvmargs)
> 
> This library parses JVM options so that any given option is only  
> stored once. It does this by breaking each option into one of the  
> three option categories:
> 
> 1. standard, ex: -server, -enablesystemassertions
> 2. nonstandard, ex: -Xmx128M, -Xint
> 3. unstable, ex: -XX:-DisableExplicitGC, -XX:AltStack=128M
> 4. directive, ex: -Dcom.sun.management.jmxremote
> 
> JVMArgs will ensure that only one value is stored for any given  
> option. Here is a quick example
> 
> args = JVMArgs::Args.new("-XX:-DisableExplicitGC", "-Xmx256M")
> 
> # "-XX:-DisableExplicitGC" is now stored in args
> 
> args.add("-XX:+DisableExplicitGC")  
> args.add("-Xmx2G")
> 
> # the settings are now "-XX:+DisableExplicitGC" and "-Xmx2G"

---

<div class="post-metadata">

**Author:** ![Bryan\_Berry](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/bryan_berry/32/213_2.png) [@Bryan\_Berry](https://discourse.chef.io/u/Bryan_Berry)\
**Post date:** [March 21, 2013, 1:31pm UTC](https://discourse.chef.io/t/jvmargs-a-sanity-checker-for-jvm-options/3775/3 "2013-03-21T13:31:12Z")

</div>

min and max should be the same because there is no benefit to having a  
lower min according to everything I have read. It can slow down your  
application startup however.

it will not support parsing a space delimited string, only the options  
specifically for the JVM, for example

"java -Djava.io.tmpdir=/tmp/foo -server -Xmx256m -Xint  
-XX:MaxPermSize=512M -classpath /tmp/foo.jar:/tmp/baz.jar  
org.apache.catalina.Bootstrap start "

jvmargs doesn't add the java binary to the beginning nor the  
"org.apache.catalina.Bootstrap start"

I do want to handle the classpath but i have not figured out a clean  
way to handle that yet ☹

i would very much appreciate feedback and testing. this afternoon i  
hope to add support for arbitrary rules like the following

"if Max heap is greater than available RAM, raise an error"  
"if Max heap is changed, also set Min heap to same value"

On Thu, Mar 21, 2013 at 2:18 PM, Jesse Campbell [hikeit@gmail.com](mailto:hikeit@gmail.com) wrote:

> hey, been looking for something like this to come along, looks like a very  
> clean, sane way to handle it 😃
> 
> in your todo you have ensure min and max heap should be the same. why is  
> this?
> 
> i didn't dig to far into the code, but will it support parsing a space  
> delimited string, as the current tomcat and tomcat6 cookbooks expect, or  
> will the cookbook be expected to handle that?
> 
> thanks!
> 
> On Thu, Mar 21, 2013 at 4:53 AM, Bryan Berry [bryan.berry@gmail.com](mailto:bryan.berry@gmail.com) wrote:
> 
> > hey folks,
> > 
> > i have written a little gem to parse JVM options and would love some  
> > feedback on it. Managing JVM options in a cookbooks is a total PITA  
> > and I hope this makes it easier. This is less than alpha quality, i am  
> > posting it here to get some feedback, not to notify others of a  
> > production-ready tool. I foresee it being used in Java-related  
> > cookbooks to provide a set of application-specific defaults and then  
> > make it easy to override or add to them in recipe code.
> > 
> > [GitHub - bryanwb/jvmargs: sane parser of java command-line arguments](https://github.com/bryanwb/jvmargs)
> > 
> > This library parses JVM options so that any given option is only  
> > stored once. It does this by breaking each option into one of the  
> > three option categories:
> > 
> > 1. standard, ex: -server, -enablesystemassertions
> > 2. nonstandard, ex: -Xmx128M, -Xint
> > 3. unstable, ex: -XX:-DisableExplicitGC, -XX:AltStack=128M
> > 4. directive, ex: -Dcom.sun.management.jmxremote
> > 
> > JVMArgs will ensure that only one value is stored for any given  
> > option. Here is a quick example
> > 
> > args = JVMArgs::Args.new("-XX:-DisableExplicitGC", "-Xmx256M")
> > 
> > # "-XX:-DisableExplicitGC" is now stored in args
> > 
> > args.add("-XX:+DisableExplicitGC")  
> > args.add("-Xmx2G")
> > 
> > # the settings are now "-XX:+DisableExplicitGC" and "-Xmx2G"

---

<div class="post-metadata">

**Author:** ![Jesse\_Campbell](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/jesse_campbell/32/251_2.png) [@Jesse\_Campbell](https://discourse.chef.io/u/Jesse_Campbell)\
**Post date:** [March 21, 2013, 1:44pm UTC](https://discourse.chef.io/t/jvmargs-a-sanity-checker-for-jvm-options/3775/4 "2013-03-21T13:44:51Z")

</div>

I've read plenty that suggests that depending on the situation, having  
different Xms and Xmx values can be beneficial.

i've seen things like this:

> **[Java Monitor - The Latest Java News](https://www.java-monitor.com)**
>
> Java is liked by many programmers and it always makes the top 10 in various lists about programming languages Java was first released in 1995 \[…\]

which suggest that setting them the same has no particularly beneficial  
effect.

and I've seen things like this:  
[http://weblogs.java.net/blog/kcpeppe/archive/2011/12/19/setting-xmx-xms-still-considered-harmful](http://weblogs.java.net/blog/kcpeppe/archive/2011/12/19/setting-xmx-xms-still-considered-harmful)  
which suggest that the ideal settings are for xms to be your 99% case, and  
xmx allow for some wiggle room

in fact, i haven't seen any really good recent analyses that support  
setting them the same, just lots of rhetoric

-jesse

On Thu, Mar 21, 2013 at 9:31 AM, Bryan Berry [bryan.berry@gmail.com](mailto:bryan.berry@gmail.com) wrote:

> min and max should be the same because there is no benefit to having a  
> lower min according to everything I have read. It can slow down your  
> application startup however.
> 
> it will not support parsing a space delimited string, only the options  
> specifically for the JVM, for example
> 
> "java -Djava.io.tmpdir=/tmp/foo -server -Xmx256m -Xint  
> -XX:MaxPermSize=512M -classpath /tmp/foo.jar:/tmp/baz.jar  
> org.apache.catalina.Bootstrap start "
> 
> jvmargs doesn't add the java binary to the beginning nor the  
> "org.apache.catalina.Bootstrap start"
> 
> I do want to handle the classpath but i have not figured out a clean  
> way to handle that yet ☹
> 
> i would very much appreciate feedback and testing. this afternoon i  
> hope to add support for arbitrary rules like the following
> 
> "if Max heap is greater than available RAM, raise an error"  
> "if Max heap is changed, also set Min heap to same value"
> 
> On Thu, Mar 21, 2013 at 2:18 PM, Jesse Campbell [hikeit@gmail.com](mailto:hikeit@gmail.com) wrote:
> 
> > hey, been looking for something like this to come along, looks like a  
> > very  
> > clean, sane way to handle it 😃
> > 
> > in your todo you have ensure min and max heap should be the same. why is  
> > this?
> > 
> > i didn't dig to far into the code, but will it support parsing a space  
> > delimited string, as the current tomcat and tomcat6 cookbooks expect, or  
> > will the cookbook be expected to handle that?
> > 
> > thanks!
> > 
> > On Thu, Mar 21, 2013 at 4:53 AM, Bryan Berry [bryan.berry@gmail.com](mailto:bryan.berry@gmail.com)  
> > wrote:
> > 
> > > hey folks,
> > > 
> > > i have written a little gem to parse JVM options and would love some  
> > > feedback on it. Managing JVM options in a cookbooks is a total PITA  
> > > and I hope this makes it easier. This is less than alpha quality, i am  
> > > posting it here to get some feedback, not to notify others of a  
> > > production-ready tool. I foresee it being used in Java-related  
> > > cookbooks to provide a set of application-specific defaults and then  
> > > make it easy to override or add to them in recipe code.
> > > 
> > > [GitHub - bryanwb/jvmargs: sane parser of java command-line arguments](https://github.com/bryanwb/jvmargs)
> > > 
> > > This library parses JVM options so that any given option is only  
> > > stored once. It does this by breaking each option into one of the  
> > > three option categories:
> > > 
> > > 1. standard, ex: -server, -enablesystemassertions
> > > 2. nonstandard, ex: -Xmx128M, -Xint
> > > 3. unstable, ex: -XX:-DisableExplicitGC, -XX:AltStack=128M
> > > 4. directive, ex: -Dcom.sun.management.jmxremote
> > > 
> > > JVMArgs will ensure that only one value is stored for any given  
> > > option. Here is a quick example
> > > 
> > > args = JVMArgs::Args.new("-XX:-DisableExplicitGC", "-Xmx256M")
> > > 
> > > # "-XX:-DisableExplicitGC" is now stored in args
> > > 
> > > args.add("-XX:+DisableExplicitGC")  
> > > args.add("-Xmx2G")
> > > 
> > > # the settings are now "-XX:+DisableExplicitGC" and "-Xmx2G"

---

<div class="post-metadata">

**Author:** ![Bryan\_Berry](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/bryan_berry/32/213_2.png) [@Bryan\_Berry](https://discourse.chef.io/u/Bryan_Berry)\
**Post date:** [March 21, 2013, 1:49pm UTC](https://discourse.chef.io/t/jvmargs-a-sanity-checker-for-jvm-options/3775/5 "2013-03-21T13:49:17Z")

</div>

well I can definitely be horribly mistaken on the matching Xmx and Xms  
🙂 , and am willing to change the code

iirc I read the matching Xmx and Xms in the "Java Performance" book  
but I could be mistaken

On Thu, Mar 21, 2013 at 2:44 PM, Jesse Campbell [hikeit@gmail.com](mailto:hikeit@gmail.com) wrote:

> I've read plenty that suggests that depending on the situation, having  
> different Xms and Xmx values can be beneficial.
> 
> i've seen things like this:  
> [Java Monitor - The Latest Java News](http://java-monitor.com/forum/showthread.php?t=427)  
> which suggest that setting them the same has no particularly beneficial  
> effect.
> 
> and I've seen things like this:  
> [http://weblogs.java.net/blog/kcpeppe/archive/2011/12/19/setting-xmx-xms-still-considered-harmful](http://weblogs.java.net/blog/kcpeppe/archive/2011/12/19/setting-xmx-xms-still-considered-harmful)  
> which suggest that the ideal settings are for xms to be your 99% case, and  
> xmx allow for some wiggle room
> 
> in fact, i haven't seen any really good recent analyses that support setting  
> them the same, just lots of rhetoric
> 
> -jesse
> 
> On Thu, Mar 21, 2013 at 9:31 AM, Bryan Berry [bryan.berry@gmail.com](mailto:bryan.berry@gmail.com) wrote:
> 
> > min and max should be the same because there is no benefit to having a  
> > lower min according to everything I have read. It can slow down your  
> > application startup however.
> > 
> > it will not support parsing a space delimited string, only the options  
> > specifically for the JVM, for example
> > 
> > "java -Djava.io.tmpdir=/tmp/foo -server -Xmx256m -Xint  
> > -XX:MaxPermSize=512M -classpath /tmp/foo.jar:/tmp/baz.jar  
> > org.apache.catalina.Bootstrap start "
> > 
> > jvmargs doesn't add the java binary to the beginning nor the  
> > "org.apache.catalina.Bootstrap start"
> > 
> > I do want to handle the classpath but i have not figured out a clean  
> > way to handle that yet ☹
> > 
> > i would very much appreciate feedback and testing. this afternoon i  
> > hope to add support for arbitrary rules like the following
> > 
> > "if Max heap is greater than available RAM, raise an error"  
> > "if Max heap is changed, also set Min heap to same value"
> > 
> > On Thu, Mar 21, 2013 at 2:18 PM, Jesse Campbell [hikeit@gmail.com](mailto:hikeit@gmail.com) wrote:
> > 
> > > hey, been looking for something like this to come along, looks like a  
> > > very  
> > > clean, sane way to handle it 😃
> > > 
> > > in your todo you have ensure min and max heap should be the same. why is  
> > > this?
> > > 
> > > i didn't dig to far into the code, but will it support parsing a space  
> > > delimited string, as the current tomcat and tomcat6 cookbooks expect, or  
> > > will the cookbook be expected to handle that?
> > > 
> > > thanks!
> > > 
> > > On Thu, Mar 21, 2013 at 4:53 AM, Bryan Berry [bryan.berry@gmail.com](mailto:bryan.berry@gmail.com)  
> > > wrote:
> > > 
> > > > hey folks,
> > > > 
> > > > i have written a little gem to parse JVM options and would love some  
> > > > feedback on it. Managing JVM options in a cookbooks is a total PITA  
> > > > and I hope this makes it easier. This is less than alpha quality, i am  
> > > > posting it here to get some feedback, not to notify others of a  
> > > > production-ready tool. I foresee it being used in Java-related  
> > > > cookbooks to provide a set of application-specific defaults and then  
> > > > make it easy to override or add to them in recipe code.
> > > > 
> > > > [GitHub - bryanwb/jvmargs: sane parser of java command-line arguments](https://github.com/bryanwb/jvmargs)
> > > > 
> > > > This library parses JVM options so that any given option is only  
> > > > stored once. It does this by breaking each option into one of the  
> > > > three option categories:
> > > > 
> > > > 1. standard, ex: -server, -enablesystemassertions
> > > > 2. nonstandard, ex: -Xmx128M, -Xint
> > > > 3. unstable, ex: -XX:-DisableExplicitGC, -XX:AltStack=128M
> > > > 4. directive, ex: -Dcom.sun.management.jmxremote
> > > > 
> > > > JVMArgs will ensure that only one value is stored for any given  
> > > > option. Here is a quick example
> > > > 
> > > > args = JVMArgs::Args.new("-XX:-DisableExplicitGC", "-Xmx256M")
> > > > 
> > > > # "-XX:-DisableExplicitGC" is now stored in args
> > > > 
> > > > args.add("-XX:+DisableExplicitGC")  
> > > > args.add("-Xmx2G")
> > > > 
> > > > # the settings are now "-XX:+DisableExplicitGC" and "-Xmx2G"

---

<div class="post-metadata">

**Author:** ![John\_Dyer](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/john_dyer/32/464_2.png) [@John\_Dyer](https://discourse.chef.io/u/John_Dyer)\
**Post date:** [March 21, 2013, 1:49pm UTC](https://discourse.chef.io/t/jvmargs-a-sanity-checker-for-jvm-options/3775/6 "2013-03-21T13:49:23Z")

</div>

Brian,

This is very cool ! Thanks !

-John

On Thursday, March 21, 2013, Bryan Berry [bryan.berry@gmail.com](mailto:bryan.berry@gmail.com) wrote:

> min and max should be the same because there is no benefit to having a  
> lower min according to everything I have read. It can slow down your  
> application startup however.
> 
> it will not support parsing a space delimited string, only the options  
> specifically for the JVM, for example
> 
> "java -Djava.io.tmpdir=/tmp/foo -server -Xmx256m -Xint  
> -XX:MaxPermSize=512M -classpath /tmp/foo.jar:/tmp/baz.jar  
> org.apache.catalina.Bootstrap start "
> 
> jvmargs doesn't add the java binary to the beginning nor the  
> "org.apache.catalina.Bootstrap start"
> 
> I do want to handle the classpath but i have not figured out a clean  
> way to handle that yet ☹
> 
> i would very much appreciate feedback and testing. this afternoon i  
> hope to add support for arbitrary rules like the following
> 
> "if Max heap is greater than available RAM, raise an error"  
> "if Max heap is changed, also set Min heap to same value"
> 
> On Thu, Mar 21, 2013 at 2:18 PM, Jesse Campbell [hikeit@gmail.com](mailto:hikeit@gmail.com) wrote:
> 
> > hey, been looking for something like this to come along, looks like a  
> > very  
> > clean, sane way to handle it 😃
> > 
> > in your todo you have ensure min and max heap should be the same. why is  
> > this?
> > 
> > i didn't dig to far into the code, but will it support parsing a space  
> > delimited string, as the current tomcat and tomcat6 cookbooks expect, or  
> > will the cookbook be expected to handle that?
> > 
> > thanks!
> > 
> > On Thu, Mar 21, 2013 at 4:53 AM, Bryan Berry [bryan.berry@gmail.com](mailto:bryan.berry@gmail.com)  
> > wrote:
> > 
> > > hey folks,
> > > 
> > > i have written a little gem to parse JVM options and would love some  
> > > feedback on it. Managing JVM options in a cookbooks is a total PITA  
> > > and I hope this makes it easier. This is less than alpha quality, i am  
> > > posting it here to get some feedback, not to notify others of a  
> > > production-ready tool. I foresee it being used in Java-related  
> > > cookbooks to provide a set of application-specific defaults and then  
> > > make it easy to override or add to them in recipe code.
> > > 
> > > [GitHub - bryanwb/jvmargs: sane parser of java command-line arguments](https://github.com/bryanwb/jvmargs)
> > > 
> > > This library parses JVM options so that any given option is only  
> > > stored once. It does this by breaking each option into one of the  
> > > three option categories:
> > > 
> > > 1. standard, ex: -server, -enablesystemassertions
> > > 2. nonstandard, ex: -Xmx128M, -Xint
> > > 3. unstable, ex: -XX:-DisableExplicitGC, -XX:AltStack=128M
> > > 4. directive, ex: -Dcom.sun.management.jmxremote
> > > 
> > > JVMArgs will ensure that only one value is stored for any given  
> > > option. Here is a quick example
> > > 
> > > args = JVMArgs::Args.new("-XX:-DisableExplicitGC", "-Xmx256M")
> > > 
> > > # "-XX:-DisableExplicitGC" is now stored in args
> > > 
> > > args.add("-XX:+DisableExplicitGC")  
> > > args.add("-Xmx2G")
> > > 
> > > # the settings are now "-XX:+DisableExplicitGC" and "-Xmx2G"

---

<div class="post-metadata">

**Author:** ![John\_E\_Vincent\_lusis](https://avatars.discourse-cdn.com/v4/letter/j/c89c15/32.png) [@John\_E\_Vincent\_lusis](https://discourse.chef.io/u/John_E_Vincent_lusis)\
**Post date:** [March 21, 2013, 2:47pm UTC](https://discourse.chef.io/t/jvmargs-a-sanity-checker-for-jvm-options/3775/7 "2013-03-21T14:47:11Z")

</div>

Here's the logic I've always used:

- Set an Xmx almost always. I would rather the process take a dump  
than take the system down with it.

- If you know you average a certain amount of memory usage after  
running for a while, set that to your Xms. Reasoning being that the  
startup hit is less painful than memory allocation on demand. Priming  
the pump and all that.

- If you have competing jvms, all bets are off. Just size them as best you can.

As a general practice I usually set Xmx and Xms the same. There are  
valid reasons, however ,that you might not want to do that such as GC  
pressure and abuse of ProcessBuilder but like I said above, I'd rather  
give the process the memory I know it will need at peak (if possible)  
and avoid allocation issues.

JVM tuning lends itself heavily to cargo culting and really the only  
safe thing to do out of the gate is set an Xmx so that you don't tank  
the system and profile (JMX for instance) while you learn the  
operating pattern.

On Thu, Mar 21, 2013 at 1:44 PM, Jesse Campbell [hikeit@gmail.com](mailto:hikeit@gmail.com) wrote:

> I've read plenty that suggests that depending on the situation, having  
> different Xms and Xmx values can be beneficial.
> 
> i've seen things like this:  
> [Java Monitor - The Latest Java News](http://java-monitor.com/forum/showthread.php?t=427)  
> which suggest that setting them the same has no particularly beneficial  
> effect.
> 
> and I've seen things like this:  
> [http://weblogs.java.net/blog/kcpeppe/archive/2011/12/19/setting-xmx-xms-still-considered-harmful](http://weblogs.java.net/blog/kcpeppe/archive/2011/12/19/setting-xmx-xms-still-considered-harmful)  
> which suggest that the ideal settings are for xms to be your 99% case, and  
> xmx allow for some wiggle room
> 
> in fact, i haven't seen any really good recent analyses that support setting  
> them the same, just lots of rhetoric
> 
> -jesse
> 
> On Thu, Mar 21, 2013 at 9:31 AM, Bryan Berry [bryan.berry@gmail.com](mailto:bryan.berry@gmail.com) wrote:
> 
> > min and max should be the same because there is no benefit to having a  
> > lower min according to everything I have read. It can slow down your  
> > application startup however.
> > 
> > it will not support parsing a space delimited string, only the options  
> > specifically for the JVM, for example
> > 
> > "java -Djava.io.tmpdir=/tmp/foo -server -Xmx256m -Xint  
> > -XX:MaxPermSize=512M -classpath /tmp/foo.jar:/tmp/baz.jar  
> > org.apache.catalina.Bootstrap start "
> > 
> > jvmargs doesn't add the java binary to the beginning nor the  
> > "org.apache.catalina.Bootstrap start"
> > 
> > I do want to handle the classpath but i have not figured out a clean  
> > way to handle that yet ☹
> > 
> > i would very much appreciate feedback and testing. this afternoon i  
> > hope to add support for arbitrary rules like the following
> > 
> > "if Max heap is greater than available RAM, raise an error"  
> > "if Max heap is changed, also set Min heap to same value"
> > 
> > On Thu, Mar 21, 2013 at 2:18 PM, Jesse Campbell [hikeit@gmail.com](mailto:hikeit@gmail.com) wrote:
> > 
> > > hey, been looking for something like this to come along, looks like a  
> > > very  
> > > clean, sane way to handle it 😃
> > > 
> > > in your todo you have ensure min and max heap should be the same. why is  
> > > this?
> > > 
> > > i didn't dig to far into the code, but will it support parsing a space  
> > > delimited string, as the current tomcat and tomcat6 cookbooks expect, or  
> > > will the cookbook be expected to handle that?
> > > 
> > > thanks!
> > > 
> > > On Thu, Mar 21, 2013 at 4:53 AM, Bryan Berry [bryan.berry@gmail.com](mailto:bryan.berry@gmail.com)  
> > > wrote:
> > > 
> > > > hey folks,
> > > > 
> > > > i have written a little gem to parse JVM options and would love some  
> > > > feedback on it. Managing JVM options in a cookbooks is a total PITA  
> > > > and I hope this makes it easier. This is less than alpha quality, i am  
> > > > posting it here to get some feedback, not to notify others of a  
> > > > production-ready tool. I foresee it being used in Java-related  
> > > > cookbooks to provide a set of application-specific defaults and then  
> > > > make it easy to override or add to them in recipe code.
> > > > 
> > > > [GitHub - bryanwb/jvmargs: sane parser of java command-line arguments](https://github.com/bryanwb/jvmargs)
> > > > 
> > > > This library parses JVM options so that any given option is only  
> > > > stored once. It does this by breaking each option into one of the  
> > > > three option categories:
> > > > 
> > > > 1. standard, ex: -server, -enablesystemassertions
> > > > 2. nonstandard, ex: -Xmx128M, -Xint
> > > > 3. unstable, ex: -XX:-DisableExplicitGC, -XX:AltStack=128M
> > > > 4. directive, ex: -Dcom.sun.management.jmxremote
> > > > 
> > > > JVMArgs will ensure that only one value is stored for any given  
> > > > option. Here is a quick example
> > > > 
> > > > args = JVMArgs::Args.new("-XX:-DisableExplicitGC", "-Xmx256M")
> > > > 
> > > > # "-XX:-DisableExplicitGC" is now stored in args
> > > > 
> > > > args.add("-XX:+DisableExplicitGC")  
> > > > args.add("-Xmx2G")
> > > > 
> > > > # the settings are now "-XX:+DisableExplicitGC" and "-Xmx2G"

---

<div class="post-metadata">

**Author:** ![Adam\_Jacob](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/adam_jacob/32/292_2.png) [@Adam\_Jacob](https://discourse.chef.io/u/Adam_Jacob)\
**Post date:** [March 21, 2013, 6:17pm UTC](https://discourse.chef.io/t/jvmargs-a-sanity-checker-for-jvm-options/3775/8 "2013-03-21T18:17:22Z")

</div>

Even if it is true - no need to force it. Have a happy path that does what you say, and a "no really" path. 🙂

Adam

-----Original Message-----  
From: Bryan Berry [[mailto:bryan.berry@gmail.com](mailto:bryan.berry@gmail.com)]  
Sent: Thursday, March 21, 2013 6:49 AM  
To: [chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
Subject: [chef] Re: Re: Re: Re: [ANN] jvmargs, a sanity checker for JVM options

well I can definitely be horribly mistaken on the matching Xmx and Xms  
🙂 , and am willing to change the code

iirc I read the matching Xmx and Xms in the "Java Performance" book but I could be mistaken

On Thu, Mar 21, 2013 at 2:44 PM, Jesse Campbell [hikeit@gmail.com](mailto:hikeit@gmail.com) wrote:

> I've read plenty that suggests that depending on the situation, having  
> different Xms and Xmx values can be beneficial.
> 
> i've seen things like this:  
> [Java Monitor - The Latest Java News](http://java-monitor.com/forum/showthread.php?t=427)  
> which suggest that setting them the same has no particularly  
> beneficial effect.
> 
> and I've seen things like this:  
> [http://weblogs.java.net/blog/kcpeppe/archive/2011/12/19/setting-xmx-xm](http://weblogs.java.net/blog/kcpeppe/archive/2011/12/19/setting-xmx-xm)  
> s-still-considered-harmful which suggest that the ideal settings are  
> for xms to be your 99% case, and xmx allow for some wiggle room
> 
> in fact, i haven't seen any really good recent analyses that support  
> setting them the same, just lots of rhetoric
> 
> -jesse
> 
> On Thu, Mar 21, 2013 at 9:31 AM, Bryan Berry [bryan.berry@gmail.com](mailto:bryan.berry@gmail.com) wrote:
> 
> > min and max should be the same because there is no benefit to having  
> > a lower min according to everything I have read. It can slow down  
> > your application startup however.
> > 
> > it will not support parsing a space delimited string, only the  
> > options specifically for the JVM, for example
> > 
> > "java -Djava.io.tmpdir=/tmp/foo -server -Xmx256m -Xint  
> > -XX:MaxPermSize=512M -classpath /tmp/foo.jar:/tmp/baz.jar  
> > org.apache.catalina.Bootstrap start "
> > 
> > jvmargs doesn't add the java binary to the beginning nor the  
> > "org.apache.catalina.Bootstrap start"
> > 
> > I do want to handle the classpath but i have not figured out a clean  
> > way to handle that yet ☹
> > 
> > i would very much appreciate feedback and testing. this afternoon i  
> > hope to add support for arbitrary rules like the following
> > 
> > "if Max heap is greater than available RAM, raise an error"  
> > "if Max heap is changed, also set Min heap to same value"
> > 
> > On Thu, Mar 21, 2013 at 2:18 PM, Jesse Campbell [hikeit@gmail.com](mailto:hikeit@gmail.com) wrote:
> > 
> > > hey, been looking for something like this to come along, looks like  
> > > a very clean, sane way to handle it 😃
> > > 
> > > in your todo you have ensure min and max heap should be the same.  
> > > why is this?
> > > 
> > > i didn't dig to far into the code, but will it support parsing a  
> > > space delimited string, as the current tomcat and tomcat6 cookbooks  
> > > expect, or will the cookbook be expected to handle that?
> > > 
> > > thanks!
> > > 
> > > On Thu, Mar 21, 2013 at 4:53 AM, Bryan Berry  
> > > [bryan.berry@gmail.com](mailto:bryan.berry@gmail.com)  
> > > wrote:
> > > 
> > > > hey folks,
> > > > 
> > > > i have written a little gem to parse JVM options and would love  
> > > > some feedback on it. Managing JVM options in a cookbooks is a  
> > > > total PITA and I hope this makes it easier. This is less than  
> > > > alpha quality, i am posting it here to get some feedback, not to  
> > > > notify others of a production-ready tool. I foresee it being used  
> > > > in Java-related cookbooks to provide a set of application-specific  
> > > > defaults and then make it easy to override or add to them in recipe code.
> > > > 
> > > > [GitHub - bryanwb/jvmargs: sane parser of java command-line arguments](https://github.com/bryanwb/jvmargs)
> > > > 
> > > > This library parses JVM options so that any given option is only  
> > > > stored once. It does this by breaking each option into one of the  
> > > > three option categories:
> > > > 
> > > > 1. standard, ex: -server, -enablesystemassertions 2. nonstandard,  
> > > > ex: -Xmx128M, -Xint 3. unstable, ex: -XX:-DisableExplicitGC,  
> > > > -XX:AltStack=128M 4. directive, ex: -Dcom.sun.management.jmxremote
> > > > 
> > > > JVMArgs will ensure that only one value is stored for any given  
> > > > option. Here is a quick example
> > > > 
> > > > args = JVMArgs::Args.new("-XX:-DisableExplicitGC", "-Xmx256M") #  
> > > > "-XX:-DisableExplicitGC" is now stored in args  
> > > > args.add("-XX:+DisableExplicitGC")  
> > > > args.add("-Xmx2G")
> > > > 
> > > > # the settings are now "-XX:+DisableExplicitGC" and "-Xmx2G"