Re: Netbeans failure mode
- From: Lew <noone@xxxxxxxxxxxxx>
- Date: Sat, 29 Nov 2008 14:09:48 -0500
secret decoder ring wrote:In other words, it said there is no NetBeans 6.5.
Lew wrote:
It said no such thing. What it actually said was that your NB 6.1 is up to date.
secret decoder ring wrote:
Which implies that there is no NetBeans 6.5, or any other number higher than 6.1.
No, it doesn't. Up-to-dateness checks for a specific version do not imply anything about the existence or non-existence of a later version.
I suppose you are technically correct that it did not explicitly *say* that, but it is a strong implication. "6.1 is the latest version" makes
It doesn't say "6.1 is the latest version". It says, "Your 6.1 version is up to date".
it very unlikely that there is a 6.5, since it is very uncommon (if it's
And yet, there is a 6.5 version of NetBeans. Doesn't that hint that your analysis needs enhancement?
Lew wrote:
He said "what are your times?" You haven't answered that question.
secret decoder ring wrote:
That's because I don't have an exact number. I'd have to shut down NB, dig up a stopwatch, and start it up again, and I can't be bothered to do that at the drop of a proverbial hat.
But you are investigating a specific problem that is hurting you, that's exactly what you need to do. That's just common sense.
I DID give an estimate, however, despite your implication above that I didn't.
I must have missed it. What was that estimate again?
secret decoder ring wrote:
I am not being snide about anything. I am simply pointing out that whatever it is, it is NOT NetBeans 6.1 and consequently might behave differently from NetBeans 6.1.
Agreed, but not, as it happens, with respect to your described behaviors, at least not in my experience.
That statement is in direct contradiction with my copy of NB 6.1 self-reporting as being the most recent NetBeans, presumably based on
Which it doesn't do. NetBeans 6.5 is the most recent version.
data it retrieved from the NB Web site that can reasonably be characterized as having come from the proverbial horse's mouth.
And yet NetBeans 6.5 is the most recent version. That's easily verifiable.
Of course, it could be the case that your statement is correct and my copy of NB 6.1 is in error (somehow failing to detect the existence of a more up to date version), rather than the other way around.
Depends on how you define "error". It happens that NB 6.5 is the most recent version of NB, and, from your evidence, that version 6.1 doesn't report that. Maybe, like many, many other software products, versions only report up-to-dateness in their own context and not that of some later version when it comes out.
Lew said:
Not observed here, that phenomenon. I've not seen that either with NB 6.1 on Linux or Windows.
secret decoder ring wrote:
That is very odd, in light of the above.
It just means that you have to investigate what's different between the setups. I suggest you examine netbeans.conf.
Lew:
Actually, it's extremely unlikely that it misuses the EDT that way, given the Java expertise involved in its development.
secret decoder ring wrote:
Then the behavior observed stems from another cause, unrelated to my network's speed, as I suspected all along.
Seems likely.
More likely it is something about swap in your OS or GC.
Doubtful, since I see the slow-when-start-page-displayed behavior even when the system's memory in use is smaller than the total physical memory available, and separately since it is not a transient state that goes away after a short time (as it would when something was finished being swapped in) but persists for as long as the start page is visible.
You haven't answered Mark Space's question about your OS
I most certainly have.
I corrected that typo before you responded.
but I would also look into your swap space allocation
2GB; and irrelevant (see above)
the -Xmx paramater in your netbeans.conf
Haven't touched this file, so this should still be the default, and so if this were the cause it would affect most copies of NB 6.1. Apparently most copies are unaffected, which points to the problem being elsewhere.
It is a mystery.
and what other apps are running at the same time. Having less RAM than
Mark Space's configuration, you could be seeing a swap artifact.
When NB has been foregrounded and in use for an hour plus and the system's total memory consumption at the time is only around 700MB out of a physical 1024?
Yes, that militates against that hypothesis.
The slow startup time is not a primary complaint of mine. But it makes problems that force the user to restart NB to be onerous enough for this reason that I think suggesting people just resign themselves to occasionally restarting NB is "not good enough".
Who made that suggestion? Not I.
I would look into your netbeans.conf.
Why? It is not possible that I've munged this file, for the simple
It's not a question of you "munging" the file, but of it perhaps not being optimal out of the box.
reason that I've not edited it. (Indeed, didn't know it existed until this post.) (I assume making some changes in NB's options dialogs might indirectly alter that file, but those dialogs should trap any attempt to enter unreasonable values, and I can't recall messing with anything to do with its memory use or related behaviors.)
You might wish to allocate a wee bit more -Xmx to NB
I doubt it. When it was doing its CPU-saturating-hang thing I noticed the process size was upwards of 200 megs. I infer that the -Xmx is 256M or more, which "ought to be enough", at least for the time being.
The process size is not a reliable indicator of maximum heap, quite the contrary. It actually indicates that -Xmx is far below 200 MB. Process size includes class space, the JVM itself and a host of non-heap allocations.
Since my copy's GC parameters are still the factory defaults, if those GC parameters were the problem, a large proportion of all NB 6.1 installs would be similarly affected, which you claim is not the case.
Perhaps, or perhaps not. Or perhaps more people who use NB are modifying netbeans.conf than you think.
In any event, empirical evidence is best. If you adjust the configuration and the problem goes away, Bob's your uncle.
--
Lew
.
- References:
- Netbeans failure mode
- From: secret decoder ring
- Re: Netbeans failure mode
- From: Mark Space
- Re: Netbeans failure mode
- From: secret decoder ring
- Re: Netbeans failure mode
- From: Lew
- Re: Netbeans failure mode
- From: secret decoder ring
- Netbeans failure mode
- Prev by Date: Re: Replace synchronized with AtomicInteger: does this work?
- Next by Date: Re: Netbeans failure mode
- Previous by thread: Re: Netbeans failure mode
- Next by thread: Re: Netbeans failure mode
- Index(es):
Relevant Pages
|
