Spring Tool Suite
  1. Spring Tool Suite
  2. STS-1954

Spring Tool Suite 100% CPU Usage / Perminately Frozen

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.7.1.RELEASE
    • Fix Version/s: 3.3.0.RELEASE
    • Component/s: None
    • Labels:
      None
    • Environment:

      Description

      Sometimes when using content assist STS freezes and must be killed. When looking in top STS is near or at 100% CPU usage. When I profile STS with YourKit it states that org.eclipse.equinox.launcher.Main.run(String[]) is the problem thread using nearly all the CPU.

      1. STS-2011-07-20.snapshot.zip
        2.01 MB
        Rob Winch (c)
      2. sts-threaddump-STS-1954.txt
        52 kB
        Rob Winch (c)
      1. STS-1954-autocomplete.png
        14 kB

        Activity

        Hide
        James Lang added a comment -

        Great on both fronts, particularly server startup.

        Just to put in context, a straight groovlet app on tomcat restarts in 2-3 seconds vs 20-40 seconds (unclean/clean) for grails on quad core laptop + 8gb ram + SSD.

        Obviously spring MVC is the foundation of grails and therefore, not at all 100% groovy app, nor lightweight. With great power comes long startup times it seems. Strange though that say, Mono on Linux restarts surprisingly quickly, maybe 4 seconds max, and although I have not tried in awhile, on Windows C#/.NET starts up quite quickly as a I recall.

        JVM must not be taking full advantage of multi-core cpus during compilation. I believe Scala as well does not yet compile as quickly as one would hope. Context switching is a productivity killer and sometimes in Grails you have to restart to view changes (e.g. to a domain class)

        Anyway, any improvement will be much appreciated

        Show
        James Lang added a comment - Great on both fronts, particularly server startup. Just to put in context, a straight groovlet app on tomcat restarts in 2-3 seconds vs 20-40 seconds (unclean/clean) for grails on quad core laptop + 8gb ram + SSD. Obviously spring MVC is the foundation of grails and therefore, not at all 100% groovy app, nor lightweight. With great power comes long startup times it seems. Strange though that say, Mono on Linux restarts surprisingly quickly, maybe 4 seconds max, and although I have not tried in awhile, on Windows C#/.NET starts up quite quickly as a I recall. JVM must not be taking full advantage of multi-core cpus during compilation. I believe Scala as well does not yet compile as quickly as one would hope. Context switching is a productivity killer and sometimes in Grails you have to restart to view changes (e.g. to a domain class) Anyway, any improvement will be much appreciated
        Hide
        Andy Clement (c) added a comment -

        I just tried recreating the inconsistent class file with the code as you had it (abstract Controller and concrete FooController) but it doesn't happen for me - I tried with Grails 2.0.0.M2 and Grails 2.0.0.BUILD-SNAPSHOT (that I built today). But I recognize that you say it is intermittent. Do I presume the full message is as per the post you referenced:
        Inconsistent classfile encountered: The undefined type parameter V is referenced from within Controller._closure1
        indicating it is the closure class that contains broken contents. I've been through the one I'm creating with javap and can't see any issues in it. I wasn't able to test with an old version of Groovy-Eclipse though, I am using the recent 2.5.2.RELEASE. Perhaps you should update to that (if you haven't already), update site: http://dist.springsource.org/release/GRECLIPSE/e3.7/

        On the other issue:
        With the change for grails to use an agent to help with reloading, the intention is that even if startup time takes a hit due to the agent, you have to restart far less frequently, eventually saving more time than you lost due to the increased startup time. (I'm not saying the time will be as you see it now as we are improving it all the time, I'm just saying the intention is to reduce the number of times you need to restart).

        Show
        Andy Clement (c) added a comment - I just tried recreating the inconsistent class file with the code as you had it (abstract Controller and concrete FooController) but it doesn't happen for me - I tried with Grails 2.0.0.M2 and Grails 2.0.0.BUILD-SNAPSHOT (that I built today). But I recognize that you say it is intermittent. Do I presume the full message is as per the post you referenced: Inconsistent classfile encountered: The undefined type parameter V is referenced from within Controller._closure1 indicating it is the closure class that contains broken contents. I've been through the one I'm creating with javap and can't see any issues in it. I wasn't able to test with an old version of Groovy-Eclipse though, I am using the recent 2.5.2.RELEASE. Perhaps you should update to that (if you haven't already), update site: http://dist.springsource.org/release/GRECLIPSE/e3.7/ On the other issue: With the change for grails to use an agent to help with reloading, the intention is that even if startup time takes a hit due to the agent, you have to restart far less frequently, eventually saving more time than you lost due to the increased startup time. (I'm not saying the time will be as you see it now as we are improving it all the time, I'm just saying the intention is to reduce the number of times you need to restart).
        Hide
        James Lang added a comment -

        Problem is intermittent, thankfully spared at the moment I'll try 2.5.2 Groovy-Eclipse...

        Yes, the 2.0 reloading agent is very good; in fact, it is the only reason I am actively developing in Grails now (with my LAMP stack background I could not tolerate the number of devel restarts needed in Grails 1.2/1.3).

        Anyway, there are still a number of cases where one has to restart (domain class changes, missing GORM implementation error, and some edge cases where you know the code is correct, but only a restart gets a change picked up), and that can be tough, particularly when troubleshooting an error, which may take several restarts to sort out.

        I wonder how it is that .NET on Windows and Mono on Linux are able to compile so quickly? Does the JVM not utilize multiple cores during compilation? Maybe there are some JAVA opts I can set, I'm getting 20 second startups on non-clean project, which seem slow for a quad core machine with 8gb ram and fast SSD...

        Show
        James Lang added a comment - Problem is intermittent, thankfully spared at the moment I'll try 2.5.2 Groovy-Eclipse... Yes, the 2.0 reloading agent is very good; in fact, it is the only reason I am actively developing in Grails now (with my LAMP stack background I could not tolerate the number of devel restarts needed in Grails 1.2/1.3). Anyway, there are still a number of cases where one has to restart (domain class changes, missing GORM implementation error, and some edge cases where you know the code is correct, but only a restart gets a change picked up), and that can be tough, particularly when troubleshooting an error, which may take several restarts to sort out. I wonder how it is that .NET on Windows and Mono on Linux are able to compile so quickly? Does the JVM not utilize multiple cores during compilation? Maybe there are some JAVA opts I can set, I'm getting 20 second startups on non-clean project, which seem slow for a quad core machine with 8gb ram and fast SSD...
        Hide
        Andy Clement (c) added a comment -

        > Anyway, there are still a number of cases where one has to restart (domain class changes,
        > missing GORM implementation error, and some edge cases where you know the code is correct,
        > but only a restart gets a change picked up), and that can be tough, particularly when
        > troubleshooting an error, which may take several restarts to sort out.

        Just a quick note: if you can raise those as grails jiras, I'll look into them. I currently only have one grails issue against the reloading agent.

        > I wonder how it is that .NET on Windows and Mono on Linux are able to compile so quickly? Does the JVM
        > not utilize multiple cores during compilation? Maybe there are some JAVA opts I can set, I'm
        > getting 20 second startups on non-clean project, which seem slow for a quad core machine with
        > 8gb ram and fast SSD...

        As far as I am aware, javac is not multi threaded. The eclipse compiler for java does some parts of compilation multi-threaded (parsing) but then everything blocks so that resolution can proceed in one thread. I don't believe any of groovyc is multi threaded. Given the high cost of parsing for groovy, if groovyc went multi threaded in that area, it might speed things up quite a bit.

        Show
        Andy Clement (c) added a comment - > Anyway, there are still a number of cases where one has to restart (domain class changes, > missing GORM implementation error, and some edge cases where you know the code is correct, > but only a restart gets a change picked up), and that can be tough, particularly when > troubleshooting an error, which may take several restarts to sort out. Just a quick note: if you can raise those as grails jiras, I'll look into them. I currently only have one grails issue against the reloading agent. > I wonder how it is that .NET on Windows and Mono on Linux are able to compile so quickly? Does the JVM > not utilize multiple cores during compilation? Maybe there are some JAVA opts I can set, I'm > getting 20 second startups on non-clean project, which seem slow for a quad core machine with > 8gb ram and fast SSD... As far as I am aware, javac is not multi threaded. The eclipse compiler for java does some parts of compilation multi-threaded (parsing) but then everything blocks so that resolution can proceed in one thread. I don't believe any of groovyc is multi threaded. Given the high cost of parsing for groovy, if groovyc went multi threaded in that area, it might speed things up quite a bit.
        Hide
        Andrew Eisenberg (c) added a comment -

        Bug 345093 is fixed at eclipse.org, which is the root cause of this bug. Resolving this issue as fixed.

        Show
        Andrew Eisenberg (c) added a comment - Bug 345093 is fixed at eclipse.org, which is the root cause of this bug. Resolving this issue as fixed.

          People

          • Assignee:
            Andrew Eisenberg (c)
            Reporter:
            Rob Winch (c)
          • Votes:
            4 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: