Community
Participate
Working Groups
When the error log i relatively large the Help->About Eclipse Platform->Configuration Details eats up a lot of memory. I had to increase the max heap size to around 512M in order to open it without an out of memory error. In that case the error-log was 12M. Maybe the display of the error log should be truncated when above a specific size, or it should not be shown at all. BTW: this is on Eclipse M9.
Should investigate for RC3, and consider using Browser widget instead.
you mean RC2 nick?
Yeah, sure <g>.
Andrew, please investigate whether this is a simple reason why it takes so long to read the log and dump it to a text widget. If we can just speed this up for R3.0 that would be nice. Otherwise we defer
*** Bug 65671 has been marked as a duplicate of this bug. ***
Bug 65671 has more details. The problem is more serious than first thought. I'm flagging this as a stop-ship for 3.0.
Andrew: do you still want help with this bug? From the log on Bug 65671, I'm assuming this is specific to GTK+. Which version of GTK+ is being used? What window manager (and version)?
$ rpm -q gtk+ gtk+-1.2.10-25 Window Manager is KDE: $ rpm -q kdebase kdebase-3.1-15 The log file has a size of 8.2 MBytes.
rpm -q gtk2?
gtk2-2.2.1-4
$ rpm -q pango pango-1.2.1-3
I have tried to reproduce this problem on my machine. This is what I observed: + There is no feedback to the user that a long running task is taking place. + The opening of the file happens on the UI thread, which blocks paints from occurring + The memory consumption for a 13MB log file is about 70MB of uncompacted heap (I'm not sure how much it would be after garbage collection). This could easily be done if the file we read in (8bit->16bit character conversion) and then duplicated. This would lead to over 52MB in memory (not counting any extra space for styled text glyph caching, etc.). Looking for where the string is copied might be an interesting place to start.
I've been able to reproduce these problems on windows as well. The current code reads the entire file into a String and then does a Text. setText to populate the config dialog. I noticed that Text also supports #append, but my experiments suggest its much too slow. I found that on my machine (winxp) #setText (for 32Kb blocks) can be done in under 1 ms, but the time for append (for 32Kb each time) ranges from 16 ms initially to over 100 ms by the end of a 12Mb file (5032ms overall for #setText vs. 67141ms overall for #append). - I'll use the progress monitor for this operation to give some user feedback. - We should also cap memory used in this type of extreme situation. I'll change the implementation so that the first 4Mb of text will use #setText (same as the current code) and after that the file will be read and appended in 4Mb chunks. I've chosen a threshold large enough so that the normal case should not be affected. This 4Mb is 4Mb of memory, not log file size.
You can probably decide on a cap by querying the java.lang.Runtime.*memory() methods.
I have some hacked up code that I've used to test some parameters. I've tried two sizes of large log file (~5.5 Mb and ~11.5 Mb) and a variety of block sizes (the amount that is stored in memory before being pushing to the widget). The total memory used for each size of log file is the same, but the read times vary. For all tests, System.totalMemory was reporting 5Mb in use initially, which I have removed from the values in the table below. 11.5 Mb 5.5 Mb blockSize totalMemory time time 12 Mb 39 Mb 5.1 s 3.6 s 8 Mb 38 Mb 2.3 s 3.6 s 4 Mb 21 Mb 5.8 s 3.9 s 2 Mb 11 Mb 7.5 s 4.6 s 1 Mb 8 Mb 9.2 s 5.3 s 512 Kb 5 Mb 11.4 s 6.1 s Which seems to suggest that a 1Mb buffer allows reads at a bit faster than 1 Mb/s and memory use is kept below 10 Mb. The problems with this type of solution are: - It doesn't address the memory used by the widget. - It still needs to run in the ui thread since the string is being appended into the swt text widget. I've put the operation into the progress monitor so that there is some feedback that stuff is happening, but repaints don't work correctly if the window is hidden and then made active again. - If the file size is known ahead of time then its possible to use a smoothly updating progress bar. However, the error log is contributed by an extension, which means the file size is not directly known. It would be possible to use down casting in the extension that provides the log file contents...but that's clearly a hack. I'm starting to think that a better solution is recognize that the log file is very big and stop trying to write the entire file to the window. It should be sufficient to write just the first and last bits (256Kb?) as well as the path to the full file. This would reduce the memory used by the widget, cap total memory use, reduce time required to display the dialog, and most importantly, restrict the solution to the extension that contributes the log file to the system summary dialog. This late in the release I think that lower risk is a good idea. The only negative I see is that people with large log files where the middle portion is significant have an extra step. What do people think?
Since we already have support for opening a web browser on the "More Info" for features and plugins, I'm inclined to: - remove the log from the configuration details, but keep the rest (the log isn't really configuration info anyway) - add an Open Log File button, which opens the log in an external web browser This will also address the issues of people being unable to easily copy or save the content to a different file, and is low risk.
I've made the change described in comment 16. Reviewed by tod and submitted to HEAD.
