Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop 500MB cap for 9.1 #21

Open
headius opened this issue Mar 18, 2016 · 1 comment
Open

Drop 500MB cap for 9.1 #21

headius opened this issue Mar 18, 2016 · 1 comment

Comments

@headius
Copy link

headius commented Mar 18, 2016

For jruby/jruby#3739 we have decided to stop forcing a 500MB default heap max, since most current JVMs will choose their own, better, larger defaults. We've already removed it from the bash script for 9.1. We need to remove it from mjruby as well.

Unlike the bash script, we may also be able to do the memory size calculation with our 500MB in mind, if we want (as @enebo believes) to ensure we at least do not cause it to suddenly be lower on machines with less than 2GB (current Hotspot releases use 1/4*physical as default max). @enebo sent me a link to some C code to determine system memory (which I can't find now) that might serve as a good starting point for a "mruby-sysinfo" or something that provides some basic OS/platform information. From there we can choose an appropriate max or let JVM decide.

Or we can just let JVM decide, which is my preference :-) Either way, this is a 9.1 change, and 9.1 should ship mjruby.

@enebo
Copy link
Contributor

enebo commented Mar 18, 2016

@codefinger also points out another wrinkle with both our idea and about Java within docker itself:
http://matthewkwilliams.com/index.php/2016/03/17/docker-cgroups-memory-constraints-and-java-cautionary-tale/

Not sure what conclusion is to be made here but JVM ergonomics are broken because APIs are returning the wrong info to them...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants