I have a project with lots of files. After switching to an SSD disk, things became impossible, its extremely slow. I reinstalled, upgraded to a new version (oxygen) but nothing changes.
For example, a refresh of workspace can take 10 minutes. A single file renaming, 5 minutes. But sometimes (it happens occasionally) these operations are really fast.
My OS is Debian 4.9.30-2+deb9u5 (2017-09-19) x86_64.
Eclipse build information:
Eclipse Java EE IDE for Web Developers.
Version: Oxygen.1a Release (4.7.1a)
Build id: 20171005-1200
OS: Linux, v.4.9.0-3-amd64, x86_64 / gtk 2.24.31
Before the SSD disk switch, I had no problem.
I had a similar issue. What fixed it for me was running Eclipse in clean mode, to clear out cached data. The first time you do eclipse -clean it takes ages, but then it's fast again. You should only have the -clean flag on once, not every time you run it.
Take a look at this answer for details: How to run eclipse in clean mode? and what happens if we do so?
Related
I have a Java application, and I'd like to monitor it using Java VisualVM (jvisualvm).
However, in the VisualVM window very little data can be seen. Also, I can't take a heap dump.
Here is a screenshot of what it looks like, with another test app I wrote:
I can monitor memory usage, classes loaded and threads. Heap dumps, performing GC as well as sampling is disabled.
I have tried adding -Dcom.sun.management.jxmremote to VM arguments, as described here. This is showing up in the Installation Details window. However, it does not appear in the Java process arguments. (should it?)
I also tried to click the button in my test app until an OutOfMemoryError occurred. No heap dump; that is not weird as Heap Dump on OOME is disabled.
What could I do to solve this?
I had this problem because I was running JVisualVM from a different JRE/JDK installation than the target process. It seems that the two must be coming from the same place or it grays out the Heap Dump button.
It seems there was a problem with different Java versions.
A long story short: If JDK is outdated re-install it, and delete Java executables from C:\Windows\System32 and C:\Windows\SysWOW64.
Firstly, I want to tell you that I have multiple versions of Java on my computer. My JDK is 32-bit because of some drivers not running with 64-bit Java. Also, I have both 32-bit and 64-bit JRE installed, the latter for better performance for Java games.
My JDK was version 7, update 40. The VisualVM was so also that version. However, my JRE with auto updates was version 7, update 45.
java -version told me it was version 45 (which it was), so I didn't think the problem was there.
Then, I checked the versions via Control Panel. I now knew my JDK was outdated, so I uninstalled it and redownloaded it.
Uninstalling removed Java from the system path, so jvisualvm wouldn't run. I added it to the path. Now both the app and VisualVM ran normally, but still the problem persisted.
The final problem was that the system was using the java.exe from C:\Windows\System32 instead of the JDK one. By the date it seemed to be the latest one, but maybe it was that the JRE was installed in a different location that the VisualVM (= the JDK).
Finally, I just deleted the Java executables in both C:\Windows\System32 and C:\Windows\SysWOW64.
I have a very powerful Mac with latest OS X Lion and latest Apple 1.6 JDK. I just did a clean install after struggling with previous install.
The computer don't have problems, because I can run smoothly lot of heavy applications that don't use java (Avid Pro Tools, Gimp, 3D games...).
BUT, if I run a simple command like "mvn -version" or "java -version" or start the eclipse application, it hangs some seconds before answer... eclipse run fast, but hangs for a long time before the loading bar start.
A maven project that I build in my windows in 5 minutes, takes 1h in the mac.
If I create a simple HelloWorld class without any import and acall "javac HelloWorld.java", without set any extra classpath, it takes 20 seconds to compile.
I was about to install the Oracle Java 7. My intention is to keep both. But, while downloading I did something:
I was imagining that for every java call it hangs (for a javac that compile several classes, it hangs a lot), it looks like scanning for class path, or something like this. So I compared:
javac HelloWorld.java
to
sudo javac HelloWorld.java
The first today took almost 1 minute. The second one much less than one second.
I'm a admin user, but probably I have some other problem of permissions (maybe in some not related directory). I will post the solution here hope soon!
There is something wrong with your OS X Java installation. First, I would try downloading and installing the latest Java 7 JDK from Oracle to see if that corrects your installation.
I've upgraded to IDEA 12 and become frustrated with the slow response. Class navigation takes several seconds to populate the search list (previously it was instantly), any dialog relevant to file list operation hangs for minutes. Move a class to another package just hang up and I have to kill the process. Does anyone have the same experience with me?
Additional information:
I am on windows 7
I tried both 64 and 32 versions and both have the same issue
My 64bit vmoption file has the following configuration:
I have the log dir zipped and put on http://ge.tt/1JwgAnU/v/0. When I start to generating the log dir, I clean it first and then start IDEA 64 bits, open a project (automatically), then invoke File > import module command. I observed there are around a minutes delay before the dialog popped up. And inside the log dir I see a threadDumps-20130106-091041-IU-123.100 folder. However there is no exception found in the idea.log file.
Updates
A screenr showing IDEA hang up when trying to move one class to another package by drag and drop: http://www.screenr.com/zlA7
I found the problem is caused by JDK 8 ea installed in my windows 7. IDEA use exe4j to load JDK, which automatically picked up JDK 8 (See this question).
After I defined IDEA_JDK_64 environment variable and point that to my JDK 6, a high performance IDEA comes back!
I had the exact same, but solved it by changing a setting the idea64exe.vmoptions:
from...
-XX:ReservedCodeCacheSize=64m
...to...
-XX:ReservedCodeCacheSize=256m
I had this problem with RubyMine (uses the same codebase) and it was because my system had swiched to OpenJDK instead of Sun/Oracle JDK.
I see that someone had similar problems in this thread: OpenJDK or Sun Java for IntelliJ IDEA
Specifically, do you see something like the following when you start your IDE from the terminal?
OpenJDK Runtime Environment (IcedTea6 1.11pre) (6b24~pre2-1)
OpenJDK Server VM (build 20.0-b12, mixed mode)
WARNING: You are launching IDE using OpenJDK Java runtime.
THIS IS STRICTLY UNSUPPORTED DUE TO KNOWN PERFORMANCE AND GRAPHICS PROBLEMS!
NOTE: If you have both Oracle (Sun) JDK and OpenJDK installed
please validate either IDEA_JDK, JDK_HOME, or JAVA_HOME environment variable points to valid Oracle (Sun) JDK installation.
See http://ow.ly/6TuKQ for more info on switching default JDK
Press Enter to continue.
Perhaps you should check if the upgrade caused the IDE to revert to a non-Oracle JDK.
In my case it was a Findbugs plugin that caused frequent lags. You can see this if you run IDEA from the terminal and look at the log output, e.g.
No classfiles specified; output will have no warnings
After disabling the real-time Findbugs scans (Settings -> Inspections -> Findbugs IDEA) everything ran smoothly again.
I am using Windows 7 32-bit OS. I am using Eclipse 3.7 (Indigo) 32 bit. I have jdk1.7.0_07 32-bit installed. And sometimes when I go to run Eclipse as administrator, I get the following error message,
And when I tap "OK", I get the following error message,
And sometimes I get this error message. And at other times, Eclipse will launch, but fail when Gradle goes to initialize its VM when attempting to start its daemon process.
What's happening? I realize it's a memory issue, but why am I able to launch Eclipse once in a while and run everything just fine? And at other times, why I am able to launch Eclipse but not able to run anything, or unable to launch Eclipse at all?
As a developer, this behavior is a nuisance.
Try -Xmx900m. The problem might be with the eclipse.ini file.
I've had this problem with JDK7. I've found that i do better with eclipse if it runs under Java 6, and then you add JDK7 as the runtime environment for your project.
Make sure that your eclipse matches your jre/jdk bitwise. If you are using 32-bit eclipse, you must use 32-bit jdk.
Your -vm param is wrong. The arg must start on the next line like this:
-vm
c:\Program Files\java... etc
When the JVM (Sun's JVM) starts it allocates the heap as a single malloc, a single contiguous block of memory. If, for any reason, that much contiguous memory is not available then the JVM will not start. Without debugging your machine is hard to know what could be blocking a big malloc. Note that some viruses recently have been taking shelter inside the jvm.
you said that your's is a 32 bit os is you your eclipse is 32 bit compatable or 64 bit if it is 64 bit remove the java related folder in your eclipse and replace it with 64 bith java sdk this will work i got this problem and i got it solved in this way.
Are there known Tomcat 6.0 and JDK 1.7.0_02 issues?
I know this is a hard question to answer, if the answer is no. But I need to ask just in case the answer is yes. Also I will accept any solutions to the issues below as answers. Please just share whatever issues you have had, and I will update this question if need be.
Issues:
Some issues I have run into since upgrading from JDK 1.7.0 to 1.7.0_02 (which I did to avoid the Eclipse's help menus from crashing, due to a Java 1.7.0 bug.):
Tomcat server takes much longer to start, I need a 120 second timeout to handle it.
FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197) error, which disappeared the next day and then reappeared the third day, with no changes other than reloading Eclipse.
Tomcat server takes much longer to shut down. I need a 60 second timeout to handle it, from 15 second default.
Eclipse itself appears to crawl to a halt (figuratively speaking) upon building the workspace and validating the project at hand. Everything within Eclipse appears to take longer, even opening an unopened file.
Everything seems suspicious.
P.S. JDK 1.7.0_02 is also known as 1.7.0u2, Java SE 7u2, Java SE 7 Update 2, etc.
Versions:
JDK = Oracle, 64-bit, downloaded from http://www.oracle.com/technetwork/java/javase/downloads/index.html. Exact file downloaded and installed was jdk-7u2-windows-x64.exe.
Tomcat = Tomcat 6.0.33, downloaded separately from Eclipse
Eclipse = Eclipse Java EE IDE for Web Developers., Version: Indigo Release, Eclipse Platform, Version: 3.7.0.v20110530-9gF7UHNFFt4cwE-pkZDJ7oz-mj4OSEIlu9SEv0f, Build id: I20110613-1736.
64-bit Windows 7 machine, 8GB RAM, Intel Core i7-2600 CPU # 3.4GHz (4 cores)
Eclipse, Tomcat, Apache HTTP Server, are all on the same (development) computer.
EDIT: Added system specs above.
When running 64 bits Java with default options (references compaction is off by default), it requires almost twice the amount of memory than with 32 bits.
For Eclipse, open the eclipse.ini file and double/increase a lot the -Xmx option.
Of course, your physical memory may not be enough when running some JVMs.
So I recommend you to test the -XX:+UseCompressedOops HotSpot option with 64 bits JVM and monitor memory usage thanks to jconsole for instance. You can also read details about that recent option. That option
For Tomcat, create the file bin/setenv.bat with content:
set JAVA_OPTS="-Xmx1024M -XX:+UseCompressedOops"
Well, perhaps it's all about the new JVM released in that update. It alledgedly improves performance but... well, who knows. JDT on Tomcat6 interacts with JDK 1.7 so unexpected things could happen.
Other than that, there're few things to check.