Uploaded image for project: 'Spring Tool Suite'
  1. Spring Tool Suite
  2. STS-1954

Spring Tool Suite 100% CPU Usage / Perminately Frozen

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: 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-threaddump-STS-1954.txt
        52 kB
        Rob Winch
      1. STS-1954-autocomplete.png
        14 kB

        Activity

        Hide
        aclement Andy Clement 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
        aclement Andy Clement 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
        virtualeyes 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
        virtualeyes 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
        aclement Andy Clement 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
        aclement Andy Clement 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
        aeisenberg Andrew Eisenberg added a comment -

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

        Show
        aeisenberg Andrew Eisenberg added a comment - Bug 345093 is fixed at eclipse.org, which is the root cause of this bug. Resolving this issue as fixed.
        Hide
        mlippert Martin Lippert added a comment -

        We moved issue tracking for this project to https://github.com/spring-projects/spring-ide.
        If you would like to comment on or re-open this issue, please file a new issue at GitHub and refer to this one.

        Show
        mlippert Martin Lippert added a comment - We moved issue tracking for this project to https://github.com/spring-projects/spring-ide . If you would like to comment on or re-open this issue, please file a new issue at GitHub and refer to this one.

          People

          • Assignee:
            aeisenberg Andrew Eisenberg
            Reporter:
            rwinch Rob Winch
          • Votes:
            4 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: