This returns (.getTotalPhysicalMemorySize (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
You could use this in your project.clj, perhaps by including ~(str "-Xms" (quot (.getTotalPhysicalMemorySize ...) appropriate-number)) in :jvm-opts. Also, you can absolutely use your own :jvm-opts with :replace. Cheers, Michał PS. getTotalPhysicalMemorySize is declared by com.sun.management.OperatingSystemMXBean. getOperatingSystemMXBean's return type is actually java.lang.management.OperatingSystemMXBean, but the actual returned value does implement the com.sun interface. I just tested this on a Linux system, hopefully it'll also work on other platforms. On 6 February 2014 03:15, Lee Spector <lspec...@hampshire.edu> wrote: > > On Feb 5, 2014, at 8:50 PM, Bruce Adams wrote: >> Modern JVM's pick default heap sizes based on the physical memory in >> your machine. With more than 1GB of physical memory, initial heap is >> 1/64 and maximum heap is 1/4 of physical memory.[1] >> >> For OpenJDK and Oracle, this command: >> java -XX:+PrintFlagsFinal -version | grep HeapSize >> will show the initial and maximum heap sizes (along with a few other >> numbers). > > Thanks Bruce. Do you happen to know if there's a way to specify different > fractions? I'd like something more like 3/4 (or 7/8) than 1/4. Nothing else > will be running on the machine (aside from the OS and maybe tiny other > things), and I want it to take everything it might need. I realize I can > hardcode specific sizes, but then I have to change it for every machine > configuration it runs on, which is what I was hoping to avoid. I have 64GB on > some of my machines, 12GB on others, etc., and I'd like to use most of what's > available wherever I run, preferably without changing project.clj every time. > >> Also, you may not want to set the initial heap size as large as the >> maximum heap size. Oracle[2] says (in part): >> >>> Setting -Xms and -Xmx to the same value increases predictability by >>> removing the most important sizing decision from the virtual machine. >>> However, the virtual machine is then unable to compensate if you make a >>> poor choice. > > The choice of using the same, maximal limit for both -Xms and -Xmx, could > only be poor in the sense of using more than the necessary memory, right? > Since I'm happy to use every available byte and am only concerned about speed > it seems like this should be okay. > > Thanks, > > -Lee > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
