This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Product Version = NetBeans IDE Dev (Build 200705141800) Operating System = Windows XP version 5.1 running on x86 Java; VM; Vendor; Home = 1.6.0-rc; Java HotSpot(TM) Client VM 1.6.0-rc-b101; Sun Microsystems Inc.; d:\Java\jdk1.6.0\jre System Locale; Encoding = en_GB (nb); Cp1252
Created attachment 42402 [details] thread dump
I don't see a deadlock there. AWT is waiting for the document to be loaded and document loading is (probably temporarily) blocked on project mutex while examining the encoding. Project mutex is indirectly held by repository scan, but that's still on the CPU and running. The blockage of the editor is not nice though, and is directly caused by the encoding support.
encoding -> tzezula
It's more general problem, not related to the encoding, calling any project query from the EditorSupport will cause the same problem. Indeed it's not a deadlock the project query waits for the project lock, which is hold by the JavaSource Worker Thread doing universe scan. When the scan finishes the IDE will continue to work. Seems as an apisupport issue. Jardo, do you have any idea?
I don't see any issue in the thread dump. CloneableEditorSupport.loadDocument does have to wait to get the project lock, but it shouldn't be for long AFAICT, since it is only being held momentarily to load a subproject. But perhaps Mutex has poor fairness properties and keeps on granting the lock to the same thread (Java Source) even though Default RP has been waiting for it?
The NetBeans Mutex has no fairness. More specifically, if there are overlapping readers, no writer will ever enter.
See Jesse comment.
So what? Our Mutex can't be changed to to be fair (i.e. enqueue lately coming readers if there is already a writer enqueued), because that would mean readers couldn't enter even when the mutex is in shared state. (While such Mutex mode is generally possible and used in some scenarios, too much code in NetBeans depend on current unfair behavior and the change would produce way too many deadlocks. This is why there is a special case for this in MutexTest) At best, it would be possible to do a forceful thread switch on exit*Access (i.e. Thread.yield()) that may help in case the last reader leaves the read access (so the Mutex become uncontended). Still, are you sure this is the case? And please note that the encoding query is the only thing that performs project query during document opening.
>And please note that the encoding query is the only thing that performs project query during document opening. Is no argument, loaders does not forbid using queries, also it's quite obvious that encoding of the file is needed when the file is loaded|stored.
I cannot do much with this. The FEQ waits to obtain the ProjectManager.mutex(). The only question is if it's caused by the unfair behavior of the mutex or by long time spent in apisupport. The strange thing is that both the thread calling FEQ and the code loading projects want read access. Jesse do you have any idea? Also the issue is reported on JDK 1.6.0-rc which has problems with locking. To Reporter: Are you able to reproduce it? If so, can you try it with these options: -XX:-UseBiasedLocking -XX:-UseThreadPriorities?
Sorry, the conclusion about read access was wrong. The first thread is trying to enter a write lock, I've overlooked the leave method.
I can't reproduce any such freeze, including on projects which would reopen files, and including just opening a Java file directly with no projects open. If the only problem is that universe scanning is slower than it should be, well that is true, but this only really affects developers of nb.org modules, and I don't plan to touch that code for 6.0.
Closed. Haven't encountered it for long time.