I run my Java application in Eclipse and see these two thing in Task Manager:
Before I start my application, Eclipse uses ~0% CPU. What exactly does Eclipse do after my program started?
If I run my application without Eclipse, will there be any difference in my Java process CPU usage in the case that my JVM settings are the same with Eclipse?
Eclipse has to read your program output to display it in the console, for example, which can take a bit of resources, especially if your program generates lots of output and/or long lines of output (in my experience, the Eclipse console is quite slow). I suppose you're not running in debug mode, in which case Eclipse would have to do more to handle the debugging.
So your application running outside Eclipse may go a bit faster, yes.
You can of course run something like jvisualvm to get a thread dump of Eclipse while your program is running to find out exactly Eclipse is doing.
Related
I am running multiple executions in my Eclipse. One is supposed to run for weeks and just crunch data. But at the same time I develop and regularly kill processes during i.e. debugging. It often happens that I accidentally kill the wrong task and days of calculations are gone. I do not really want to duplicate/split workspaces. Ideally I want to lock the long term task, so I have to unlock/confirm before it can be terminated. I googled but did not get any helpful results.
Eclipse Version:
Eclipse IDE for Java Developers
Version: 2020-03 (4.15.0)
I use ubuntu16.04 in VMware for learning Hadoop. The eclipse is Eclipse IDE for Java Developers at 2020.03 for linux_64.
And when use eclipse to write some java code, the IDE usually exits by itself without any error. And the eclipse is too slow when I use it. I guess that whether the memory is not enough for using IDE. But I found the memory is free when I check it. I allocated 2G of memory for ubuntu16.04.
And I search for this problem on web. I found many people believe the problem is eclipse caused. So they come up with a way to edit eclipse.ini.
-Dorg.eclipse.swt.browser.DefaultType=mozilla
Add this command to the last line of eclipse.ini.
Unfortunately, it doesn't work. So Do u know why? Should I allocate more memory for VMware?
I've been working on a small set of command line programs in Scala. While
developing I used SBT, and tested the program with run within the console. At
this point the programs had a fast startup time (when re-run after initial compilation); nearly instant, even
with additional dependencies.
Now that I'm trying to actually utilize them on my system outside of sbt, the speeds have noticeable lag. I'm looking for ways to
reduce this, since the nature of these utilities requires little to no delay.
The best speeds I've achieved so far has been through utilizing Drip. I include all dependencies in a lib directory by utilizing Pack and then run by executing a shell script like this:
#!/bin/sh
SCRIPT=$(readlink -f "$0")
SCRIPT_PATH=$(dirname "$SCRIPT")
PROG_HOME=`cd "$SCRIPT_PATH/../" && pwd`
CLASSPATH_SUFFIX=""
# Path separator used in EXTRA_CLASSPATH
PSEP=":"
exec drip \
-cp "${PROG_HOME}/lib/*${CLASSPATH_SUFFIX}" \ # Add lib directory to classpath
TagWorkspace "$#" # TagWorkspace is the main class
This is still noticeably slower then invoking run from within SBT.
I'm curious as to why SBT is able to startup the application so much faster, and if there is someway for me to levarage its strategy, or SBT itself, even if that means keeping a long living process around to actually run a command through.
Unless you have forking turned on for your run task, this is likely due to VM startup time. When you run from inside an active SBT session, you have an already initialized VM pointing at your classes - all SBT needs to do is create a new ClassLoader and point it at your build output directory. This bypasses all of the other (not insignificant) stuff that happens when you fire up a new VM.
Have you tried using the client VM to start your utility from the command line? Sadly, this isn't an option with 64-bit Java, since Oracle apparently doesn't want to support it, but if you're using a 32-bit VM, try adding the -client argument to the list that you give the VM from the command line.
If you are using a 64-bit VM, some googling will find you some unofficial forks of OpenJDK that have the client VM re-enabled. It's really just a #define in the JVM build itself - it works fine once it's been compiled in.
The only slowness I have is launching SBT. Running a hello-word Scala app with java (no Drip) version 1.8 on a 7381 bogomips CPU takes only 0.2 seconds.
If you're not in that magnitude, I suspect your application startup requires loading thousands of classes, and creating instances of them.
I'm having problems debugging a JNI application. I've read several threads in StackOverflow, like this one, this one or this one. I've also tried to start gdb in a separated shell and attach it to the running java process. In both cases, the problem is the same: GDB can't find the sources to debug. Things tried
Add "dir" line to gdbinit, pointing to C++ sources folder
Adding the C++ sources folder to the GDB debbuging configuration in Eclipse, in the "Sources" tab.
Adding set environment LD_LIBRARY_PATH=/path/to/library.so, being library.so the library file built from C++ source files
Attach ddd to the java process, but then I get an error because pthread_join.c is not found in the working directory. I don't have this file in my hard disk. I don't know what is this about.
Nothing worked. I've spent several days on this. I know my bug is in the C++ code called by the JNI wrapper, but I can't debug it. Any hints? If helps, I'm running Eclipse Juno in Debian 7 under a Parallels VM on Mac OS.
Many thanks in advance,
You need to have debug information in your native library. You should pass -g to your compiler and linker to have this information in the executable. You may also want to add -O0.
As an alternative to attaching to the Java process, you can create a C++ app and debug it directly. You just need to link in the functions you want to test. In the main function, create the VM, register the functions with RegisterNatives, and kick off a Java test class the uses them.
Hopefully, the debugger has no problem finding the sources since it is just part of the normal compile/link/debug loop of a C++ app.
I would suggest to start with the latest ADT bundle. You can even download the Mac version, so you will not even need Parallels (see a detailed instructions). Then, choose Debug Android Native Application in launch menu.
I use Eclipse Helios for developing J2ME applications. I wanted to know if there was a way I could see the background/text-line commands that are executed for each click/action on the GUI (eg. Compile, Run, Creating a J2ME package). I am interested in it so I can run through the process using a script.
There is nothing specific that you can do to see all commands run in Eclipse. First, there is no one to one mapping between code being executed in Eclipse and java commands that you might run from the command line. So, even though you might be able to view individual commands in vim or Emacs, you won't be able to do this Eclipse.
However, there are some things that may help. There is a platform tracing facility that will print some trace messages to stdout. However, this is not widely used outside of core Eclipse projects so you won't be able to get full tracing on all commands. Also, this facility is not meant to be a general tracing facility, but really only for a few plugins that you are interested in. You can find more information about it here:
http://wiki.eclipse.org/FAQ_How_do_I_use_the_platform_debug_tracing_facility%3F
So, you will need to create a .options file in your Eclipse install directory with something like the following contents:
org.eclipse.platform/debug=true
org.eclipse.ui/debug=true
org.eclipse.core.runtime/debug=true
org.eclipse.core.resources/debug=true
org.eclipse.core.commands/debug=true
org.eclipse.core.filesystem/debug=true
org.eclipse.core.jobs/debug=true
These are a few of the low-level Eclipse plugins that will very likely contain some tracing information. However, without knowing more about what you are trying to do, it is hard to recommend specific plugins to trace.