Correct output of Memory Usage, fix for free_ram, max_ram, used_ram added current_ram

[KoffiePatje]

I've also fixed the memory output to display correct values and added the variable "%current_ram%"

PROOF: http://prntscr.com/42q3sp ( differnce of 2mb in free_mem is my speed of print screening after executing the command )

---

Long/int division resulted in unexpected values, making sure the value is in the range of long fixes this problem.

TO DO: Fix used%ram

[KoffiePatje]

Well those builds fail at downloading protocollib.... dunno why, but you can see that jdk6,7 and 8 get compiled in any of the last 2....

shitty Travis CI building machine

[KoffiePatje]

Aaah there you go, can't stand that build-machine sorry....

[games647]

Yes, I know. I can't understand why travis timed out for one or two java versions. Are you sure long/int division causes, because this sounds to me very strange.

[KoffiePatje]

http://stackoverflow.com/questions/12314889/unexpected-result-in-long-int-division

Normally I code in C++, I thought the result was quite unexpected as well, turns out that Java does a 64 bits / 32 bits division if the static value is within the integer range. To make sure this doesn't happen we could simply adjust your division to "/ 1024L / 1024L" but since divisions take more time than multiplications it is an optimization to do "/ ( 1024L * 1024L )"

Hope that explains everything ^^

[KoffiePatje]

Or what I can imagine happening since the result turned out as negative value is that the 64 bits long was casted to a 32 bits integer, which of course set the "signed" bit of the integer causing it to go big number below zero and that was than divided by 1024.

This also explains why smaller memory amounts produced correct results.

Nonetheless I am sure the current implementation will never suffer from this issue again.

[games647]

First of all the compiler will automatically optimize this and secondly this is a long/int division, where I thought the vm will convert the int to a long. In my opinion this little difference occures of time difference.

[KoffiePatje]

No way... really, you're calculation messes up, try setting a server with more than 2 gigs of RAM and the issues will occur I'm quite sure, this has nothing to do with time. The compiler expects a final integer to be returned and will thus be converted to an int. I have tested this on multiple machines, your call if you want to integrate my changes... I need no credit for them. But you should put an L behind the 1024 to make sure the calculation is done correctly.

[KoffiePatje]

The first division occuring should always be a long/long division since 4GB of ram will overflow the integer range

[KoffiePatje]

By the way my changes also correct your mistake of using maxmemory instead of totalmemory for used_ram calculations.

Max ram can not be used when doing this since you're not sure if the complete amount of memory is allocated.

[games647]

Sorry for my late response, but I was very busy in the last days.

You're absolutly right. At first the division should be made and then the casting. I thought casting has a lower priority and would be made after the division.

Second I thought the compiler will automatically optimize the division from "/1024/1024" to "/1048576", but for some reason it doesn't and works for your case.

Nevermind, thanks for your work. Could you please rebase your branch to one commit?

[games647]

https://github.com/games647/ScoreboardStats/commit/0728edb87a4caacee5acc68c0b76561b1608917f