Even after porting to VW74, we still see this error. It seems to
happen "after a while." Sounds like a memory leak, huh? Originally it was. And by switching to Announcements we got rid of that. And now we still get it after a while. This time I'm sure there's not a memory leak. Top, printing all memory, etc. There's lots of memory left. The common theme I've noticed now seem to be allocating _fixed_ memory though. I'm off to do dig through the VM source. I wonder if others when they've seen these problems have been using Fixed memory. Does anyone else even really used Fixed memory. Our app uses it heavily. In large 4MB chunks. -- Travis Griggs Objologist "Dying men never wish they'd spent more time at the office" ----------------------------------------- DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm |
When is fixed space compacted? I don't think that ever happens while the
image is running. If this is true, smaller allocations may be fragmenting the space preventing the allocation of a contiguous piece of 4MB. Joerg -----Original Message----- From: Travis Griggs [mailto:[hidden email]] Sent: Thursday, February 16, 2006 8:31 AM To: VW NC Subject: Unable to Allocate Memory Even after porting to VW74, we still see this error. It seems to happen "after a while." Sounds like a memory leak, huh? Originally it was. And by switching to Announcements we got rid of that. And now we still get it after a while. This time I'm sure there's not a memory leak. Top, printing all memory, etc. There's lots of memory left. The common theme I've noticed now seem to be allocating _fixed_ memory though. I'm off to do dig through the VM source. I wonder if others when they've seen these problems have been using Fixed memory. Does anyone else even really used Fixed memory. Our app uses it heavily. In large 4MB chunks. -- Travis Griggs Objologist "Dying men never wish they'd spent more time at the office" ----------------------------------------- DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm |
On Feb 16, 2006, at 8:39, Joerg Beekmann wrote: > When is fixed space compacted? I don't think that ever happens > while the > image is running. If this is true, smaller allocations may be > fragmenting the space preventing the allocation of a contiguous > piece of > 4MB. I guess I've always taken it for granted. Not that I'm naive enough I don't understand fragmentation and the effects thereof. But after reading enough GC literature, I guess I've bought into the "fragmentation worries are usually overrated" sentiment. I will look into this some more because I'm curious what really is going on. It would be handy of the VM had some mechanism of showing fixed space fragmentation... That aside. It still doesn't make sense why it fails. OK, so I'm making poor use of my fixed space (possibly). But I've got lots more of it. Why is it deciding prematurely to cease letting me fragment even more fixed space. Unless there's a limit hidden somewhere that I don't see. I've looked at MemoryPolicy and don't see anything that looks like it does that. Though I'm not sure I understand completely the context of "threaded data" in said classes comment. I've put together a little "showFixedSpaceStats" on ObjectMemory to put in my end application and watch what it reports over time. The interesting thing is to run it in my dev image. Where there are no fixed space objects, or are there? Because it shows that I have: 204800 fixed space bytes total 0 used 1 fixed object That doesn't make sense. Maybe there's an object out there with a fixed space body of 0 size? So I do an: ObjectMemory allObjectsDo: [:each | each occupiesFixedSpace ifTrue: [each halt]] Run that, and none comes up. (occupiesFixedSpace is a variant of isFixedArgument, but it does not include immediates). So that's just weird. I hope Eliot is watching this thread. Would love to have his thoughts on some of this. -- Travis Griggs Objologist "Conference calls: the appearance of doing work without the substance thereof" - Bruce Boyer ----------------------------------------- DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm |
In reply to this post by Travis Griggs
From page 8 of doc\TechNotes\vwMemoryMgmt.pdf,
<quote> Since the contents of Fixed Space can't move, it cannot be compacted, and so quickly becomes fragmented. Fixed Space is coallesced at image start-up, so can be compacted by saving the image, quitting, and then restarting. </quote> Hope this helps, it's a somewhat comprehensive document depending on how much detail you may be looking for, Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: Travis Griggs [mailto:[hidden email]] > Sent: Thursday, February 16, 2006 9:37 AM > To: VW NC > Subject: Re: Unable to Allocate Memory > > > On Feb 16, 2006, at 8:39, Joerg Beekmann wrote: > > > When is fixed space compacted? I don't think that ever > happens while > > the image is running. If this is true, smaller allocations may be > > fragmenting the space preventing the allocation of a > contiguous piece > > of 4MB. > > I guess I've always taken it for granted. Not that I'm naive > enough I don't understand fragmentation and the effects > thereof. But after reading enough GC literature, I guess I've > bought into the "fragmentation worries are usually overrated" > sentiment. I will look into this some more because I'm > curious what really is going on. It would be handy of the VM > had some mechanism of showing fixed space fragmentation... > > That aside. It still doesn't make sense why it fails. OK, so > I'm making poor use of my fixed space (possibly). But I've > got lots more of it. Why is it deciding prematurely to cease > letting me fragment even more fixed space. Unless there's a > limit hidden somewhere that I don't see. I've looked at > MemoryPolicy and don't see anything that looks like it does > that. Though I'm not sure I understand completely the context > of "threaded data" in said classes comment. > > I've put together a little "showFixedSpaceStats" on > ObjectMemory to put in my end application and watch what it > reports over time. The interesting thing is to run it in my > dev image. Where there are no fixed space objects, or are > there? Because it shows that I have: > 204800 fixed space bytes total > 0 used > 1 fixed object > > That doesn't make sense. Maybe there's an object out there > with a fixed space body of 0 size? So I do an: > > ObjectMemory allObjectsDo: [:each | each occupiesFixedSpace ifTrue: > [each halt]] > > Run that, and none comes up. > (occupiesFixedSpace is a variant of isFixedArgument, but it > does not include immediates). So that's just weird. > > I hope Eliot is watching this thread. Would love to have his > thoughts on some of this. > > -- > Travis Griggs > Objologist > "Conference calls: the appearance of doing work without the > substance thereof" - Bruce Boyer > > > > ----------------------------------------- > DISCLAIMER: This email is bound by the terms and conditions > described at http://www.key.net/disclaimer.htm > > smime.p7s (4K) Download Attachment |
This is a bit extreme, but you should be able to "compact"
fixed space by emptying it, doing a gc, then refilling it. Of course this may not be practical. Terry =========================================================== Terry Raymond Smalltalk Professional Debug Package Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: Boris Popov [mailto:[hidden email]] > Sent: Thursday, February 16, 2006 12:51 PM > To: Travis Griggs; VW NC > Subject: RE: Unable to Allocate Memory > > From page 8 of doc\TechNotes\vwMemoryMgmt.pdf, > > <quote> > Since the contents of Fixed Space can't move, it cannot be compacted, > and so quickly becomes fragmented. Fixed Space is coallesced at image > start-up, so can be compacted by saving the image, quitting, and then > restarting. > </quote> > > Hope this helps, it's a somewhat comprehensive document depending on how > much detail you may be looking for, > > Cheers! > > -Boris > > -- > +1.604.689.0322 > DeepCove Labs Ltd. > 4th floor 595 Howe Street > Vancouver, Canada V6C 2T5 > > [hidden email] > > CONFIDENTIALITY NOTICE > > This email is intended only for the persons named in the message > header. Unless otherwise indicated, it contains information that is > private and confidential. If you have received it in error, please > notify the sender and delete the entire message including any > attachments. > > Thank you. > > > > -----Original Message----- > > From: Travis Griggs [mailto:[hidden email]] > > Sent: Thursday, February 16, 2006 9:37 AM > > To: VW NC > > Subject: Re: Unable to Allocate Memory > > > > > > On Feb 16, 2006, at 8:39, Joerg Beekmann wrote: > > > > > When is fixed space compacted? I don't think that ever > > happens while > > > the image is running. If this is true, smaller allocations may be > > > fragmenting the space preventing the allocation of a > > contiguous piece > > > of 4MB. > > > > I guess I've always taken it for granted. Not that I'm naive > > enough I don't understand fragmentation and the effects > > thereof. But after reading enough GC literature, I guess I've > > bought into the "fragmentation worries are usually overrated" > > sentiment. I will look into this some more because I'm > > curious what really is going on. It would be handy of the VM > > had some mechanism of showing fixed space fragmentation... > > > > That aside. It still doesn't make sense why it fails. OK, so > > I'm making poor use of my fixed space (possibly). But I've > > got lots more of it. Why is it deciding prematurely to cease > > letting me fragment even more fixed space. Unless there's a > > limit hidden somewhere that I don't see. I've looked at > > MemoryPolicy and don't see anything that looks like it does > > that. Though I'm not sure I understand completely the context > > of "threaded data" in said classes comment. > > > > I've put together a little "showFixedSpaceStats" on > > ObjectMemory to put in my end application and watch what it > > reports over time. The interesting thing is to run it in my > > dev image. Where there are no fixed space objects, or are > > there? Because it shows that I have: > > 204800 fixed space bytes total > > 0 used > > 1 fixed object > > > > That doesn't make sense. Maybe there's an object out there > > with a fixed space body of 0 size? So I do an: > > > > ObjectMemory allObjectsDo: [:each | each occupiesFixedSpace ifTrue: > > [each halt]] > > > > Run that, and none comes up. > > (occupiesFixedSpace is a variant of isFixedArgument, but it > > does not include immediates). So that's just weird. > > > > I hope Eliot is watching this thread. Would love to have his > > thoughts on some of this. > > > > -- > > Travis Griggs > > Objologist > > "Conference calls: the appearance of doing work without the > > substance thereof" - Bruce Boyer > > > > > > > > ----------------------------------------- > > DISCLAIMER: This email is bound by the terms and conditions > > described at http://www.key.net/disclaimer.htm > > > > |
Free forum by Nabble | Edit this page |