• Subject: Re: How can Java eat up 160meg of memory?
  • From: Blair Wyman <wyman@xxxxxxxxxxxx>
  • Date: Tue, 29 Feb 2000 14:02:25 -0600 (CST)

Excerpts from midrange-l: 28-Feb'00 How can Java eat up 160meg ..
"Stone, Brad V @taylorco (1473*) 

> We have an application running on an NT server.  It's a pentium pro 200 with 
> 160meg of memory and 2 2gig scsi hard drives. 

> Now, this application is "written in Java!!!".  First of all, as expected, 
> it's a slow running app.  but I can deal with that.   

Why not try it on your AS/400?  Seriously!  If it is 100% Java, and
doesn't do a lot of graphics, there's no reason you shouldn't at least
try it there.  If it leaks memory on our JVM, too, it's a good sign the
software vendor is at fault. 

> The real problem is after only 5 days of running, we have to reboot because 
> we get so many "out of memory" errors.  this is a machine that needs to be 
> 24/7. 

Unfortunately, the question probably comes down to "Whose JVM are you
running?" 

In an ideal world, all JVMs would work exactly the same.  Unfortunately
(or fortunately, depending on your perspective) they do not. 

If you are running the M$ JVM, consider the conflict: if Java works
right, it undermines the desktop OS-monopoly they enjoy.  If you are
running a Microsoft JVM on your PPro, this is certainly one good reason
for trying a different JVM before making a final judgement. 

If you aren't running the Sun or IBM JVM, you should consider trying one
of them with your application.  If the application still exhibits this
*classic* memory leak, call the software vendor and tell them about it
-- again, odds are it's their fault. 

> I can only assume it's the "awesome" builtin cleanup with Java that is 
> eating resources like candy.  I run my pentium 200mhz PC with 48meg of 
> memory for up to 3 weeks at a time and never get memory errors (it just 
> reboots itself..haha..). 

Well, from a Java vs. C/C++ software development standpoint, the
alternative to using garbage collection (as in Java) is managing your
own memory (with malloc/free or new/delete).  Pointer programming leads
to pointer errors, and debugging pointer errors is the blackest legal
art, IMHO.  I've used both environments quite heavily, and can tell you
garbage collection *is* "awesome." 

> So, maybe Java cleanup isnt so good?  Maybe there is some knowledge of 
> memory management needed that this application doesn't use?  

The Java garbage collector can be fooled into thinking some objects are
still reachable, even when they are not.  Typically, this has to be done
in native methods obtaining what are known as "global references," but
I'm sure there have been scenarios where references to objects "escape"
and render the object uncollectable. 

> I'd be interested in hearing what folks have to say.  I'm not saying what 
> the software is, though.  Maybe if you ask privately I'll tell.  ;)  This is 
> more of a Java gripe than a software gripe, but they do go hand in hand. 
> Maybe "written in Java" means to steer clear?  160meg of memory is a LOT of 
> memory to eat up in a few days. 

Well, this situation is simply a memory leak, and could happen in any
language.  The fact that it might be the JVM instead of the application
is the key difference. 

Just my 2 cents worth. 

-blair 

  ___   _           Blair Wyman                  IBM Rochester 
 ( /_)  /  _  ' _   (507)253-2891            blairw@us.ibm.com 
__/__)_/_<_/_/_/_'  Opinions expressed may not be those of IBM 

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.