I have a problem that I've tried to figure out, but without much progress.
I run Fedora Eclipse with an UML plugin. Very often Eclipse seems to be stuck in some sort of loop where the java VM is using appr. 50% CPU (dual core = 100% of one core?). The result is that Eclipse shuts down after a few minutes. (This happens with ArgoEclipse and Omondo EclipseUML Community Edition)
I have found some advice suggesting I should try to increase the VM's memory, but they use flags with the java... command used to run the normal Eclipse. I have not figured out how to do this with Fedora Eclipse.
FC6 x86_64, SunJDK 1.5
I'll be greatful for some pointers... Frode Petersen
On 2/22/07, Frode Petersen fropeter@online.no wrote:
I have a problem that I've tried to figure out, but without much progress.
I run Fedora Eclipse with an UML plugin. Very often Eclipse seems to be stuck in some sort of loop where the java VM is using appr. 50% CPU (dual core = 100% of one core?). The result is that Eclipse shuts down after a few minutes. (This happens with ArgoEclipse and Omondo EclipseUML Community Edition)
This sounds to me like a bug in the Eclipse distribution you are using or a bug in the UML plugin. You would have better luck asking this question in a forum for the Eclipse distriubtion or plugin. This mail list is for the Fedora Linux distribution. Your problem is definitely not caused by Fedora.
I have found some advice suggesting I should try to increase the VM's
memory, but they use flags with the java... command used to run the normal Eclipse. I have not figured out how to do this with Fedora Eclipse.
I start Eclipse using a shell script where I set up the environment variables and vm arguments before calling the Eclipse executable.
charlie
Charles Tuckey skrev:
On 2/22/07, *Frode Petersen* <fropeter@online.no mailto:fropeter@online.no> wrote:
I have a problem that I've tried to figure out, but without much progress. I run Fedora Eclipse with an UML plugin. Very often Eclipse seems to be stuck in some sort of loop where the java VM is using appr. 50% CPU (dual core = 100% of one core?). The result is that Eclipse shuts down after a few minutes. (This happens with ArgoEclipse and Omondo EclipseUML Community Edition)This sounds to me like a bug in the Eclipse distribution you are using or a bug in the UML plugin. You would have better luck asking this question in a forum for the Eclipse distriubtion or plugin. This mail list is for the Fedora Linux distribution. Your problem is definitely not caused by Fedora.
I have found some advice suggesting I should try to increase the VM's memory, but they use flags with the java... command used to run the normal Eclipse. I have not figured out how to do this with Fedora Eclipse.I start Eclipse using a shell script where I set up the environment variables and vm arguments before calling the Eclipse executable.
charlie
Thank you for the answer!
You might be right in the cause for the behaviour, and if I used the pure Eclipse.org version of Eclipse, I would have placed the question there.
But I am using the Fedora version of Eclipse, which is a precompiled version using the java stack included with Fedora, and since it is precompiled, I don't have access directly to the java VM used, thus I can't use a startup script as you suggested. Because of this there should be some means by which I could configure the memory usage and possibly other things regarding that VM. I have not as yet found any conclusive info on where that configuration is done in the Fedora version of Eclipse. Or am I completely confused here?
If I find that this is not a memory related issue, then I will go the road you outlined, but right now I would be greatful for this information.
Frode
Hi,
* Frode Petersen fropeter@online.no [2007-02-23 07:25]:
But I am using the Fedora version of Eclipse, which is a precompiled version using the java stack included with Fedora, and since it is precompiled, I don't have access directly to the java VM used, thus I can't use a startup script as you suggested.
This is incorrect. We build the bytecode exactly the same as upstream: with the JDT Core compiler, ecj. After the build is done - the exact same as upstream - we natively-compile all of the jars with gcj to shared libraries which can be used by gij. But you said you were running with the Sun VM so all you're using is the bytecode. /usr/bin/eclipse is the binary (native) launcher just like upstream that is used to spawn the VM. In the case of Sun, at least, the memory flags in the file I mention below should be respected.
Because of this there should be some means by which I could configure the memory usage and possibly other things regarding that VM. I have not as yet found any conclusive info on where that configuration is done in the Fedora version of Eclipse. Or am I completely confused here?
You can fiddle with memory stuff (mx, etc.) in /usr/share/eclipse/eclipse.ini. It's the same as upstream except that it's owned by root and managed by RPM instead of just an exploded tarball :) .
You may get some more tips if you ask on fedora-devel-java-list as some of the people there may have more experience with this kind of situation.
One thing to confirm is that you are indeed running with the Sun VM. If you've downloaded plugins that aren't shipped with Fedora, they don't contain the gcj-compiled bits and if you're just running with our stock setup, they'll be purely interpreted by gij. They'll run slower than if there are .sos corresponding to the jars. But if you're running with the Sun VM then that's irrelevant.
Andrew
(OT - The quoted message didn't show up in my fedora-list mail, although it was sent there; only in my private mail. Is this normal?)
Andrew Overholt skrev:
Hi,
- Frode Petersen fropeter@online.no [2007-02-23 07:25]:
But I am using the Fedora version of Eclipse, which is a precompiled version using the java stack included with Fedora, and since it is precompiled, I don't have access directly to the java VM used, thus I can't use a startup script as you suggested.
Snip<
Or am I completely confused here?
This is incorrect. We build the bytecode exactly the same as upstream: with the JDT Core compiler, ecj. After the build is done - the exact same as upstream - we natively-compile all of the jars with gcj to shared libraries which can be used by gij.
Completely confused then.;-) Good to get this right.
But you said you were running with the Sun VM so all you're using is the bytecode. /usr/bin/eclipse is the binary (native) launcher just like upstream that is used to spawn the VM. In the case of Sun, at least, the memory flags in the file I mention below should be respected.
Because of this there should be some means by which I could configure the memory usage and possibly other things regarding that VM. I have not as yet found any conclusive info on where that configuration is done in the Fedora version of Eclipse.
You can fiddle with memory stuff (mx, etc.) in /usr/share/eclipse/eclipse.ini. It's the same as upstream except that it's owned by root and managed by RPM instead of just an exploded tarball :) .
Thank you for this! I'll see if it helps.
You may get some more tips if you ask on fedora-devel-java-list as some of the people there may have more experience with this kind of situation.
One thing to confirm is that you are indeed running with the Sun VM. If you've downloaded plugins that aren't shipped with Fedora, they don't contain the gcj-compiled bits and if you're just running with our stock setup, they'll be purely interpreted by gij. They'll run slower than if there are .sos corresponding to the jars. But if you're running with the Sun VM then that's irrelevant. Andrew
One of the plugins refused to run with less than Java 1.5, I have not checked the other in that respect. But what you're saying here, if I get you right, is that if I need Java 1.5, there wouldn't be any advantage in using Fedora Eclipse over the upstream version, but if the Fedora Java stack suffices for the plugins, Eclipse itself would run faster, although the plugins won't benefit. Confused again? :-)
Frode
On Mon, 2007-02-26 at 12:24 +0100, Frode Petersen wrote:
(OT - The quoted message didn't show up in my fedora-list mail, although it was sent there; only in my private mail. Is this normal?)
Sounds like someone replied to you, rather than the list. People occasionally do that.
Tim skrev:
On Mon, 2007-02-26 at 12:24 +0100, Frode Petersen wrote:
(OT - The quoted message didn't show up in my fedora-list mail, although it was sent there; only in my private mail. Is this normal?)
Sounds like someone replied to you, rather than the list. People occasionally do that.
No the recipient was fedora-list@redhat.no, I was CC.
Frode
Frode Petersen:
(OT - The quoted message didn't show up in my fedora-list mail, although it was sent there; only in my private mail. Is this normal?)
Tim:
Sounds like someone replied to you, rather than the list. People occasionally do that.
Frode Petersen:
No the recipient was fedora-list@redhat.no, I was CC.
Okay... That's a bit different from how you described it the first time around. Some people will do that, too. It's an unusual to do, though. There's no reason for it.
If, in your original post, you mean that it didn't filter through as other list mail did, you'd have to tell us how you do your filtering.
Frode Petersen:
No the recipient was fedora-list@redhat.no, I was CC.
Okay... That's a bit different from how you described it the first time around. Some people will do that, too. It's an unusual to do, though. There's no reason for it.
If, in your original post, you mean that it didn't filter through as other list mail did, you'd have to tell us how you do your filtering.
Aarrgh!! Sorry for the bandwith wasted! Of course the filter setup was at fault. I filtered only on List-ID.
Sorry, Frode
* Frode Petersen fropeter@online.no [2007-02-26 06:24]:
One thing to confirm is that you are indeed running with the Sun VM. If you've downloaded plugins that aren't shipped with Fedora, they don't contain the gcj-compiled bits and if you're just running with our stock setup, they'll be purely interpreted by gij. They'll run slower than if there are .sos corresponding to the jars. But if you're running with the Sun VM then that's irrelevant. Andrew
One of the plugins refused to run with less than Java 1.5, I have not checked the other in that respect.
Then you must use the Sun (or IBM or BEA) VM. gcj in rawhide has just recently merged in the 1.5 branch of GNU Classpath so you can expect that in Fedora 7.
But what you're saying here, if I get you right, is that if I need Java 1.5, there wouldn't be any advantage in using Fedora Eclipse over the upstream version, but if the Fedora Java stack suffices for the plugins, Eclipse itself would run faster, although the plugins won't benefit. Confused again? :-)
I don't think it's worth talking about absolute performance of gcj-compiled binaries vs. the Sun JIT 'cause there are a lot of factors and it's difficult to get hard numbers that apply in all cases.
As for using Fedora Eclipse over an upstream download, it's up to you. We include a few patches. These have either been applied upstream after the release we're shipping or are useful for multi-user, RPM-based installations. There's also the benefit of having it installed and managed by yum and the whole RPM infrastructure but I figure that goes without saying :)
Andrew
Andrew Overholt skrev:
- Frode Petersen fropeter@online.no [2007-02-26 06:24]:
One thing to confirm is that you are indeed running with the Sun VM. If you've downloaded plugins that aren't shipped with Fedora, they don't contain the gcj-compiled bits and if you're just running with our stock setup, they'll be purely interpreted by gij. They'll run slower than if there are .sos corresponding to the jars. But if you're running with the Sun VM then that's irrelevant. Andrew
One of the plugins refused to run with less than Java 1.5, I have not checked the other in that respect.
Then you must use the Sun (or IBM or BEA) VM. gcj in rawhide has just recently merged in the 1.5 branch of GNU Classpath so you can expect that in Fedora 7.
But what you're saying here, if I get you right, is that if I need Java 1.5, there wouldn't be any advantage in using Fedora Eclipse over the upstream version, but if the Fedora Java stack suffices for the plugins, Eclipse itself would run faster, although the plugins won't benefit. Confused again? :-)
I don't think it's worth talking about absolute performance of gcj-compiled binaries vs. the Sun JIT 'cause there are a lot of factors and it's difficult to get hard numbers that apply in all cases.
As for using Fedora Eclipse over an upstream download, it's up to you. We include a few patches. These have either been applied upstream after the release we're shipping or are useful for multi-user, RPM-based installations. There's also the benefit of having it installed and managed by yum and the whole RPM infrastructure but I figure that goes without saying :)
Andrew
Thank you for the clarifications!
Frode
Andrew Overholt skrev:
- Frode Petersen fropeter@online.no [2007-02-26 06:24]:
One thing to confirm is that you are indeed running with the Sun VM. If you've downloaded plugins that aren't shipped with Fedora, they don't contain the gcj-compiled bits and if you're just running with our stock setup, they'll be purely interpreted by gij. They'll run slower than if there are .sos corresponding to the jars. But if you're running with the Sun VM then that's irrelevant. Andrew
One of the plugins refused to run with less than Java 1.5, I have not checked the other in that respect.
Then you must use the Sun (or IBM or BEA) VM. gcj in rawhide has just recently merged in the 1.5 branch of GNU Classpath so you can expect that in Fedora 7.
But what you're saying here, if I get you right, is that if I need Java 1.5, there wouldn't be any advantage in using Fedora Eclipse over the upstream version, but if the Fedora Java stack suffices for the plugins, Eclipse itself would run faster, although the plugins won't benefit. Confused again? :-)
I don't think it's worth talking about absolute performance of gcj-compiled binaries vs. the Sun JIT 'cause there are a lot of factors and it's difficult to get hard numbers that apply in all cases.
As for using Fedora Eclipse over an upstream download, it's up to you. We include a few patches. These have either been applied upstream after the release we're shipping or are useful for multi-user, RPM-based installations. There's also the benefit of having it installed and managed by yum and the whole RPM infrastructure but I figure that goes without saying :)
Andrew
Thank you for the clarifications!
Frode
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
I ran into the same problems some time ago. Apart from the compiler and Java version to be installed, are you using CDT within Eclipse? And do you have C/C++ Indexing set to Full?, Then the Indexer lets you run out of memory. You can change the VM arguments in Window-Preferences->Java-Installed JREs. Select JRE, edit. My VM args are as follows: -vmargs -Xms512m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=128m
These settings work for me with 1GB of RAM.
I hope this is useful for someone.
-
Andrew Overholt -
Charles Tuckey -
Frode Petersen -
Jeroen Lankheet -
Tim