MemoryUtils.getPhysicalMemory()

What is MemoryUtils.getPhysicalMemory() used for?

I was looking at bug #2755 and it’s related to a jna (Java Native Access) call failing. I notice that MemoryUtils.getPhysicalMemory() is called from within a static block when the AbstractLaunchAction class is loaded. Does it need to be called at class load time, or could it be moved to a startup call like what we did for Resources?

It looks like there is nothing VASSAL specific in the MemoryUtils class, which would make it a candidate to be replaced by a jar if we can find one that has the functionality we need–make fixing bugs in it someone else’s problem… Platform-specific jna code is pretty error-prone–I’d recommend avoiding it if we can.

-K

Thus spake fil512:

What is MemoryUtils.getPhysicalMemory() used for?

It returns the amount of RAM the machine has. It’s used in
AbstractLaunchAction when spawning child processes to help us set their max
heap sizes appropriately.

I was looking at bug #2755 and it’s related to a jna (Java Native
Access) call failing. I notice that MemoryUtils.getPhysicalMemory() is
called from within a static block when the AbstractLaunchAction class is
loaded. Does it need to be called at class load time, or could it be
moved to a startup call like what we did for Resources?

It looks like there is nothing VASSAL specific in the MemoryUtils class,
which would make it a candidate to be replaced by a jar if we can find
one that has the functionality we need–make fixing bugs in it someone
else’s problem… Platform-specific jna code is pretty error-prone–I’d
recommend avoiding it if we can.

If you can find a library which does this, I’d be happy to use it. This
code isn’t very old—I wrote it sometime during the 3.1 series—so I
imagine I looked for a library but didn’t find one.


J.

Thus spake Joel Uckelman:

If you can find a library which does this, I’d be happy to use it. This
code isn’t very old—I wrote it sometime during the 3.1 series—so I
imagine I looked for a library but didn’t find one.

I found a way which might work which doesn’t use JNA:

import com.sun.management.OperatingSystemMXBean;
import java.lang.management.ManagementFactory;

public class Test {
public static void main(String args) {

final Object o = ManagementFactory.getOperatingSystemMXBean();

if (o instanceof OperatingSystemMXBean) {
  final OperatingSystemMXBean osb = (OperatingSystemMXBean) o;
  System.out.println((osb.getTotalPhysicalMemorySize() >> 20) + " MB RAM");
} 
else {
  System.out.println("o is a " + o.getClass().getSimpleName());
}

}
}

Caveats:

  • This won’t let us get the RAM on a non-Sun JVM. However, I can’t remember
    the last time I saw anyone using a non-Sun JVM to run VASSAL, and it won’t
    fail—we just won’t be able to check that the max heap for the Player is
    sane. I think it’s safe to say that anybod using some other JVM will be
    sufficiently clueful to not need this check.

  • I’ve tested this on Linux. I would appreciate it if somebody would test
    it on Windows, and also on a Java 5 Mac, a Java 6 Mac, an Intel Mac, and
    a PPC Mac.

If this works, then we can get rid of our dependancy on JNA for 3.1.15.


J.

  • I’ve tested this on Linux. I would appreciate it if somebody would test
    it on Windows, and also on a Java 5 Mac, a Java 6 Mac, an Intel Mac, and
    a PPC Mac.

On a Vista machine with 4Gb of RAM, it reports 2047 MB RAM.

Thus spake “Brent Easton”:

  • I’ve tested this on Linux. I would appreciate it if somebody would test
    it on Windows, and also on a Java 5 Mac, a Java 6 Mac, an Intel Mac, and
    a PPC Mac.

On a Vista machine with 4Gb of RAM, it reports 2047 MB RAM.

Was that 32- or 64-bit Vista? 32- or 64-bit JVM?

Sigh, it looks like we’re hitting this bug:

bugs.sun.com/bugdatabase/view_bu … id=6853676

It appears that internally, the JDK is calling the wrong Windows API
function… This is something they could fix in a few minutes. It’s
maddening that the bug has been open since June of last year.


J.

Was that 32- or 64-bit Vista? 32- or 64-bit JVM?

32 bit

It appears that internally, the JDK is calling the wrong Windows API
function… This is something they could fix in a few minutes.

I can sympathise :frowning:

But then, I’m paid to do something else entirely…

  • M.



It appears that internally, the JDK is calling the wrong Windows API

function… This is something they could fix in a few minutes.

I can sympathise :frowning:

But then, I’m paid to do something else entirely…

- M.

On Sep 3, 2010, at 3:51 AM, Joel Uckelman wrote:

  • I’ve tested this on Linux. I would appreciate it if somebody would
    test
    it on Windows, and also on a Java 5 Mac, a Java 6 Mac, an Intel Mac,
    and
    a PPC Mac.

Initial results:
Intel Mac, OS 10.5 (Leopard).
Java 5: Works
Java 6: Works

Other Mac variants will have to wait until I get home.

Thus spake Thomas Russ:

Initial results:
Intel Mac, OS 10.5 (Leopard).
Java 5: Works
Java 6: Works

Was this 32- or 64-bit?


J.

Joel,

I noticed the last comment on that sun bug link found says this:

Is install4j an option for us here?

Ken

On Sep 3, 2010, at 10:24 AM, Joel Uckelman wrote:

Thus spake Thomas Russ:

Initial results:
Intel Mac, OS 10.5 (Leopard).
Java 5: Works
Java 6: Works

Was this 32- or 64-bit?

A fair question.

Java 5 I ran in both 32 and 64 bit versions. Both worked.
java version “1.5.0_24”
Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_24-
b02-357-9M3165)
Java HotSpot™ Client VM (build 1.5.0_24-149, mixed mode, sharing)

