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 216210 - org.netbeans.api.lexer.TokenSequence.checkModCount took 10375 ms.
Summary: org.netbeans.api.lexer.TokenSequence.checkModCount took 10375 ms.
Status: RESOLVED WONTFIX
Alias: None
Product: editor
Classification: Unclassified
Component: Lexer (show other bugs)
Version: 7.3
Hardware: All All
: P3 normal (vote)
Assignee: Miloslav Metelka
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2012-07-31 15:04 UTC by Alexander Simon
Modified: 2013-09-01 12:04 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter: 191179

Attachments
nps snapshot (123.84 KB, application/nps)
2012-07-31 15:04 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 Alexander Simon 2012-07-31 15:04:17 UTC 
This bug was originally marked as duplicate of bug 149538, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related.

Build: NetBeans IDE Dev (Build 20120730-12c10df24f47)
VM: Java HotSpot(TM) Client VM, 23.1-b03, Java(TM) SE Runtime Environment, 1.7.0_05-b05
OS: SunOS
Maximum slowness yet reported was 10375 ms, average is 10375
Comment 1 Alexander Simon 2012-07-31 15:04:22 UTC 
Created attachment 122593 [details]
nps snapshot
Comment 2 David Strupl 2012-11-23 09:11:32 UTC 
There is (so far) only one snapshot with similar suspected method. Is there any more information as to what was happening when this happened?

There are 3 threads trying to repeatedly lock IncTokenList - Spellchecker, Cnd Braces Matching thread and AWT EDT. 

I suspect that the slowdown was caused by repeatedly calling IncTokenList.tokenOrEmbeddingImpl(x) but I am not sure. As this method is called under the synchronized all the other threads had to be waiting for it. Just a theory though ...

I am not sure whether this report is actionable, what do you think? Both Alexander and Milo ...
Thanks. David.
Comment 3 Miloslav Metelka 2013-09-01 12:04:37 UTC 
The report 678882 is strange imho the machine is either heavy loaded or jvm is struggling with GC which would correspond to an xml file being large.
The report 603399 as David mentioned there are three threads competing all three scanning lexer's token hierarchy so they possibly compete for the lexer's lock at certain times.