jordan@aerospace.aero.org (Larry M. Jordan) (10/24/90)
re: FLAME ON ------------ Frank, you say the system "typically runs out of memory on the second allocation." "Typical" for whom? Obviously, not typical for me, even though my applications tend to be heap intensive. I called JPI tech. support for the details. Unless they're lying to me, the circumstances for the problem seemed pretty obscure--Only those applications which where "close to using all available memory, and those that happened to deallocate the last byte of whole segments." I'm not denying your experience, but your account does seem to distort through overstatement. JPI says the problem was fixed in r1.06. Have you verified this? As to your other remarks: One of the "Heavy duty" (your term, not mine) applications I have been working on the past year-and-a-half is a compiler. It's not very large as compilers go--41 modules and roughly 8500 SLOC. The language is an object-oriented extension to Modula-2 I designed and implemented for my Master's thesis in CS. I translate the source form into Modula-2 and use, in this instance, JPI to compile/debug the generated code. Among other things, the compiler/translator builds a concrete representation of the source for use by subsequent passes. This is a graph built from the heap. No heap problems, then or now. Pragma Inline ------------- I will also continue to post what I consider to be interesting and and unique capabilities (and any and all problems I encounter). I successfully exercised the INLINE capability of the JPI product in a grand way this weekend. I knew the internal representation for my compiler would be changing over time so I hid it behind a wall of interfacing procedures. Most of these are small, and if I were doing this in C, I would have made them macros. In a matter of minutes I made these 40 or so procedures INLINE via the appropriate JPI pragmas, exposed the opaque declaration, moved the procedure bodies into the definition and recompiled. The final executable is slightly larger (155K vs. 145k) and it still works! I successfully recompiled all my test cases with the new executable. I've been waiting for a performance tuning capability like this for Modula-2 for years.
reid@CTC.CONTEL.COM (Tom Reid x4505) (10/25/90)
= As to your other remarks: One of the "Heavy duty" (your term, not = mine) applications I have been working on the past year-and-a-half is a = compiler. It's not very large as compilers go--41 modules and = roughly = 8500 = SLOC. The language is an object-oriented extension to Modula-2 I designed = and = implemented for my Master's thesis in CS. I translate the source form into = Modula-2 and use, in this instance, JPI to compile/debug the generated code. = Among other things, the compiler/translator builds a concrete representation = of the source for use by subsequent passes. This is a graph built from the = heap. No heap problems, then or now. By the time this message got to me, there was not evidence of the author. I would be very interested in both the OO extension and the graphic concrete representation of the source for my translator construction and programming languages courses. Could the author please contact me. Thanks. Tom. Thomas F. Reid, Ph. D. (703)818-4505 (work) Contel Technology Center (703)742-8720 (home) 15000 Conference Center Drive Net: reid@ctc.contel.com P.O. Box 10814 Chantilly, Va. 22021-3808