We have preview projects that we test and have seen no issues. Can you attach a clean .zip of the project so we can
reproduce the issue?

Created attachment 73322 [details]
my test nbproject

I am sorry, I cannot reproduce it.
Please attach a thread dump from NetBeans when this happends.

It would also be helpful if you would attached your messages.log file from your userdir.  Windows (help > about will 
show you where your userdir is located), Mac (Netbeans > About Netbeans will show you where your userdir is located)

Created attachment 73487 [details]
stack dumps from nb.

I switched nb to use jdk 1.6 so I could use jstack and then hit the condition pretty fast.

I am no longer sure that it is related to opening the project. Yesterday I worked (using jdk 1.5) for most of the day
without the cpu pegging to max (85% of my cpu right now according to top), and then, without a restart it pegged. I am
working on a FX project, so I am mostly working on a mix of .java and .fx files, with a small about of building.

Something is wacky for sure, hopefully you can get what is happening from the traces. Let me know if there is more that
I can do to help diagnose this.

Note: there is no indication in the gui that scanning is taking place. I expect the cpu to warm up when that is
happening :-)

adding David and Rasta to cc since I see the parser in the stack trace.
I suggest to download and use VisualVM (already included in 1.6u10 - bin/jvisualvm.exe ) from https://visualvm.dev.java.net/
As soon as you hit the problem, run Visual VM, it will detect your running VMs automatically and you can profile them.
You can easily see the methods that consume most time and take a screenshot as a png.
I've tried to reproduce the problem on my machine as well but it works correctly.

I have already tried to reproduce this one yesterday but all what happened was approx. 10 seconds CPU spike (after
opening the project) which later on died. I assume it is scanning the project since the project contains a lot of
sources but I did not get the behavior to repeat to be able to profile.

If the stack trace ends somewhere in javafx.source or editor please re-assign to me or to Petr Nejedly. But I was not
able to reproduce it with the attached project so I am not sure I am able to do something with it ...

If there are stack traces attached we might know what was happening but without being able to reproduce it will be close
to impossible to fix this before the 1.0 release.

visualvm sounds like a great idea - but.... I am on a mac and 6u10 is not available.

I downloaded the package, and when I try to start it, I get:

Exception in thread "main" java.lang.NoClassDefFoundError: org/netbeans/Main

which at first blush is due to errors in the classpath creation of platform7/lib/nbexec

If you are able to reproduce the problem you can diagnose even without the visual VM by generating a thread dump
http://wiki.netbeans.org/GenerateThreadDump

If you follow the steps you will get the thread dump either on the console or in the file
.netbeans/<version>/var/log/messages.log. Please generate several thread dumps in a row when the processor is on 100%
and attach the file to this bug report. Thanks a lot for your help with resolving this.

Ok - got visualvm to run but....
(it had a problem with a relative path, when I changed the launch to `pwd`/bin/visualvm it did much better. Certainly a
bug....)

from https://visualvm.dev.java.net/troubleshooting.html:
   Profiling Does Not Work on Mac OS X
   Description: Profiling doesn't work for applications running on Developer preview of JDK 6 on Mac OS X.
   Resolution:  Unfortunately profiling does not work with Developer preview of JDK 6, due to bug in the JDK. However
you can still take thread and heap dumps of applications running on JDK 6 on Mac OS X.

However - despite it visualvm telling me it would not work, it looks like it may have. Will upload a png and snapshot
file in a moment that seems to say JavaFXSource.movedToPhase is being called excessivly as the counter is going nuts
while I am watching it.

Created attachment 73505 [details]
screenshot of visualvm hotspot trace

Created attachment 73507 [details]
visual vm snapshot of a very warm netbeans.

Changing title - don't think this is related to "opening", I think it is more about working with an FX project.

Let me know if you want me to try something - just remember - it is mac with 1.6 u7.

Removing the incomplete keyword. Re-assigning to the appropriate person. The question is when will Andrey be able to
look at it ...

From the VM trace it looks like a problem outside the tracked classpath.
RequsetProcessor consumed almost all the CPU time, from the Thread Dump there is a huge stack trace diving somewhere
inside JavaFX compiler (classes com.sun.tools.javafx.main.JavafxCompiler and com.sun.tools.javafx.antlr.v4Parser) but
none of the com.sun.* classes is traced.

Requset Processor (132x) calls Error Annotator (47106x) calls JavaFXSource.moveToPhase (47106x, 10% selftime) but most
of the CPU must be consumed by some direct call from Request Processor to some com.sun. class. I guess some com.sun
runnable is directly enqueued into the Request Processor. 

