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 185526 - Give parsing API chance to suspend background refresh
Summary: Give parsing API chance to suspend background refresh
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 6.x
Hardware: Other Linux
: P1 normal (vote)
Assignee: Tomas Zezula
Depends on:
Blocks: 177274
  Show dependency tree
Reported: 2010-05-05 15:25 UTC by Jaroslav Tulach
Modified: 2010-05-12 04:13 UTC (History)
2 users (show)

See Also:
Exception Reporter:

priorityIO(Runnable) (13.26 KB, patch)
2010-05-05 15:27 UTC, Jaroslav Tulach
Details | Diff
Problematic snapshot (6.03 KB, application/octet-stream)
2010-05-05 20:28 UTC, Tomas Zezula
PriorityIO changed (24.75 KB, patch)
2010-05-06 16:10 UTC, Tomas Zezula
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2010-05-05 15:25:19 UTC
Various snapshots indicate that one reason for slowness of Go To Type dialog is the background refresh (triggered after main window being activated). It is supposed to watch for I/O load automatically, but it seems that it takes time before the I/O load is high enough. This needlessly steals I/O capacity desperatelly needed elsewhere.

We need a hint that parsing API can use to suspend the background I/O manually.
Comment 1 Jaroslav Tulach 2010-05-05 15:27:30 UTC
Created attachment 98498 [details]
Comment 2 Vitezslav Stejskal 2010-05-05 19:11:33 UTC
VS01: How exactly is parsing.api meant to use this? Are all index queries meant to run as PE.priorityIO()? If so, parsing.api will need to depend on masterfs. Is it ok?

VS02: PE.priorityIO's javadoc seems confusing - "Allows registered exceptions to execute..." - what 'exceptions'? Also the value of @Since tag is wrong. It should read 2.25, I think.
Comment 3 Tomas Zezula 2010-05-05 20:26:41 UTC
Thanks Jardo.
I will try it and let you know.
VS01: There are two use cases.
1st) TaskProcessor.runUserActionTask should become priorityIO. Several slowness in code completion, go to decl are caused by the background refresh.
2nd) The GoTo * should be guarded by the priority IO.
Comment 4 Tomas Zezula 2010-05-05 20:28:18 UTC
Created attachment 98521 [details]
Problematic snapshot

Here is one of the typical problematic snapshots.
Comment 5 Tomas Zezula 2010-05-06 11:51:48 UTC
Cau Jardo,
can the runPriorityIO take rather MutexAction.ExceptionAction or Callable than Runnable. Runnable is problematic as the parsing API task may throw ParseException and it's hard to re throw it.
Comment 6 Tomas Zezula 2010-05-06 16:10:28 UTC
Created attachment 98576 [details]
PriorityIO changed
Comment 7 Tomas Zezula 2010-05-06 16:13:01 UTC
I've rewritten the parsing.api to use the priorityIO.
I've also changed:
1) priorityIO takes j.u.c.Callable<T> not Runnable.
2) I've made the method static as I've not found a way how to get an instance of ProvidedExtension (except of new ProvidedExtension()). If there is a way feel free to change it back to non static.
Comment 8 Jaroslav Tulach 2010-05-10 08:48:59 UTC
Thanks for refining my patch to be usable, Tomáši! If it is also beneficial (together with your changes), please proceed with integration.
Comment 9 Tomas Zezula 2010-05-10 09:11:29 UTC
Thanks Jardo, the patch improved the performance significantly.
I will integrate it.
Comment 10 Tomas Zezula 2010-05-10 11:59:07 UTC
Integrated into jet-main 894fe07157c0
Comment 11 Tomas Zezula 2010-05-10 13:30:39 UTC
java.source: jet-main:c45560a7aa8c
Comment 12 Quality Engineering 2010-05-12 04:13:34 UTC
Integrated into 'main-golden', will be available in build *201005112200* on (upload may still be in progress)