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.
Download the following file and copy it into an empty text file in NetBeans http://www.census.gov/tiger/tms/gazetteer/zips.txt Run the following regexp replacement on it: "\w\w","(\w\w\w\w\w)","(\w\w)","(.*)".*(\n) Z$1 ("$1", State.$2, "$3"),$4 You will encounter an out of memory error w/ message "Java heap size", but the heap has not grown. Setting PermSize to 384M before startup allows the replacement to complete (takes about 15 minutes!). I can only conclude that some or all of the file is being interned in the process of replacement and runs out of perm gen space for the interned strings.
That's rather large file. We will need to run profiler to figure out where the possible performance/memory improvements could be done. I remember that there used to be an ineficiency in searching where we have used doc.getText() as a CharSequence which grabbed the whole text from the document into a String. I have double-checked that it's no longer true - the find now uses DocumentUtilities.getText() at DocumentFinder:210 which is a "view" over the document's text. Setting TM to future preliminarily.
Might be interesting to just instrument String.intern() and dump stack traces to the console. I don't know any other way you can run out of perm gen doing something that isn't loading classes. The culprit is probably one easily found line of code.
I've also verified that both in FindSupport and DocumentFinder there are no String.intern() calls. Actually in j.u.regex.Pattern there are some intern() calls in private Node family(boolean not, boolean singleLetter) Not sure whether the code will reach that point but it may be checked by debugging.
It would be nice to have this functional efficiently. Lets focus next release.
NetBeans.org Migration: changing resolution from LATER to WONTFIX