[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.newcomer] Re: Eclipse hates me! Help requested please:

On Wed, 01 Aug 2007 11:03:27 -0400, Eric Rizzo wrote:

> Kevin Crocker wrote:
>> On Tue, 31 Jul 2007 12:10:11 -0400, Eric Rizzo wrote:
>> 
>>> Kevin Crocker wrote:
>>>> Thanks for the explanation. It helps a lot - unfortunately, the --launcher...
>>>> one doesn't actually set the MaxPermGen higher than 64M - I tried this
>>>> and set it t0 128M and the Memory Monitor still says that PermGen is set
>>>> to 64M
>>> What "Memory Monitor" are you talking about that shows Perm Gen size? 
>> 
>> The memory monitor that is listed as an attachment in the eclipse Bug
>> for PermGen, I think I still have it as a gz file and could send it to you
>> or post it somewhere --- or I could go and find the bug at eclipse again
>> 
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=92250
>> 
>> It's listed as a tweaked version of Memory Monitor and it shows a bunch
>> of nice bars - but if you hold your mouse over each bar it tells you
>> what the bar means and it's size -- try it out 
>> 
>> now, of course, I could be getting led down a garden path, but I doubt it
>> as this bug discussion is mostly by serious eclipse coder types.
> 
> I'll give the tool a try. At the very least to make sure it shows that 
> my Perm Gen size is increased (which I know it is because I used to get 
> the problem before increasing it).
> 
> 
>>> I can assure you that if Eclipse is indeed running in a Sun JVM it will 
>>> set the Perm Gen size with that option. Can you confirm the JVM that 
>>> Eclipse is running in (Help > About Eclipse > Configuration Details)
>> 
>> I can assure you that I am running SUN's JVM because that's all that's
>> installed on this machine.
> 
> Don't be so sure, unless you're using the -vm paramter. Without -vm in 
> eclipse.ini or on the command line, it is VERY VERY common for Eclipse 
> to find a "bad" JVM before finding a Sun one you installed yourself.
> In the interest of trying to figure out why the Perm Gen size on your 
> machine is not getting set, please either use the About Eclipse dialog 
> as I suggested above or specify -vm in your eclipse.ini to be sure. It 
> will only take a couple of minutes and it will get me to stop harping on 
> you to verify your VM vendor and version. :-)

Here's what the output of the About Eclipse box says:

eclipse.buildId=I20070625-1500
... stuff deleted
-vm
/usr/lib/jvm/java-1.5.0-sun-1.5.0.11/jre/bin/../lib/i386/client/libjvm.so

and a little later on is
eclipse.vm=/usr/lib/jvm/java-1.5.0-sun-1.5.0.11/jre/bin/../lib/i386/client/libjvm.so

and still further down is:

java.endorsed.dirs=/usr/lib/jvm/java-1.5.0-sun-1.5.0.11/jre/lib/endorsed
java.ext.dirs=/usr/lib/jvm/java-1.5.0-sun-1.5.0.11/jre/lib/ext
java.home=/usr/lib/jvm/java-1.5.0-sun-1.5.0.11/jre
java.io.tmpdir=/tmp
java.library.path=/usr/lib/jvm/java-1.5.0-sun-1.5.0.11/jre/lib/i386/client::/usr/lib/jvm/java-1.5.0-sun-1.5.0.11/jre/lib/i386::/usr/lib/mozilla-firefox:/usr/lib/mozilla-firefox
java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition
java.runtime.version=1.5.0_11-b03java.specification.name=Java Platform API Specification
java.specification.vendor=Sun Microsystems Inc.
java.specification.version=1.5
java.vendor=Sun Microsystems Inc.
java.version=1.5.0_11
java.vm.info=mixed mode, sharing
java.vm.name=Java HotSpot(TM) Client VM
java.vm.specification.name=Java Virtual Machine Specification
java.vm.specification.vendor=Sun Microsystems Inc.
java.vm.specification.version=1.0
java.vm.vendor=Sun Microsystems Inc.
java.vm.version=1.5.0_11-b03

I'm reasonably confident that this is SUN's JVM :-)

Here's what I don't see which is in my eclipse.ini:

--launcher.XXMaxPermSize
256M

So somehow, this eclipse.ini option appears to be vanishing into thin air.
 
>> And I can also assure you that despite setting the MaxPermGen with the
>> --launch (which by the way was already set - the eclipse people did
>> that automagically upon detecting SUN JVM) or by setting it manually
>> and experimenting with different values, it does not change the PermGen
>> size. I've read through all of SUN's documents on this too, and even
>> SUN says that the -X and -XX parameters are not guaranteed to work.
>> This one doesn't on my machine.
>> 
>>> You can always try forcing the max perm gen setting to your JVM by
>>> adding "-XX:MaxPermSize=128m" (line by itself, without quotes) after
>>> the -vmargs line.
>> 
>> I did that too - I changed this 12 times to different numbers, and
>> every single time, the Memory Monitor showed that I always had 64M ---
>> but more importantly, Eclipse 3.3 kept dying after a very short time -
>> sometimes as little as one or two clicks.
> 
> That is what makes me think the VM Eclipse is using is not the one you
> think it is. If it turns out to be the right JVM, there appears to be a
> bug in the JVM or some kind of conflict on your system preventing the
> perm gen size from getting set.

There is a bug in the JVM. SUN seems to be aware of it - but doesn't
seem to be interested in doing much about it except to tell people to
use an unsupported and unreliable command line parameter - the one
we've been discussing. Although, I did find a page that lists all the
currently unsupported and potentially unreliable command line parameters.
 
> Eclipse is dying because 64MB is simply not enough perm gen space for an
> app with lots of classes. "Core" Eclipse does not likely reach that
> limit, but when you add a massive set of plugins like MyEclispe or WTP,
> it bumps its head on that ceiling quite easily.

Yes, I know :-) And isn't that because of the way they changed some of
the class loaders etc, for version Java 5

It seems to me that whatever they did was an incomplete thought session.
They may have solved other problems but they sure have created a large
problem of another kind. They have made it impossible to use their JVM
with what is likely the most popular IDE - Eclipse. As in my case, I'm
much more likely to dump SUN's JVM than I am to dump Eclipse. This is both
bad marketing/business and bad computing.

>> I suggest you read the above bug discussion. I found it shortly after I
>> had posted this thread.
> 
> Oh I have - if you look closely you'll see my name in several comments
> to that bug discussion.

I apologize. The thread was long enough and I find it to be a difficult
format to read through, looking for names makes it even more difficult.

Thanks for your kind assistance here though - it has at least helped 
me to go read through bug reports and for that I'm grateful - I've learned
something.

Kevin