Asked  6 Months ago    Answers:  5   Viewed   55 times

The question is not about the maximum heap size on a 32-bit OS, given that 32-bit OSes have a maximum addressable memory size of 4GB, and that the JVM's max heap size depends on how much contiguous free memory can be reserved.

I'm more interested in knowing the maximum (both theoretical and practically achievable) heap size for a 32-bit JVM running in a 64-bit OS. Basically, I'm looking at answers similar to the figures in a related question on SO.

As to why a 32-bit JVM is used instead of a 64-bit one, the reason is not technical but rather administrative/bureaucratic - it is probably too late to install a 64-bit JVM in the production environment.

 Answers

41

32-bit JVMs which expect to have a single large chunk of memory and use raw pointers cannot use more than 4 Gb (since that is the 32 bit limit which also applies to pointers). This includes Sun and - I'm pretty sure - also IBM implementations. I do not know if e.g. JRockit or others have a large memory option with their 32-bit implementations.

If you expect to be hitting this limit you should strongly consider starting a parallel track validating a 64-bit JVM for your production environment so you have that ready for when the 32-bit environment breaks down. Otherwise you will have to do that work under pressure, which is never nice.


Edit 2014-05-15: Oracle FAQ:

The maximum theoretical heap limit for the 32-bit JVM is 4G. Due to various additional constraints such as available swap, kernel address space usage, memory fragmentation, and VM overhead, in practice the limit can be much lower. On most modern 32-bit Windows systems the maximum heap size will range from 1.4G to 1.6G. On 32-bit Solaris kernels the address space is limited to 2G. On 64-bit operating systems running the 32-bit VM, the max heap size can be higher, approaching 4G on many Solaris systems.

(http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit)

Tuesday, June 1, 2021
 
Crashthatch
answered 6 Months ago
38
export CFLAGS=-m32
Tuesday, June 1, 2021
 
SilverHorn
answered 6 Months ago
69

Each thread in a Java application has its own stack. The stack is used to hold return addresses, function/method call arguments, etc. So if a thread tends to process large structures via recursive algorithms, it may need a large stack for all those return addresses and such. With the Sun JVM, you can set that size via that parameter.

Wednesday, June 9, 2021
 
MDDY
answered 6 Months ago
83

Your 32 bit dll should work just fine on a 64 bit machine as long as it is loaded into a 32 bit process - attempting to load a 32 bit dll into a 64 bit process will fail.

If your project is a .Net (e.g. C#) application then you should be able to target your assembly at x86 in order to get your 32 bit dll working correclty:

  • Right click on your project in Visual Studio and select Properties
  • On the Build project properties tab ensure that the Platform target drop down reads "x86" instead of "Any CPU"

If you platform target is "Any CPU" then your project will normally be targeted at whatever platform is available, i.e. x64 on a 64 bit OS - this will prevent your 32 bit dll from being loaded.

If your project is not a .Net assembly then the equivalent steps needed to do the above will be different.

Alternatively you can attempt to obtain a 64 bit version of your dll - if it is a dll that you have produced then you will need to migrate it to 64 bit yourself. If not then you are dependent on the original suppliers providing a 64 bit compatible version.

Monday, August 23, 2021
 
Andres
answered 4 Months ago
99

Can someone explain the difference between anonymous classes, nested classes and private classes in Java?

  • Anonymous classes are for instance the Runnable in

    new Thread(new Runnable() {
        public void run() {
            ...
        }
    }.start();
    
  • Nested classes look like

    class SomeClass {
    
        ...
    
        class NestedClass {
            ....
        }
    }
    
  • Private classes (which you refer to as "the ones you write at the bottom of your file completely outside the declaration of your public class") are actually package scoped classes. You can't have the private modifier in front of a class, unless it is nested!

I'd like to know the runtime costs associated with each and the compiler approach to each, so I can get a grip on which is best to use for e.g. performance (potential for compiler optimisations), memory usage, and general acceptability with other Java coders.

I doubt that there is any performance difference between these approaches. Why? Because each approach ends up as being compiled into a separate more or less "regular" class. ("More or less" due to the fact that an accesss-method is generated in some cases, but it's side effect free and most likely inlined by the JIT anyway.)

This code:

public class TestOuter {

    int fieldOuter;
    public void methodOuter() {
    }

    class TestInner {
        int fieldInner;
        public void methodInner() {
        }
    }
}


class TestPackage {

    int fieldPackage;
    public void methodPackage() {
    }

}

Gets compiled into:

$ javap -c TestOuter$TestInner
Compiled from "TestOuter.java"
public class TestOuter extends java.lang.Object{
int fieldOuter;

public TestOuter();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

public void methodOuter();
  Code:
   0:   return

}

$ javap -c TestOuter
Compiled from "TestOuter.java"
public class TestOuter extends java.lang.Object{
int fieldOuter;

public TestOuter();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

public void methodOuter();
  Code:
   0:   return

}

$ javap -c TestPackage
Compiled from "TestOuter.java"
class TestPackage extends java.lang.Object{
int fieldPackage;

TestPackage();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

public void methodPackage();
  Code:
   0:   return

}
Friday, October 22, 2021
 
masukomi
answered 1 Month ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :
 
Share