| Re: [stellation-res] Latest checkin *does* run the unit tests - with one change |
On Wed, Aug 14, 2002 at 08:27:52AM +0000, Mark C. Chu-Carroll wrote: > On Wednesday 14 August 2002 09:51 am, Florin Iucha wrote: > > On Tue, Aug 13, 2002 at 01:54:40PM +0000, Mark C. Chu-Carroll wrote: > > > Unit tests pass with MAX_AGE = 12. > > > > Because you have 512 MB RAM + ??? swap. > > I run with 512MB ram + 1G swap. According to gkrellm, it never even > went into swap, but just ran in the 512M. (Besides, we're running > Java with a max heap size set to well below that... So there's something > very strange going on.) I am using Alan Cox kernels that do not allow to allocate more memory than you really have. I think you are using RedHat stock kernels which allow overcommit: the process can allocate as much memory as it wants as long as it doesn't use it ;) This can cause out-of-memory when the process really dirties too many pages. With strict overcommit control that does not happen - a request to allocate more memory than is available fails right away. > > > I have 256 MB RAM and 512 MB swap and the last test fails with 12 and > > the last two tests fail with 15. I am using Alan Cox kernels which have > > strict overcommit (you cannot allocate more memory than you have). > > > > This is with both SUN and IBM JDKs. > > > > Invoking Svn.run leaks both threads and memory. I have a > > ps x | grep java | wc -l > > in another console and I have counted 1000 java threads!!! > > Gag! I'll try to look at that. Something is *seriously* wrong there. I'm > having a hard imagining where 1000 threads could be coming from! > > Out of curiousity... Do you see the same kind of out-of-control thread > stuff running from the command line? Or is it just when run from the unittest > framework? It happens only with the unittest framework right now because it uses a single jvm process for all operations. When running from the command line, all the resources are cleaned up upon jvm's exit. [That's why I don't like garbage collection user's mindset ;)] I have added a System.gc() in tests tearDown method but it doesn't appear to help. There is real memory pinned down there, quite possibly in the leaked threads. > (Unfortunately, I'm home with the baby today, Get him better soon! > so I'm probably > not going to have any uninterrupted time to try to do experiments > like this. If you happen to have time, I'd really like to see the results. > If not, they'll just have to wait a day or two until I have some clear > work time.) Cheers, florin -- "If it's not broken, let's fix it till it is." 41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4
Attachment:
pgpZWhZr6EYT_.pgp
Description: PGP signature