units of measurement - Does java -Xmx1G mean 10^9 or 2^30 bytes? -

and in general, units used -xmx, -xms , -xmn options ("k", "m" , "g", or less standard possibilities "k", "m" or "g") binary prefix multiples (i.e. powers of 1024), or powers of 1000?

the manuals represent kilobytes (kb), megabytes (mb) , gigabytes (gb), suggesting powers of 1000 defined in original si system. informal tests (that i'm not confident about) suggest kibibytes (kib), mebibytes (mib) , gibibytes (gib), powers of 1024.

so right? e.g. java code show current size?

using multiples of 1024 not surprising ram sizes, since ram typically physically laid out doubling hardware modules. using units in clear , standard way ever more important bigger , bigger powers, since potential confusion grows. unit "t" accepted jvm, , 1 tib 10% bigger 1 tb.

note: if these binary multiples, suggest updating documentation , user interfaces clear that, examples "append letter k or k indicate kibibytes (1024 bytes), or m or m indicate mebibytes (1048576 bytes)". approach taken, e.g., in ubuntu: unitspolicy - ubuntu wiki.

note: more on options used for, see e.g. java - xms , xmx parameters when starting jvms?.

short answer: memory sizes used jvm command line arguments specified in traditional binary units, kilobyte 1024 bytes, , others increasing powers of 1024.

long answer:

this documentation page on command line arguments says following applies arguments accepting memory sizes:

for example, set size 8 gb, can specify either 8g, 8192m, 8388608k, or 8589934592 argument.

for -xmx, gives these specific examples:

the following examples show how set maximum allowed size of allocated memory 80 mb using various units:

-xmx83886080
-xmx81920k
-xmx80m

before thought check documentation (i assumed had?), checked source of hotspot , found memory values parsed in src/share/vm/runtime/arguments.cpp function atomull (which seems stand "ascii memory, unsigned long long"):

// parses memory size specification string. static bool atomull(const char *s, julong* result) {   julong n = 0;   int args_read = sscanf(s, julong_format, &n);   if (args_read != 1) {     return false;   }   while (*s != '\0' && isdigit(*s)) {     s++;   }   // 4705540: illegal if more characters found after first non-digit   if (strlen(s) > 1) {     return false;   }   switch (*s) {     case 't': case 't':       *result = n * g * k;       // check overflow.       if (*result/((julong)g * k) != n) return false;       return true;     case 'g': case 'g':       *result = n * g;       if (*result/g != n) return false;       return true;     case 'm': case 'm':       *result = n * m;       if (*result/m != n) return false;       return true;     case 'k': case 'k':       *result = n * k;       if (*result/k != n) return false;       return true;     case '\0':       *result = n;       return true;     default:       return false;   } } 

those constants k, m, g defined in src/share/vm/utilities/globaldefinitions.hpp:

const size_t k                  = 1024; const size_t m                  = k*k; const size_t g                  = m*k; 

all confirms documentation, except support t suffix terabytes apparently added later , not documented @ all.

it not mandatory use unit multiplier, if want one billion bytes can write -xmx1000000000. if use multiplier, they're binary, -xmx1g means 2³⁰ bytes, or 1 stick o' ram.

_{(which not surprising, because java predates iec's attempt retroactively redefine existing words. confusion have been saved if iec had merely advised disambiguating memory units qualifiers "binary" , "decimal" occasional times meaning wasn't clear. e.g., binary gigabytes (gb2) = 1024³ bytes, , decimal gigabytes (gb10) = 1000³ bytes. no, redefined words using, inevitably exploding confusion, , leaving stuck these clown terms "gibibyte", "tebibyte" , rest. oh god spare us.)}