jonnyg@umd5.umd.edu (Jon Greenblatt) (02/13/89)
I am stumped! I am porting a lisp interpreter (xlisp2.0) to MS Windows. I am using an internal memory allocation routine that breaks memory off of large blocks of GLOBAL FIXED memory. The program is compiled under the LARGE model and the data segment is FIXED and NOT SHARED. Once a global memory block is allocated I lock it and never unlock it! The code segment is SHARED MOVEABLE DISCARDABLE. The program EXE is about 180k and takes up 100k of windows memory when loaded, leaving me with 300k memory free. Running small lisp programs it works ok. Running large ones is where the problem is. When I lock about 100k of global fixed memory the environment becomes unstable. I keep all memory locked and fixed. I've put my memory allocator through a rogorous debug and found it to be stable. One other problem I have noticed is that I can load more than one instance of the interpreter but as soon as I use one, the other becomes corrupted. The data segment is 0x28864 bytes, stack checking is on. The lisp dynamic memory is stored in about 17 blocks of global data the biggest of which is 0x9024 bytes. Heapwalker reports the global blocks to be of type TASK. I have the equivalent code running on a unix machine under X Windows, using the same memory allocator and it never bombs under any amount bashing. BTW memory is never freed once allocated, memory management is internal so things just get bigger when they have to. I do all intersegment pointer arithmetic my self in order to rule out the possibily of a compiler error while doing this. If anyone has seen this problem before under these severe conditions or knows of a possilbe fix, please let me know. Xlisp2.0 is supposed to be available from UUNET but there seems to be a delay getting it there. I can only give out my copy to those interested in becoming a pre alpha site for my MS Windows port. If you would like to study the code under MS Windows and want to become a pre-alpha test site, please send me mail. Xlisp 2.0 is public domain free ware and I will give a test copy of the MS Windows code to anyone who wishes to help me with this problem. The final version will become public domain and will be distributed through David Betz, the author of xlisp. BTW xlisp2.0 is much more impressive and writen completely differently than the xlisp1.6 version. JonnyG. (jonnyg@rover.umd.edu) (jonnyg@umd5.umd.edu) (jonnyg%rover.umd.edu@uunet.uu.net)
brent@well.UUCP (Brent Southard) (02/16/89)
In article <4517@umd5.umd.edu> jonnyg@umd5.umd.edu (Jon Greenblatt) writes: > I am stumped! I am porting a lisp interpreter (xlisp2.0) to >MS Windows. I am using an internal memory allocation routine that breaks >memory off of large blocks of GLOBAL FIXED memory. The program is >compiled under the LARGE model and the data segment is FIXED and NOT SHARED. >Once a global memory block is allocated I lock it and never unlock it! Bad move. I'm sure you've been told this before, but I reiterate: don't keep global memory locked in Windows. Windows is CONSTANTLY moving code and data segments around. Even a few small locked segments can bring the machine to a virtual standstill if conditions are right. I realize this means a total rethinking of your memory management routines. We had the same problem with an application my company developed. After keeping data unlocked (except, of course, when using it) and switching to medium model, our memory problems disappeared. In fact, Microsoft acknowledged to us that large model programs are vulnerable to crashing, and their only advice was not to use large model. >The code segment is SHARED MOVEABLE DISCARDABLE. The program EXE is about The SDK Programming Tools Guide, page 74, says that SHARED is used only for 80286 protected-mode programs only. Try using LOADONCALL MOVEABLE DISCARDABLE. >180k and takes up 100k of windows memory when loaded, leaving me with 300k >memory free. Running small lisp programs it works ok. Running large ones >is where the problem is. When I lock about 100k of global fixed memory >the environment becomes unstable. I keep all memory locked and fixed. Please don't do this. Sorry, I already said that... >....The lisp dynamic memory is stored in about 17 blocks of global data >the biggest of which is 0x9024 bytes. Heapwalker reports the global blocks >to be of type TASK. I have the equivalent code running on a unix machine Your data blocks should be of type DATA, not TASK. Something is wrong here. Good luck! brent -- Brent Southard, ImageTech Corp. | Everybody's trying to be a friend of mine, Usenet: ...well!brent | Even a dog can shake hands. - W. Zevon CIS: 76657,415 | We fell into love, love's a very deep hole. GEnie: b.southard | - Loudon Wainwright III
jonnyg@umd5.umd.edu (Jon Greenblatt) (02/17/89)
In article <10731@well.UUCP> brent@well.UUCP (Brent Southard) writes: >In article <4517@umd5.umd.edu> jonnyg@umd5.umd.edu (Jon Greenblatt) writes: >> I am stumped! I am porting a lisp interpreter (xlisp2.0) to >>MS Windows. I am using an internal memory allocation routine that breaks >>memory off of large blocks of GLOBAL FIXED memory. The program is ....... >Bad move. I'm sure you've been told this before, but I reiterate: don't >keep global memory locked in Windows. Windows is CONSTANTLY moving code and >data segments around. Even a few small locked segments can bring the >machine to a virtual standstill if conditions are right. I realize this ....... My problem was do to a programming error but I would like to comment about my experiences thus far with global memory. First of all xlisp 2.0 is written in such a way that makes it extreamly hard to port to the medium memory model. I realy feel it is hard to port just about any large program that uses a lot of memory to MS Windows when the code was not written around MS Windows. Try passing a long string pointer to printf in the medium model for instance. This goes back to a point I like to make that apps cannot realy be portable to MS Windows unless written for MS Windows! I have no plans to make xlisp 2.0 work in the medium model for several reasons: 1: The pointer conversions will make the code unreadable and unsuportable. 2: The code needs to be portable to other operating systems. Half the base system coding in the medium model would be MS Windows dependent. Right now very little code is dependent on any operating system. 3: The fact that Actor has not done any better with their highly system dependent implementation of a dynamic language leads me to believe there is little hope for dynamic languages under MS Windows. Actor promised a virtual memory system but I have not seen it. I thought about making xlisp dynamic but the paging would get overly extensive. Actor uses more fixed memory than my xlisp interpreter. Even though Actor unlocks this memory when not in use you cannot run any other windows programs of any size in most cases. Just becuase you unlock something does not make it take less windows memory. BTW Actor uses one code segment so they seem to be using near function calls. I am not trying to flame Actor, it runs much faster and is much more extensive than Xlisp. I am just trying to point out how hopeless writing a dynamic laguage that follows all the rules of MS Windows can be. My final version of the lisp interpreter will unlock the segments when not in use but this has marginal if any benefit the way the MS Windows memory manager is written to date! I usualy start xlisp before running other apps, this solves most of the fixed memory problems when interacting with the heap. I do plan to "toy" with using Movable/Virtual memory in xlisp but this will slow things down. The large model is here to stay! JonnyG.