Eclipse v3.3.x PermGen Memory Errors

Out-of-the-box Eclipse v3.3.x was giving me on average 12 to 16 crashes per day! I was even seriously considering dropping Eclipse altogether and finding something more stable.

I was using Eclipse v3.3.1 with the WST extension and tigris.org's subclipse v1.2.0 (since the v2.x has serious bugs that prevents it from installing) on a Windows XP Pro platform.

The short of the problems came down to a mistake in the eclipse.ini file that had the

--launcher.XXMaxPermSize

statement come before the

-vmargs

statement. It is a little more involved that that, one issue was that the duel-level launch configuration that Eclipse uses does not always do a great job of detecting Sun VMs, of which the

--launcher.XXMaxPermSize

only works with a Sun VM, which defaults the PermGen space to a size of 64MB.

The suggested fix is to remove

--launcher.XXMaxPermSize

and replace it with

-XX:MaxPermSize=256m

after

-vmargs

it should now pickup the change.

This change and usage of

-XX:MaxPermSize

is said to be universal (to some degree) to other VM's such as the mac.

An example of my config which works, which is "fairly" close to the original eclipse.ini:

-showsplash org.eclipse.platform
-vmargs
-Xms512M
-Xmx1028M
-XX:MaxPermSize=256M

One area of great disappointment with all of this, is that it appears like they were spending a fair amount of time arguing how and when to apply this fix or even announce this potential problem instead of just getting it done. I really do enjoy the Eclipse experience, but because of this problem, I was about to drop it and probably never give it another chance. Good thing I went snooping through their Bugzilla!

References
Eclipse's Bugzilla Entry on this bug

FireFox Add-On worth trying - FireBug

For the last few months I have been wishing that the PC version of Safari had the same full robust HTML and CSS debugging tools as the mac counterpart. Well, I have just found in the last week a tool that should make any Mac Safari user quite envious.

The tool's name is FireBug.

What is great about it? Here is a very short list:

• JavaScript Error Console


• JavaScript profiler


• View source code for HTML, CSS, JavaScript, Images, etc...


• HTML Source hover-highlighting


• Select an DOM element, and it can show the CSS styles that contribute to it, the Box model layout, and DOM hooks


• Dynamically modify CSS elements without modifying any source code or reloading the page to see the results


• Set JavaScript breakpoints for debugging


• See Network performance stats on object/page loads


• Review dynamic AJax calls: parms, headers, and response

This is a really useful tool. If you spend any time in HTML, JavaScript, CSS, this tool is well worth looking in to. I don't think many would be disappointed.

References
FireBug's Website

Prototype v1.6 Ajax.Updater and textarea in FireFox v2.x

There is a slight issue with how Prototype v1.6 (and prior) deals with textarea form elements when used in combination with Ajax.Updater. This appears to only be an issue with FireFox v2.0.0.x and not IE7 or Safari v3 for Windows. I have not tested to confirm if this is an issue on non-windows versions of FireFox or other browsers or platforms.

The problem enters when Updater is successful in putting the results content in to the textarea innerHTML, but the contents are not displayed. Most of the solutions that I have been able to find on the web suggests to use a onSuccess: callback then within there, pull the responseText from the response object and shove it in to the value of the textarea.

Example of a BAD use of Ajax.Updater with the textarea:

  <form id="formid">
    <textarea id="textareaid" />
  </form>
  Ajax Status: <div id="ajaxStatus"></div>
...
  new Ajax.Updater( 'textareaid', 'anSOAapp.jsp', {
      parameters: { id: anId, afield : avar },
      onFailure: function(){
          $('ajaxStatus').update('An error occurred.'); 
      }, 
      onSuccess: function(response) {
           $('textareaid').value = response.responseText;
           $('ajaxStatus').update( response.status ); 
   }});

How wasteful! Not only in redundant processing (the contents of the textarea is being updated twice!), but also in memory that JavaScript is now having to allocate and use. What is the point of using the Ajax.Updater function if you are just going to overwrite its output?! For small tidbits of data, it may not be noticeable, but for larger data sets, then you can not only risk the out of memory exceptions, but also a non-functional page.

The whole point of utilizing the Ajax.Updater function is to help streamline the whole data flow and to offset the needs to keeping the data in a variable or as a String in JavaScript, which is what occurs when using the responseText field.

There is an easy solution that helps to avoid these problems of redundancy and excessive memory utilization. It is actually quite simple.

Example of the correct use of Ajax.Updater with the textarea:

  <form id="formid">
    <textarea id="textareaid" />
  </form>
  Ajax Status: <div id="ajaxStatus"></div>
...
  new Ajax.Updater( 'textareaid', 'anSOAapp.jsp', {
      parameters: { id: anId, afield : avar },
      onFailure: function(){
          $('ajaxStatus').update('An error occurred.'); 
      }, 
      onSuccess: function(response) {
           if ( Prototype.Browser.Gecko ) {
              $('formid').reset();
           }
           $('ajaxStatus').update( response.status ); 
   }});

Notice that the key element was

$('formid').reset();

inside a conditional to ensure it only is performed for FireFox browsers.

Give it a try.

Resources
Prototype API Docs
Prototype's Form.reset() function API Docs