Browse Prior Art Database

Efficient Memory Allocation for Smalltalk/V PM

IP.com Disclosure Number: IPCOM000114535D
Original Publication Date: 1992-Oct-01
Included in the Prior Art Database: 2005-Mar-28
Document File: 2 page(s) / 73K

Publishing Venue

IBM

Related People

Griffin, DL: AUTHOR [+2]

Abstract

Current art for both system and application function built using Smalltalk/V* PM is inefficient in interfacing to the OS/2** memory systems. Specifically, all current functions which require a string or strings to be passed in memory outside Smalltalk require each of those strings to be written to memory and the memory individually allocated. Since memory allocation is an expensive operation, and the pool of resources available for allocation is limited, this can present a bottleneck in Smalltalk/V PM applications.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Efficient Memory Allocation for Smalltalk/V PM

       Current art for both system and application function
built using Smalltalk/V* PM is inefficient in interfacing to the
OS/2** memory systems.  Specifically, all current functions which
require a string or strings to be passed in memory outside Smalltalk
require each of those strings to be written to memory and the memory
individually allocated.  Since memory allocation is an expensive
operation, and the pool of resources available for allocation is
limited, this can present a bottleneck in Smalltalk/V PM
applications.

      In summary, this article defines a technique for allocation of
chunks of memory which is then used for calls which require this
external memory.  The allocation, address manipulation, and the
freeing of the allocated memory is handled outside the application
domain in order to minimize the impact of the application programmer.

      For purposes of this disclosure, strings will be used as an
example.  It should be understood that this technique also
encompasses structures, numbers, or any combination.

      The current art in Smalltalk/V PM includes a technique to
obtain memory outside Smalltalk.  Use of this memory is required when
interfacing with functions outside Smalltalk since Smalltalk memory
can be moved at anytime and this relocation causes problems for
non-Smalltalk functions.  The current way to allocate three strings
for a function call is to send
      'anAddress:= PMAddress copyToNonSmalltalkMemory: aString.'
for each of the strings.  This results in a piece of memory of the
length of a...