#3723 Same SQL file requires 400MB heap on Mac and 60MB on Linux

normal bug
open
nobody
5
2012-07-21
2012-07-21
müzso
No

In two quite different environments the very same jEdit version (4.5.2 and using the same jedit4.5.2install.jar in both cases and not using the Mac integration plugin on the Mac) behaves very differently, when opening the same large SQL file.

On Mac OS X (10.6.8) jEdit used approx. 400 MB of heap memory for opening the SQL file, on Ubuntu (10.10) jEdit took 60 MB of heap memory for the same task. I\'ve attached the SQL file (zipped). The problem is not simply with large files or with files that have huge lines (eg. over 200000 character lines). I\'ve created such test files and on both platforms jEdit consumed approx. the same amount of heap space.

Btw. I\'ve used jConsole to monitor heap usage in both cases.
I should also note that on Mac OS X jEdit was executed in a 64 bit Oracle JVM, and on Ubuntu it was a 32 bit Oracle JVM. In both cases I used Oracle JRE 1.6.0.*.
Of course in a 64 bit JRE the same app would eat more memory, but afaik it should not be more than twice the memory used by the app on a 32 bit platform. So the huge difference (6-7 times) in heap memory requirement to open the given SQL file should not be explainable merely by the platform differences.

Any idea what might cause this?

Btw. when opening the SQL file, jEdit asked me whether I wanted to open it without syntax highlighting, or with a simplified syntax highlight or with fulll syntax highlight. I\'ve found that this choice does not affect required heap memory significantly in either case.

If more info is needed (any debug logs, etc.), I\'d happy to provide them.

P.S.: Sourceforge does not allow attachments larger than 256K at the moment. And since the problem occurs only with large files, I uploaded my test SQL file to somethere else: http://dropcanvas.com/h7nbd
This will be only temporary (I guess dropcanvas won't keep my upload "forever"), but if you suggest another method for sharing my test SQL file, I'll gladly upload it again.

Discussion

  • müzso
    müzso
    2012-07-21

    I've tried this SQL file with the official jedit4.5.2install.dmg installer too (the one meant for Mac OS X), but got the same result.

     
  • Please repeat the test on both machines with -noplugins -nosettings

    I made a few tests on Debian and I had memory usage from 50MB to 250MB and OOM. Jedit became non-responsive. It's impossible to navigate this 18MB file.

    In case the file is really unique I uploaded it as:
    http://jedit.org/files/tracker/3546827_drupal6_database_partial_dump_20120721.sql.zip

     
  • müzso
    müzso
    2012-07-23

    I've repeated the test in both environments (+ I added a Windows test too) with the "-noplugins -nosettings" switches came up with quite the same results.

    My steps were the following in all three environments:
    1. Start up jEdit with "jedit -noplugins -nosettings".
    2. In Global Options set the default encoding to UTF8 (since this one differs based on the platform and I did want to provide the same test parameters as much as possible).
    3. Start jconsole, connect to the jEdit JVM and switch to the Memory tab.
    4. Open the SQL file in jEdit, wait for the file contents to appear.
    5. Press PageDown once.

    And the results are ...

    1.) Windows XP SP3
    Finished opening the file in 2s and used 51 MB heap memory.
    The press of PageDown resulted in heap memory usage to be increased to 434 MB and the paging took 1 minute or so.

    2.) Mac OS X 10.6.8
    Opening of the file took 1 minute and heap memory usage grew to 370 MB.
    First few PageDowns were instant, without any delay.

    3.) Ubuntu 10.10
    Like on Windows:
    Finished opening the file in 1s and used ~50 MB heap memory.
    First PageDown resulted in heap memory usage to go up to 428 MB and took 1 minute or so.

     
  • Thomas Meyer
    Thomas Meyer
    2012-09-05

    Method Chunk.layoutGlyphVector(Font, FontRenderContext, char[], int, int) eats up all CPU and makes jEdit unusable for the file in above link in 5.1pre1, Fedora 17, java 7.

    Stack trace is:
    Thread [AWT-EventQueue-0] (Ausgesetzt (Unterbrechungspunkt bei Zeile 597 in Chunk))
    Eigner von: TokenMarker ID
    Chunk.layoutGlyphVector(Font, FontRenderContext, char[], int, int) Zeile: 597
    Chunk.layoutGlyphs(Font, FontRenderContext, char[], int, int) Zeile: 635
    Chunk.init(Segment, TabExpander, float, FontRenderContext, int) Zeile: 457
    DisplayTokenHandler.initChunk(Chunk, float, Segment) Zeile: 181
    DisplayTokenHandler.initChunks(Chunk, Segment) Zeile: 190
    DisplayTokenHandler.makeScreenLine(Segment) Zeile: 398
    DisplayTokenHandler.handleToken(Segment, byte, int, int, TokenMarker$LineContext) Zeile: 102
    TokenMarker.markTokens(TokenMarker$LineContext, TokenHandler, Segment) Zeile: 252
    Buffer.markTokens(Segment, TokenMarker$LineContext, TokenHandler) Zeile: 1705
    Buffer(JEditBuffer).markTokens(int, TokenHandler) Zeile: 1377
    ChunkCache.lineToChunkList(int, List<Chunk>) Zeile: 789
    ChunkCache.updateChunksUpTo(int) Zeile: 671
    ChunkCache.scrollUp(int) Zeile: 211
    DisplayManager.setFirstLine(int, int) Zeile: 564
    JEditTextArea(TextArea).setFirstLine(int) Zeile: 545
    JEditTextArea(TextArea).scrollUpPage() Zeile: 675
    JEditTextArea(TextArea).goToPrevPage(boolean) Zeile: 2833