Could you, please, profile it again without the filters (especially com.sun.*) ?

Thanks

I can reproduce this issue on OSX 10.5.5 with NB5.6 Build 20081107165852 and the latest FX plugin from
  
http://www.jeevez.russia/hudson/job/JavaFX_NB_Plugin_NB65_daily/lastSuccessfulBuild/artifact/main/nbbuild/nbms/catalog.xml.gz

It is reproducible with both 1.5 and 1.6.

It only happens if at least one FX project is opened. If it is closed and NB restarted,
it doesn't happen. I tried to clean the cache many times to no avail. 
(I can provide my fx project if needed).

The only busy thread is the ErrorAnnotator worker. Here's a couple of stack dumps of this thread:

ErrorAnnotator worker" daemon prio=1 tid=0x5e201c00 nid=0x90e400 runnable [0xb3c3f000..0xb3c3fd90]
               at org.openide.util.lookup.ProxyLookup.lookup(ProxyLookup.java:244)
               - waiting to lock <0x07d073f8> (a org.netbeans.core.startup.MainLookup)
               at org.openide.util.Lookup.lookupResult(Lookup.java:225)
               at org.openide.util.Lookup.lookupAll(Lookup.java:245)
               at org.netbeans.modules.javafx.source.tasklist.FXErrorAnnotator.getAnnotator(FXErrorAnnotator.java:225)
               at org.netbeans.api.javafx.source.JavaFXSource.moveToPhase(JavaFXSource.java:283)
               at org.netbeans.api.javafx.source.CompilationInfoImpl.toPhase(CompilationInfoImpl.java:132)
               at org.netbeans.api.javafx.source.CompilationController.toPhase(CompilationController.java:72)
               at org.netbeans.modules.javafx.source.tasklist.FXErrorAnnotator$1.run(FXErrorAnnotator.java:278)
               at org.netbeans.modules.javafx.source.tasklist.FXErrorAnnotator$1.run(FXErrorAnnotator.java:277)
               at org.netbeans.api.javafx.source.JavaFXSource.runUserActionTask(JavaFXSource.java:481)
               at org.netbeans.modules.javafx.source.tasklist.FXErrorAnnotator.haveError(FXErrorAnnotator.java:273)
               at org.netbeans.modules.javafx.source.tasklist.FXErrorAnnotator.haveError(FXErrorAnnotator.java:292)
               at org.netbeans.modules.javafx.source.tasklist.FXErrorAnnotator.haveError(FXErrorAnnotator.java:292)
               at org.netbeans.modules.javafx.source.tasklist.FXErrorAnnotator$2.run(FXErrorAnnotator.java:346)
               at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:573)
               at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1005)
"ErrorAnnotator worker" daemon prio=1 tid=0x5e201c00 nid=0x90e400 runnable [0xb3c3f000..0xb3c3fd90]
                at org.antlr.runtime.DFA.predict(DFA.java:89)
                at com.sun.tools.javafx.antlr.v4Lexer.mTokens(v4Lexer.java:5243)
                at org.antlr.runtime.Lexer.nextToken(Lexer.java:84)
                at org.antlr.runtime.CommonTokenStream.fillBuffer(CommonTokenStream.java:119)
                at org.antlr.runtime.CommonTokenStream.LT(CommonTokenStream.java:238)
                at com.sun.tools.javafx.antlr.v4Parser.script(v4Parser.java:291)
                at com.sun.tools.javafx.antlr.JavafxSyntacticAnalysis.parse(JavafxSyntacticAnalysis.java:104)
                at com.sun.tools.javafx.main.JavafxCompiler.parse(JavafxCompiler.java:477)
                at com.sun.tools.javafx.main.JavafxCompiler.parse(JavafxCompiler.java:517)
                at com.sun.tools.javafx.main.JavafxCompiler.parseFiles(JavafxCompiler.java:838)
                at com.sun.tools.javafx.api.JavafxcTaskImpl.parse(JavafxcTaskImpl.java:195)
                at org.netbeans.api.javafx.source.JavaFXSource.moveToPhase(JavaFXSource.java:249)
                at org.netbeans.api.javafx.source.CompilationInfoImpl.toPhase(CompilationInfoImpl.java:132)
                at org.netbeans.api.javafx.source.CompilationController.toPhase(CompilationController.java:72)
                at org.netbeans.modules.javafx.source.tasklist.FXErrorAnnotator$1.run(FXErrorAnnotator.java:278)
                at org.netbeans.modules.javafx.source.tasklist.FXErrorAnnotator$1.run(FXErrorAnnotator.java:277)
                at org.netbeans.api.javafx.source.JavaFXSource.runUserActionTask(JavaFXSource.java:481)
                at org.netbeans.modules.javafx.source.tasklist.FXErrorAnnotator.haveError(FXErrorAnnotator.java:273)
                at org.netbeans.modules.javafx.source.tasklist.FXErrorAnnotator.haveError(FXErrorAnnotator.java:292)
                at org.netbeans.modules.javafx.source.tasklist.FXErrorAnnotator.haveError(FXErrorAnnotator.java:292)
                at org.netbeans.modules.javafx.source.tasklist.FXErrorAnnotator$2.run(FXErrorAnnotator.java:345)
                at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:573)
                at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1005)

