intellij-community icon indicating copy to clipboard operation
intellij-community copied to clipboard

IDEA-130373 Still "do highlight during VFS refresh" but fix frequent …

Open acejingbo opened this issue 4 years ago • 2 comments

https://github.com/JetBrains/intellij-community/commit/01e0d412641e52bb4185517928bbbd9e7a21c13f#diff-4497b4c4afdd25574053db8b6de01a43669c1b3200a5d4d31d14da002614e400 fixed highlight to no longer blocked by VFS refresh, which is good.

However, once highlight do start with all passes (heavy process beside vfs refresh finished), highlight keeps getting interrupted (daemon cancel & restart), as it listen to every single HeavyProcess's stopProcess.
For example,

  • for a small file it restarted 5 times or so when highlighting
  • for a big file that took really long to highlight, it get interrupted for like 600+ times.

Each Interruption looks like this (I added some local debug log for heavy process start/end and Update Runnable scheduled)

2021-05-14 18:20:09,217 [ 294602]  DEBUG - l.io.storage.HeavyProcessLatch -  null Heavy process started.
2021-05-14 18:20:09,217 [ 294602]  DEBUG - l.io.storage.HeavyProcessLatch -  null Heavy process finished. 
2021-05-14 18:20:09,217 [ 294602]  DEBUG - aemon.impl.PassExecutorService -          null Cancel re-scheduled to execute after heavy processing finished true; progress=797829327 V 
2021-05-14 18:20:09,218 [ 294603]  DEBUG - aemon.impl.PassExecutorService -          null Update Runnable scheduled. reason: re-scheduled to execute after heavy processing finished; progress=797829327 X 

For fix, i figured we shouldn't listen to every single stopProcess(), but should only restart daemon ONCE upon all heavy process beside vfs finished. There comes this fix

You may find it very similar to before https://github.com/JetBrains/intellij-community/commit/01e0d412641e52bb4185517928bbbd9e7a21c13f#diff-4497b4c4afdd25574053db8b6de01a43669c1b3200a5d4d31d14da002614e40, where we queue a one time runnable to restart daemon after heavy process, but it's different in terms of I (1) queue one-time runnable to happen after heavy process EXCEPT VFS (2) does NOT require if (!hasPass) to queue this runnable. This is important, as sometimes MOST pass is filtered due to dumbaware, but some is left, in that case we still need to queue this runnable.

acejingbo avatar Jun 22 '21 19:06 acejingbo

I tested and confirmed fix by patching this and prerequiresite commits (and adjust a few conflict) to IJ202 and 211, but not 212. Because when i build on master or any 212 branch/tag, the result sandbox IDE will hit this error https://youtrack.jetbrains.com/issue/IDEA-270409, so editor will be blank, and most button and UI (“New Project” “Go to file” “Open project panel”) will be unresponsive.

i tried (1) reclone to clean master (2) invalidate cache and restart my dev-use IDE (3) Download newest IJ211 for dev-use (4) remove cache by removing /Library/Cache/Jetbrains, /Library/Application Support/Jetbrains, intellij-community/system, intellij-community/config, but none of it works. But once i rebase to 211 it immediately works. It feels like this error just happen to my 212 sandbox consistently

If we have to test in 212 to get accepted, any guidance on how to get around this error? Or if you cannot reproduce this error in 212, would it to too much to ask to help patch and test this commit? Thank a lot!

acejingbo avatar Jun 22 '21 19:06 acejingbo

Not sure if it make sense? Hope to get some review and feedback. If there's any question about the logic i am happy to explain.

acejingbo avatar Jul 19 '21 18:07 acejingbo