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.

Bug 219595 - Deadlock in FileObjectFactory.refreshFromGetter during ClassLoading
Summary: Deadlock in FileObjectFactory.refreshFromGetter during ClassLoading
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 7.3
Hardware: PC Linux
: P2 normal (vote)
Assignee: Jaroslav Tulach
URL:
Keywords: THREAD
Depends on:
Blocks: 219059
  Show dependency tree
 
Reported: 2012-10-05 12:38 UTC by Jiri Skrivanek
Modified: 2013-01-30 11:00 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Thread dump. (35.97 KB, text/plain)
2012-10-05 12:38 UTC, Jiri Skrivanek 		Details
isClassLoading consume 17.5% (170.96 KB, application/octet-stream)
2012-12-19 09:26 UTC, Alexander Simon 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Skrivanek 2012-10-05 12:38:37 UTC 
Created attachment 125451 [details]
Thread dump.

IDE was freezed while running automated tests. The test was changing properties of web JSF project. I suspect threads RepositoryUpdater.worker and ErrorAnnotator worker are blocked.
Comment 1 Tomas Zezula 2012-10-17 13:24:18 UTC 
In fact the evaluation is wrong.
There is not dead lock among RU and EA.
The EA waits on lock held by RU which waits for FS which are waiting.
Comment 2 Jaroslav Tulach 2012-10-24 15:58:36 UTC 
Do I remember correctly that the problem is that call made via JarClassLoader to load a class is considered as an I/O and the system tries to slow it down, Tomáši? And that I am supposed to detect the call goes through JarClassLoader and don't let masterfs block?
Comment 3 Jaroslav Tulach 2012-12-06 10:31:41 UTC 
ergonomics#644122033a57
Comment 4 Quality Engineering 2012-12-12 02:44:05 UTC 
Integrated into 'main-golden', will be available in build *201212120001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/644122033a57
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #219595 and #219059: Trying to avoid any I/O suspend tricks when inside of classloading.
The detection of the classloading is brutal, but should only happen when the system is ready to switch to I/O idle mode - e.g. inspecting own stacktrace should be relatively cheap operation copared to that.
Comment 5 Alexander Simon 2012-12-19 06:29:37 UTC 
Jaroslav, I see method isClassLoading() in hot spot list. It can consume up to 25% CPU time. Are you sure that method has right implementation?
Comment 6 Alexander Simon 2012-12-19 09:26:54 UTC 
Created attachment 129529 [details]
isClassLoading consume 17.5%
Comment 7 Alexander Simon 2013-01-30 11:00:05 UTC 
(In reply to comment #5)
> Jaroslav, I see method isClassLoading() in hot spot list. It can consume up to
> 25% CPU time. Are you sure that method has right implementation?
Ok, there is no response. Filed separate bug #225521