I can reproduce this on Vista using jdk 1.6.0_07. The project gets a red x.  The spinning does die down after a minute
but then if I open a .java file and a .fx file, it spins forever.  I can not reproduce this on vista using jdk 1.6_10.

On mac, I can not reproduce it using jdk 1.5.0_16.  I can however reproduce this if I switch to jdk 1.6_07.

Thinking that this may be caused by my old 'fx' project structure or something, I had created a new empty fx project,
copied a few FX files into src, and the problem still reproduced.

Also, looks like I can now reproduce the same problem on Windows now, with the latest auto-updated plugin (version 1.4)
on 20081031200614 NB6.5 build, running on 6u10.

using visualvm seems to a hit or miss affair with mac - mostly miss. I cant seem to connect for the last 30 minutes, 
though will keep trying. Perhaps one of the other commentators that hit the issue can comment. If jstack's are useful I
can make more of them.

I am able to fully reproduce using the attached project. The problem is in the FXErrorAnnotator class that keeps
enquueing the same folders forever. This must be fixed (or proven that the attached project is broken somehow) before
the release IMHO.

The neverending loop goes like this:

java.lang.Exception: Stack trace
        at java.lang.Thread.dumpStack(Thread.java:1158)
        at org.netbeans.modules.javafx.source.tasklist.FXErrorAnnotator.enqueue(FXErrorAnnotator.java:302)
        at org.netbeans.modules.javafx.source.tasklist.FXErrorAnnotator.updateInError(FXErrorAnnotator.java:205)
        at org.netbeans.api.javafx.source.JavaFXSource.moveToPhase(JavaFXSource.java:283)
        at org.netbeans.api.javafx.source.CompilationInfoImpl.toPhase(CompilationInfoImpl.java:132)
        at org.netbeans.api.javafx.source.CompilationController.toPhase(CompilationController.java:72)
        at org.netbeans.modules.javafx.source.tasklist.FXErrorAnnotator$1.run(FXErrorAnnotator.java:278)
        at org.netbeans.modules.javafx.source.tasklist.FXErrorAnnotator$1.run(FXErrorAnnotator.java:277)
        at org.netbeans.api.javafx.source.JavaFXSource.runUserActionTask(JavaFXSource.java:481)
        at org.netbeans.modules.javafx.source.tasklist.FXErrorAnnotator.haveError(FXErrorAnnotator.java:273)
        at org.netbeans.modules.javafx.source.tasklist.FXErrorAnnotator.haveError(FXErrorAnnotator.java:292)
        at org.netbeans.modules.javafx.source.tasklist.FXErrorAnnotator$2.run(FXErrorAnnotator.java:347)
        at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:572)
        at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:997)

FXErrorAnnotator --> moveToPhase --> enqueue the same folder --> ad infinitum (with 50 ms delay)

You rock dstrupl !

I am now working on this.

Further evaluation. The reason why the behavior is rather random is that the problem occurs when the error annotator is
trying to parse the files and meanwhile the cache in JavaFXSource "forgets" about already parsed files. Details:

The static variable file2Source in JavaFXSource is WeakHashMap<FileObject,WeakReference<JavaFXSource>>. The problem
occurs in cases when the weak references to the JavaFXSource are being cleared during the run of the error annotator and
the files are re-parsed again and again (the very same files). The error annotator assumes that once parsed file
remembers its state and its moveToPhase should do nothing (and especially should not call back to the error annotator
itself with request to re-validate the file's state). This is not true - once parsed and forgotten JavaFXSource is being
continually re-parsed.

Fixed in the trunk by changeset:   1748:b1b06c63e7d3

Transplanted into javafx65 repository for the release as changeset:   1756:9921e4c93f1d

Verified using Installer build 39 (sdk b51) on windows and mac.