PreviousNextTracker indexSee it online !

(161/231) 3546827 - Same SQL file requires 400MB heap on Mac and 60MB on Linux

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:
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.

Submitted muzso - 2012-07-21 - 20:36:47z Assigned nobody
Priority 5 Category editor core
Status Open Group normal bug
Resolution None Visibility No


2012-07-21 - 20:41:05z
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.
2012-07-22 - 06:58:50z
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:
2012-07-23 - 21:15:46z
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.
2012-09-05 - 18:41:34z
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