Java 6 was 64 bit only:
java version “1.6.0_20”
Java™ SE Runtime Environment (build 1.6.0_20-b02-279-9M3165)
Java HotSpot™ 64-Bit Server VM (build 16.3-b01-279, mixed mode)

Both of these are up-to-date with Apple’s Software update.

Thus spake fil512:

Joel,

I noticed the last comment on that sun bug link found says this:

We use install4j for our java installers/launchers. This provides good
access to system specific information.
com.install4j.api.SystemInfo.getPhysicalMemory() provides the accurate
value.

Is install4j an option for us here?

install4j isn’t open-source.


J.

Thus spake Thomas Russ:

Java 5 I ran in both 32 and 64 bit versions. Both worked.
java version “1.5.0_24”
Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_24-
b02-357-9M3165)
Java HotSpot™ Client VM (build 1.5.0_24-149, mixed mode, sharing)

Java 6 was 64 bit only:
java version “1.6.0_20”
Java™ SE Runtime Environment (build 1.6.0_20-b02-279-9M3165)
Java HotSpot™ 64-Bit Server VM (build 16.3-b01-279, mixed mode)

Both of these are up-to-date with Apple’s Software update.

How much RAM?


J.

On Sep 3, 2010, at 11:10 AM, Joel Uckelman wrote:

Thus spake Thomas Russ:

Java 5 I ran in both 32 and 64 bit versions. Both worked.
java version “1.5.0_24”
Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_24-
b02-357-9M3165)
Java HotSpot™ Client VM (build 1.5.0_24-149, mixed mode,
sharing)

Java 6 was 64 bit only:
java version “1.6.0_20”
Java™ SE Runtime Environment (build 1.6.0_20-b02-279-9M3165)
Java HotSpot™ 64-Bit Server VM (build 16.3-b01-279, mixed mode)

Both of these are up-to-date with Apple’s Software update.

How much RAM?

Boy, you want to know everything… ;)

4096 MB

Thus spake Thomas Russ:

How much RAM?

Boy, you want to know everything… :wink:

4096 MB

Well, the problem with it on Windows is undetectible if you have <= 2GB
RAM, so it’s good to know what we’re testing.

Thanks.


J.

On Sep 3, 2010, at 12:30 PM, Joel Uckelman wrote:

Thus spake Thomas Russ:

How much RAM?

Boy, you want to know everything… :wink:

4096 MB

Well, the problem with it on Windows is undetectible if you have <=
2GB
RAM, so it’s good to know what we’re testing.

Thanks.

And another test I was able to do quickly by remote control. The
machine does have 8 GiB on it.

Intel Mac, OS 10.6 (Snow Leopard)
Java 1.6, 32 and 64 bit.

tar% java -version
java version “1.6.0_20”
Java™ SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
Java HotSpot™ 64-Bit Server VM (build 16.3-b01-279, mixed mode)

tar% java TestMemory
8192 MB RAM

tar% java -d32 -version
java version “1.6.0_20”
Java™ SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
Java HotSpot™ Client VM (build 16.3-b01-279, mixed mode)

tar% java15 -d32 TestMemory
8192 MB RAM

I should be able to get a PPC test on Leopard later. Maybe if I’m
lucky I can also boot the PPC machine into Tiger and try that OS as
well. I think I still have a bootable disk for that.

OK, here’ some Mac PPC information. It looks like it is working fine.

iMac, PPC G5, 2GB memory (sorry, that’s she’ll take, Captain)
OS 10.5 Leopard
Java 1.5 32 and 64 bit.
No Java 1.6 available for PPC Macs.

tar % java15 -d64 -showversion TestMemory
java version “1.5.0_24”
Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_24-b02-357-9M3165)
Java HotSpot™ Client VM (build 1.5.0_24-149, mixed mode, sharing)

2048 MB RAM

tar% java15 -d32 -showversion TestMemory
java version “1.5.0_24”
Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_24-b02-357-9M3165)
Java HotSpot™ Client VM (build 1.5.0_24-149, mixed mode, sharing)

2048 MB RAM

OK. After a reboot from my external disk, I can also test

Mac PPC G5, 2GB RAM
OS 1.4 (Tiger)
Java 1.5, 32 bit only.

tar% java -showversion TestMemory
java version “1.5.0_16”
Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-275)
Java HotSpot™ Client VM (build 1.5.0_16-132, mixed mode, sharing)

2048 MB RAM

[n.B., this version of Java doesn’t take the -d32/-d64 switches]

Correction to the Mac PPC with OS 10.5 and Java 1.5 on PPC.

It appears that the only architecture it runs with is the 32 bit. Although it takes the -d64 switch and doesn’t complain, there isn’t actually a 64 bit JVM available on the PPC with Java 1.5

Thus spake tar:

OK, here’ some Mac PPC information. It looks like it is working fine.

iMac, PPC G5, 2GB memory (sorry, that’s she’ll take, Captain)
OS 10.5 Leopard
Java 1.5 32 and 64 bit.
No Java 1.6 available for PPC Macs.

tar % java15 -d64 -showversion TestMemory
java version “1.5.0_24”
Java™ 2 Runtime Environment, Standard Edition (build
1.5.0_24-b02-357-9M3165)
Java HotSpot™ Client VM (build 1.5.0_24-149, mixed mode, sharing)

2048 MB RAM

tar% java15 -d32 -showversion TestMemory
java version “1.5.0_24”
Java™ 2 Runtime Environment, Standard Edition (build
1.5.0_24-b02-357-9M3165)
Java HotSpot™ Client VM (build 1.5.0_24-149, mixed mode, sharing)

2048 MB RAM

Thanks for testing.

So, it looks like we can replace the JNA code with this on every platform
except Windows.

Hmm.


J.