Java Swing Application not running in 64bit - java

I have one really weird problem.
I have one Swing Application which we recently upgraded, that does not run at all in a Java 1.7/1.8 64bit enviroment.
More specifically, the application works perfectly in 32bit Java installations of 1.7.0_52+, but if you place it in a 64bit enviroment it does not open at all.
Running it from the console with the -verbose, the last message before it stops loading is:
[Loaded sun.awt.AWTAutoShutDown$1 from c:\Program Files\Java\jre1.8.0_65\lib\rt.jar]
There is no message in any log above that suggests an error has occured, and no exception or other message thrown. The application's java enviroment remains in memory with a cpu usage of ~40%.
What makes this wierd is that the same application runs from the same PC if I launch it via eclipse. There is only one java installation on my PC, and both the application and Eclipse use this same JDK.
I am unable to think of anything that could cause a problem, and I am at a loss. Does anyone have anyidea?

The 64-bit JVM using 32-bit references can address 32+3 bits of address space as it can assume the lowest 3 bits of an objects address is 0.
Most 32-bit JVMs are limited to around 1.2-1.5 GB.

Related

Bundled Java-Application is recognized as 32-Bit, will it run under macOS 10.15 Catalina?

I write and deploy an Application that is written in Java, then compiled and bundled into an application Bundle. The application is then run only internally to my company. So far, no machines run macOS 10.15, but new ones will come soon and thus the application needs to be ready.
When I take a look into the list of installed software, it tells my application is not a 64-Bit application, although it is a Java-application and Java is 64-Bit indeed.
Is there any flags to be set somewhere (e.g. in info.plist), to tell the OS to launch/treat it as a 64-Bit application? Or is the whole solved once the application gets signed/notarized by apple? (another thing that I skipped so far)
As I have got some never Hardware running 10.14 Mojave and the Java-Application still runs smoothly. Therefore I suppose that it is simply falsely recognized as 32-Bit application by the older operating systems.

Javafx 64 Bit Application can only allocate 1 GB Ram

This is a problem, that bugs a customer of ours already for a while. Eventhough we provided a 64-bit JavaFX Desktop Application with JVM Options set to:
[JVMOptions]
-Xmx5120m
Runtime.getRuntime().maxMemory() returns roughly about only 1 GB, eventough the client has 16 GB of RAM available.
The application gets deployed by extracting an archive together with an 64-bit runtime and is builded with fx:deploy ant task. Unfortunatly we are unable to reproduce this error here at any time.
Are there any other possibilities to restrict the memory a Java-Application can use? The customer uses some kind of virtualisation system like citrix receiver with windows 7. Can this have an influence on it? I also read it is possible to restrict the amount of memory an application can use due to windows registry entries?
Any help is greatly appriciated, because we are running out of ideas on how to solve this case.
Additional Information: To gather more information, we wrote a diagnostic tool inside our application which is simular to the one of apache diagnostics. It shows that our -Xmx parameter seems to get overwritten:
diagnostics.vmInfoStartup:
-Djava.library.path=K:\PATH\APPLICATION\app;K:\PATH\APPLICATION\
-Djava.launcher.path=K:\PATH\APPLICATION\
-Dapp.preferences.id=FxApplication
-Xmx5120m
-Xmx1024m
But where does the second -Xmx1024m restriction come from? The user starts the EXE deployed from our fx ant task without any further parameters.

Java Netbeans Heap Size

I have a Java project that needs a lot of memory to run. When I change the flags here:
It works fine, however I still need a bigger Heap size but whenever I choose a bigger size like 2g or something like that it always shows the following message:
Am I doing something wrong? And what can I do to correct this issue, I looked everywhere but can't seem to find a solution and I really need this for an assignment that is to be due sooner than I hoped...
EDIT: I should add that my computer has 8GB ram so that shouldn't be the issue and I'm working on Windows 10 if that matters.
EDIT1: When I click on help->about I get this window:
How can I conclude from here if my jvm is 32 or 64 bit?
How can I conclude from here if my jvm is 32 or 64 bit?
You are using a 32bit JVM.
A 64bit JVM includes that information in the version string, e.g.:
1.8.0_92; Java HotSpot(TM) 64-Bit Server VM 25.92-b14
A 32bit process is restricted to 2GB of memory and with Java you usually can't usually use more then about 1.2GB. I think this depends on the Windows version and configuration.
So just remove the 32bit JDK and install the 64bit one, then you can use all the 8GB that your computer has.

How does running a java application inside eclipse differ in running it directly?

I am developing a java application, which uses a dll using JNI.
The dll is still under development, so I guess it has some memory problems.
When I run my application, using the Run dialog of eclipse, the application is very unstable and crashes very likely. When I start the same application outside from eclipse, the application runs much more stable. There are still crashes, but significantly less.
And two more questions:
What is the difference when the application is run as Debug?
The memory which the dll allocates is not the memory of the virtual machine. So the parameters which influence the memory of the virtual machine (like -Xmx) do not influence the memory allocation for the dll. Is this statement correct?
Thanks in advance for your responses
This doesn't fully answer your question, but it sounds similar to an issue that I've had when running native code from Java.
If running the app one way seems more stable than another, then its possible that you have more than one JVM installed on your system, and Eclipse is using a different one to the one that gets used from the command line.
Please elaborate on "unstable". Which kinds of errors do you receive?
As suggested by codebox I would also make sure that it is the same version of the JVM running.
You can do this by printing JRE information on startup:
System.out.println("Vendor: " + System.getProperty("java.vendor") + ", Version: " + System.getProperty("java.version"));
To change the JRE version in Eclipse go to: Window -> Preferences -> Java -> Installed JREs

JVM 32 bit crashes on 64 bit machine

My Java application JVM (1.6.0_26, 32-bit) experienced sporadic crash when closed this Java application.
This intermittent JVM crash problem seemed to only affect 64-bit Windows OS. 
This problem does NOT occur on 32-bit Windows OS and Mac OS X.
Can anyone tell me the reason for this.
actually this java application uses 100-150 libraries and it does not get crashed while in execution, once application gets closed crash occurs.
Is it appropriate to use 32 bit JVM on 64 bit machine?
Thanks a lot in advance for your help.
Short answer is No. It's not appropriate to use a 32-bit JVM on a 64-bit machine. Longer answer is Windows 64bit OS can run 32bit programs under a compatibility mode if you don't have an option.
There's really no need to do that since 64 bit JVM runs fine on Windows OS. This also means your process can take advantage of more memory and speed than a 32bit process can use.
http://msdn.microsoft.com/en-us/library/aa384249(v=vs.85).aspx
Having a similar issue where I installed my JVM 32 bit on a 64 bit Win7, everything worked well until a third party OLE bridge was loaded. The JVM gave a crash report saying Java binary stopped working and the Message in the crash report code's value was HEAP_MEMORY_CORRUPTION. It is quite strange though because when I attached a profiler, the heap was well under the maximum limit. I suspect that my Bridge provider made some Kernel Mode executions(if that's possible) that is not allowed while being emulated under WOW64.
I solved mine. When the ole populated MS Office, it couldn't populate 2007 instead when I installed 2003, it worked. check whether your app crashed immediately or when some native calls are taking place, that way you could pinpoint the trouble.

Categories