`
`
`
`
`
`Ex. 1023
`Ex. 1023
`
`US Patent No. 5,765,205 (“Breslau’’)
`US Patent No. 5,765,205 (“Breslau”)
`
`
`
`
`
`

`

`United States Patent [19]
`Breslau et al.
`
`|||||||||||||||||||||||||||||||||||
`US00576.5205A
`[11] Patent Number:
`5,765,205
`[45] Date of Patent:
`Jun. 9, 1998
`
`[54]
`
`METHOD AND SYSTEM FOR ON-DEMAND
`SOFTWARE DISTRIBUTION
`
`[75]
`
`Inventors: Franklin Charles Breslau. Teaneck,
`N.J.; Paul Gregory Greenstein,
`Croton-On-Hudson; John Ted Rodell,
`Wappingers Falls, both of N.Y.
`
`[73]
`
`Assignee: International Business Machines
`Corporation, Armonk, N.Y.
`
`[21]
`[22]
`[51]
`[52]
`[58]
`
`[56]
`
`Appl. No.: 579,541
`Filed:
`Dec. 27, 1995
`Int. Cl* ~~~~~~~~~~~ G06F 12/08
`U.S. Cl. .…..... 711/203; 395/200.46
`Field of Search ......................... 395/200.03, 200.07,
`395/413. 492, 200.46; 711/203, 204, 165
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`5,619,656 4/1997 Graf ................................... 395/200.11
`5,649,140 7/1997 Duvalsaint .............................. 395/413
`
`OTHER PUBLICATIONS
`“Operating
`System
`Concepts”, ISBN
`Peterson,
`0–201–06097–3, pp. 193–198, 1983.
`Custer “Inside Windows NT", ISBN 1-55615—481–X, pp.
`182–184, 288–299, 1993.
`Primary Examiner—Tod R. Swann
`Assistant Examiner—Christopher Chow
`Attorney, Agent, or Firm—Edward H. Duffield, Esq.; Heslin
`& Rothenberg, P.C.
`ABSTRACT
`[57]
`Techniques are presented for efficiently transferring com
`puter code from a source computer to a target computer for
`execution on the target computer. A virtual memory space
`for the computer code is created on the target computer. The
`computer code is linked on the source computer such that
`addressing of the resulting executable version of the com
`puter code corresponds to the allocated virtual memory
`space on the target computer. The executable computer code
`is then stored in the memory of the source computer. As the
`target computer executes the computer code, page faults
`result because its allocated virtual memory space is empty.
`The memory pages required to remediate the page faults are
`obtained from the source computer on an on-demand basis.
`Execution accordingly proceeds.
`38 Claims, 10 Drawing Sheets
`
`Targ: User
`WANTS TO EXECJTE x (43)
`ISSUES “GET X FROM SOURCE" (45}
`
`TARGET cºuTER
`
`sq?zcE COMPUTER
`ExEcurrº X (41)
`
`source bjSER
`
`tº JERIES PERMISSICN
`FROM SOURCE USER (47)
`
`qJERIES SIZE OF x (51) ——-
`RETURNS SIZE OF x (53)
`
`At 3.0CATEs wirTUAL
`STORAGE FoR x (55)
`SENC CºxºM CF
`VIRTUAL STORAGE (57)
`
`CREATE A TARGET-ORIGº!
`werSION OF PROGRAM x (59)
`*—HOONE (61)
`INFORM VSM THAT X*
`PAGES ARE STOREE ON
`SOURCE COMPUTER (63)
`
`sºurce COMPUTER
`
`53URCE JSER
`
`
`
`
`
`TARGET USER
`
`TARCET COMPUTER
`BEGIN EXECUTION OF X (55)
`PAGE FAULT (57)
`REQUEST PAGE (69)
`RETURN PAGE (71)
`
`SEES G13 (73)
`
`SELECTs a FUNCTION (75)
`
`Lºpe
`
`MEcEssaRY
`
`PAGE FAULT (77)
`REQUEST PAGE (79)
`RETURN PAGE (31)
`EXECUTE PAGE {33}
`
`TARGE: JSER
`
`SOURCE compUTER
`
`Sºurce USER
`
`CLOSE x's GUI (85)
`
`DEALLOCATE X (87)
`
`#Forº source cohºl.JTER
`OF TERMINATION OF x (89)
`
`dEALLOCATE X (91)
`
`
`
`
`
`

`

`S. Patent
`U
`U.S. Patent
`
`Jun. 9, 1998
`Jun. 9, 1998
`
`Sheet 1 of 10
`Sheet 1 of 10.
`
`5,765,205
`5,765,205
`
`bt
`
`Et
`
`6/ | //8/
`
`YALAGDWODJOYNNOS
`
`XWVYD0Nd
`
`61
`
`
`
`4/
`4b
`
`82
`EC
`
`le
`2
`
`
`
`YILNdNODLADYVL
`
`Lbf
`
`/ 6), f
`
`eA
`
`

`

`U.S. Patent Veiif
`
`
`
`
`
`
`Y3SNJOYNOSY3LNdNODJDYNOSYSLNdWNODL39Yv1yISNLADNVL
`
`
`(Ss)X4YO439VYOLS
`WNLYIAS3LVOOTIV
`
`NIDINO—LIONVLVJLV3yO
`
`(6S)XWVWY90ddJONOISHSA
`
`
`
`(19)3NOQ
`
`s,XLYHLASAWYOJNI
`
`
`
`NOG3NOLSJuvS39Vd
`
`
`
`
`
`(¢9)Y3LNdNODJOYNOS
`
`(ZS)39VYOLSIWNLYIA
`
`Jun. 9, 1998
`
`Sheet 2 of 10
`
`5,765,205
`
`
`
`(€S)X4O3ZISSNYNLIS
`
`(1S)X4O3ZISS3IN3NO
`
`(67)XO
`
`
`
`4ONIDINOGNIS
`
`
`
`NOISSINY3SdS3IN3aNO
`
`(Ly)XONILNDIXS
`
`
`
`
`
`(Z¢)NaSN30YyNOSNOY4
`
`
`
`
`
`(Sv),30YNOSWONX139,SANSSI
`
`(fv)XJLNOAXIOLSLNVM
`
`
`
`
`
`

`

`U.S. Patent
`
`Jun. 9, 1998
`
`Sheet 3 of 10
`
`5,765,205
`
`Y4aSNJOYNOS
`
`
`YALNdNODJDYNOS
`
`
`
`
`
`YALNdWODL3I9YVLYygaSN
`
`
`
`(S9)X3ONOILNOSXI3NID3IE
`
`
`
`(29)Linv439d
`
`
`
`
`
`(69)39Vd1S3NOIY
`
`
`
`
`
`
`
`LI9NVL
`
`
`
`(1Z)39VdNYNL3YAYWSS3O3N
`
`
`
`
`
`(18)39VdNYNL3YAUYSS3O3N
`
`
`
`
`
`(62)39Vd1S3NO3Y
`
`
`
`
`
`(42)Linv439vd
`
`
`
`(SZ)NOILONN4V$LO373S
`
`
`
`(¢Z)INDS$33S
`
`

`

`U.S. Patent
`
`
`
`Jun. 9, 1998
`
`Sheet 4 of 10
`
`5,765,205
`
`(16) X ELWOOTTW3C]
`
`(Zg) X BIVOOTTW3C]
`
`
`
`(G8) Ino s.X ESOTO
`
`
`
`
`
`

`

`U.S. Patent
`
`Jun. 9, 1998
`
`Sheet 5 of 10
`
`5,765,205
`
`105
`
`141
`
`
`
`
`
`
`
`IS
`DEVICE_TYPE
`A NETWORKING
`PRO?pool
`
`
`
`
`
`143
`
`RETREIVE
`YES PAGE FROM
`REMOTE
`SYSTEM
`
`
`
`
`
`CONVENTIONAL
`PROCESSING
`
`145
`
`fig. 5
`
`

`

`U.S. Patent
`U.S. Patent
`
`Jun. 9, 1998
`
`Sheet 6 of 10
`
`5,765,205
`5,765,205
`
`bEL
`
`
`
`NOILVIOTJ9DIAS0
`
`
`
`
`
`
`
`92 /
`
`
`
`Ket
`
`909, 33
`
`Se.
`6é4LokSélEct
`#-301A30FdA1~BOINGssgyqav~39d|aisv|esl
`
`
`
`JSI07ISOSgo¢44
`
`
`
`
`
`

`

`U.S. Patent
`
`Jun. 9, 1998
`
`Sheet 7 of 10
`
`5,765,205
`
`TARGET COMPUTER REMOTE PAGE RETREVAL
`
`
`
`15?
`
`
`
`153
`
`
`
`155
`
`157
`
`159
`
`RECEIVE REQUEST
`FOR REMOTE PAGE
`
`BUILD PRB FOR
`REMOTE PAGE
`
`TRANSMIT PRE TO
`REMOTE SYSTEM
`
`POSITIVE ACK
`RECEIVED
`2
`
`Y
`
`161
`
`163
`
`WAIT FOR PTB
`
`
`
`165
`
`
`
`RECEIVE PTB
`
`HANDSHAKE WAREMOTE SYSTEM
`
`
`
`167
`
`
`
`169
`
`fig 6
`
`

`

`U.S. Patent
`
`Jun. 9, 1998
`
`Sheet 8 of 10
`
`5,765,205
`
`SOURCE COMPUTER REMOTE PAGE SUPPLY
`
`AWAIT PRB FROM
`TARGET COMPUTER
`
`
`
`
`
`
`
`RECEIVE PRB
`
`181
`
`
`
`
`
`185
`
`187
`
`SEND
`FAILURE
`ACK
`
`
`
`
`
`189
`
`SEND POSITIVE ACK
`
`
`
`
`
`RETREIVE PAGE FROM MEMORY
`
`
`
`191
`
`
`
`
`
`193
`
`BUILD PTB
`
`
`
`
`
`
`
`TRANSMIT PTB TO TARGET COMPUTER
`
`195
`
`HANDSHAKE WITH TARGET COMPUTER
`
`
`
`197
`
`fig. 7
`
`

`

`U.S. Patent
`
`Jun. 9, 1998
`
`Sheet 9 of 10
`
`5,765,205
`
`201
`
`
`
`PAGE REQUEST BLOCK (ARB)
`
`203
`
`205
`
`207
`
`209
`
`221
`
`
`
`223
`
`225
`
`227
`
`229
`
`231
`
`,233
`
`BLOCK SEQUENCE #
`
`ORIGINATOR ID
`
`
`
`CONVERSATION ID
`
`REQUESTED PAGE ADDRESS
`
`
`
`fig. 8
`PAGE REQUEST BLOCK (ARB)
`
`
`
`
`
`
`
`| cºlo
`
`NUMBER OF PAGE (N)
`
`MEMORY PAGE
`
`fig 9
`
`

`

`U.S. Patent
`
`Jun. 9, 1998
`
`Sheet 10 of 10
`
`5,765,205
`
`133
`
`13?
`
`135
`
`STORAGE
`
`
`
`fig 10
`
`

`

`15
`
`1
`METHOD AND SYSTEM FOR ON-DEMAND
`SOFTWARE DISTRIBUTION
`TECHNICAL FIELD
`The present invention relates in general to the transmis
`sion and distribution of computer software. More
`specifically, the present invention relates to a method and
`system for transferring computer code to a receiving com
`puter on an on-demand basis, and also relates to a paging
`10
`technique for use in the transfer.
`BACKGROUND OF THE INVENTION
`As computer technology progresses, the need for tech
`niques that permit different computer users to share each
`other's programs and information also increases. Advanced
`computer communications protocols and networking tech
`nologies continue to develop in pursuit of such information
`exchange. However, software products that link individual
`computer applications and facilitate sharing of programs and
`data lag behind the rapidly advancing computer hardware
`and computer networking infrastructures. For example,
`there is a need for software that enables the distribution of
`programs to remote computers that do not possess enough
`storage capacity to maintain local copies of all potentially
`25
`necessary programs.
`One solution to application sharing is the “OPENDOC”
`standard (a product of work conducted by e.g., “IBM",
`“APPLE”, and “NOVELL" which are all part of the “CIL
`ABS” industry consortium) that permits the transfer of an
`application program from a source computer to a target
`computer. This transfer may be performed while the appli
`cation program executes on the source computer, therefore,
`the application program may be simultaneously used on the
`target computer. According to “OPENDOC” techniques, the
`transfer of an application program from a source computer
`to a target computer necessitates the transfer of the entire
`application program within the “OPENDOC” environment
`before any execution begins and the program can even be
`loaded on the target computer. Therefore, the transfer
`requires extensive communications bandwidth and is expen
`sive in terms of computer power, networkresources and time
`required for completion. Furthermore, a user of the target
`computer cannot start using the transferred application pro
`gram until the transfer is complete.
`In certain circumstances, a user may only need to use a
`small subset of the functions of a program. For example, the
`user may only require the use of the stock quote function of
`a securities portfolio program. Unfortunately, according to
`conventional methods, a program must be transferred in its
`entirety before any specific function may be used.
`The present invention is directed toward improving the
`efficiency and usability of transferring application programs
`between computers.
`SUMMARY OF THE INVENTION
`In a first aspect, the present invention comprises a method
`for use in transferring computer code from a source com
`puter to a target computer for execution. The source com
`puter and the target computer are coupled, and the method
`includes requesting transfer of the computer code from the
`source computer to the target computer. In response to the
`requesting, the method includes providing the source com
`puter with an image of the computer code, wherein the
`image is pageable in by the target computer. The providing
`is performable without the target computer having to
`execute the program.
`
`45
`
`50
`
`55
`
`65
`
`5,765,205
`
`20
`
`30
`
`35
`
`2
`As an enhancement, the source computer may have an
`object code version of the computer code. The providing of
`the source computer with the image of the computer code
`may then include linking the object code version of the
`computer code, on the source computer, to provide the
`image of the computer code that is pageable in by the target
`computer. Further, the linking may be performed such that
`the image has addressing corresponding to a predesignated
`region of memory within the target computer. More
`specifically, the source computer may retrieve a starting
`address of the predesignated region of memory within the
`target computer, and use the starting address during the
`linking, such that the image has the addressing correspond
`ing to the predesignated region of memory within the target
`computer.
`As a further enhancement, the method may include
`executing the computer code on the target computer by
`on-demand paging in of the image of the program by the
`target computer from the source computer. During the
`executing, the entire image may be transferred to the target
`computer. During the transferring, priority may be given to
`the transfer of pages of the image corresponding to page
`faults encountered during the executing. The transferring
`may include sequentially transferring the entire image to the
`target computer, one page at a time. If a page fault occurs,
`a selected next page that resolves the page fault is transferred
`to the target computer.
`In another aspect, the present invention includes a method
`for transferring computer code from a source computer to a
`target computer which has a virtual storage manager. The
`method includes allocating, on the target computer, virtual
`memory space corresponding to the computer code. The
`virtual memory space comprises at least one page of
`memory. An executable version of the computer code is
`stored in a memory of the source computer and has address
`ing corresponding to the virtual memory space of the target
`computer. The method includes accessing, on the target
`computer, the virtual memory space. During this accessing,
`the virtual storage manager transfers portions of the execut
`able version from the source computer to the target computer
`as page faults occur on the target computer.
`As an enhancement, the method may further comprise
`informing the virtual storage manager of the target computer
`that pages of the executable version are stored on the source
`computer. The accessing of the virtual storage space more
`particularly includes executing the executable version on the
`target computer. During the executing, a page fault is
`encountered. In response to the page fault, the virtual storage
`manager requests a selected page of the executable version
`from the source computer, wherein the selected page cures
`the page fault. More specifically, the requesting may include
`looking up an address of the source computer and transmit
`ting a page request block (“PRB") to the source computer
`using the address. The PRB specifies the selected page.
`Thereafter, the target computer awaits a page transmission
`block (“PTB") from the source computer. The PTB includes
`a response to the PRB which contains the selected page.
`In yet another aspect, the present invention includes a
`method for transferring virtual memory pages to a computer
`from a paging device, which is coupled to the computer. The
`method includes storing at least one virtual memory page for
`the computer on the paging device, wherein the at least one
`virtual memory page has not been previously paged out by
`the computer. The method also includes paging the at least
`one virtual memory page into the computer from the paging
`device.
`Computer systems corresponding to the above-described
`methods are also disclosed.
`
`

`

`5,765,205
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`3
`To summarize, the techniques of the present invention
`facilitate a new and useful mechanism for efficiently trans
`ferring computer code from a first computer to a second
`computer. Pages are linked on the source computer such that
`their addressing corresponds to an allocated virtual memory
`space on the target computer. As the target computer requires
`the pages, they are transmitted. Thus, since transfer of
`memory pages is performed on-demand, bandwidth is con
`served and long waiting periods necessary for the transfer of
`an entire program are obviated. These techniques are par
`ticularly useful in the transfer of application programs as it
`is possible for the source computer to execute the desired
`application, and concurrently act as an external paging
`device for a target computer also executing the application
`(although it is not necessary for the source computer to be
`executing the program during the transfer techniques dis
`closed herein). In accordance with this new functionality and
`increased efficiency, the present invention comprises an
`advancement in software transmission techniques.
`BRIEF DESCRIPTION OF THE DRAWINGS
`The subject matter regarded as the present invention is
`particularly pointed out and distinctly claimed in the con
`cluding portion of the specification. The invention, however,
`both as to organization and method of practice, together with
`further objects and advantages thereof, may best be under
`stood by reference to the following detailed description
`taken in conjunction with the accompanying drawings in
`which:
`FIG. 1 is a diagram of one example of a network con
`nected source computer and target computer pursuant to one
`embodiment of the present invention;
`FIGS. 2A–C depict a flow-diagram of a technique for
`on-demand software distribution according to an embodi
`ment of the present invention;
`FIG. 3 is a diagram of computer system elements used for
`memory paging in connection with one embodiment of the
`present invention;
`FIG. 4 is one example of an Auxiliary Storage Manager
`(“Auxiliary Storage Manager”) look-up table for use within
`an embodiment of the present invention;
`FIG. 5 is a flow-diagram of target computer Auxiliary
`Storage Manager processing pursuant to one embodiment of
`the present invention;
`FIG. 6 is a flow-diagram of target computer remote page
`retrieval processing in conformance with an embodiment of
`the present invention;
`FIG. 7 is a flow-diagram of source computer remote page
`supply processing in accordance with one embodiment of
`the present invention;
`FIG. 8 is a diagram of one example of a page request
`block (“PRB");
`FIG. 9 is a diagram of one example of a page transmission
`block (“PTB"); and
`FIG. 10 is a diagram of one embodiment of a computer
`system useful in implementing the techniques of the present
`invention.
`
`45
`
`50
`
`55
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENT
`Through the application of virtual memory concepts, the
`present invention facilitates the increased efficiency and
`usability of transferring computer code between computers.
`During a transfer of, e.g., an application program from a
`
`65
`
`4
`source computer to a target computer, the source computer
`becomes a virtual memory paging device for the target
`computer. The source computer creates an image of the
`computer code corresponding to the application program in
`its memory. The image is pageable into an allocated, but
`empty region of virtual memory allocated on the target
`computer. As the target computer executes the application
`program and accordingly requires pages of memory within
`its allocated virtual address space, it retrieves them from the
`source computer. Thus, only the bandwidth required for
`transfer of necessary memory pages is used, and execution
`of the transferred application program may begin much
`earlier than was heretofore possible. Overall efficiency and
`usability of the shared application program are therefore
`increased.
`One embodiment of the hardware elements of a computer
`system used to carry out the techniques of the present
`invention are shown in FIG. 10. A central processing unit
`(“CPU”) 241 provides main processing functionality. A
`memory 243 is coupled to CPU 241 for providing opera
`tional storage of programs and data. Memory 243 may
`include, for example, random access memory (“RAM”) or
`read only memory (“ROM"). Non-volatile storage of, for
`example, data files and programs is provided by a storage
`245 that may include, for example, disk storage. Both
`memory 243 and storage 245 comprise a computer usable
`medium that may store computer program products in the
`form of computer readable program code. User input and
`output is provided by a user input/output (“I/O”) facility
`247. User I/O facility 247 may include, for example, a
`graphical display, a mouse and/or a graphics tablet. As an
`example, the system of FIG. 10 may comprise an “INTEL"
`processor based International Business Machines Personal
`Computer executing an “IBM OS/2 WARP” operating sys
`tem.
`In regard to the techniques of the present invention, and
`as shown in FIG. 1, a source computer 11 has a program X
`13 executing thereon. A source user 15 interacts with source
`computer 11 through source terminal 17. The exact configu
`ration of source terminal 17 will vary with the configuration
`of the computer system. In one embodiment, source terminal
`17 includes a keyboard, mouse and video monitor attached
`by interconnection 19 to source computer 11 (e.g., an
`“INTEL" processor based “IBM" personal computer).
`Alternatively, source terminal 17 could by an X-Station,
`connection 19 could be a network connection and source
`computer 11 could be a mainframe computer.
`A target computer 21 is coupled to source computer 11
`through a network connection 23 that is established using
`any conventional networking protocol (e.g., Transmission
`Control Protocol/Internet Protocol—“TCP/IP”,
`“NETBIOS", “IPX” (“NOVELL"), Systems Network
`Architecture—“SNA”) or any other communication path
`that permits a bi-directional transfer of data (e.g., a direct
`processor-to-processor connection). A target terminal 25
`attaches to target computer 21 through interconnection 27.
`Target terminal 25 supports a target user 29. Target terminal
`25, target computer 21 and interconnection 27 may have
`several configurations as discussed hereinabove with respect
`to source terminal 17, source computer 11 and interconnec
`tion 19. As one variation, target user 29 (or source user 15)
`could be another computer program executing on target
`computer 21.
`One embodiment of the process for on-demand transfer of
`program Xfrom the source computer to the target computer,
`in accordance with the principles of the present invention, is
`described in detail below with reference to the flow diagram
`
`

`

`5,765,205
`
`5
`of FIGS. 2A-2C. Initially, the source user begins using
`program X on the source computer (step 41). Some time
`thereafter, the target user decides that he or she wants to use
`program X (step 43) and issues a command “Run X from
`<source computer>” to the source computer (step 45). This
`command maybe instantiated from, e.g., a commandline or
`an icon in a graphical user interface (“GUI”) environment.
`(Note: The techniques disclosed herein are equally appli-
`cable evenif there is no source user using program X; the
`ability to perform a transfer of the program ‘to the target
`computer concurrently with a source user using program X
`is an enhanced feature of the techniques of the present
`invention).
`The “Run X from <source computer>” command is
`implemented as an extension to the conventional user pro-
`gram invocation mechanism. For example, in an “IBM OS/2
`WARP”operating environment, a user may invoke a pro-
`gram by,e.g., entering the program name from a command
`prompt or double clicking a mouse button on an icon
`corresponding to the program. Once a user has performed
`either of these functions, the system will locate the program,
`load it in memory andstart it’s execution (i.e. branch to its
`entry point).
`In particular. in one embodiment, an icon is displayed
`within the user’s desktop, and correspondsto the mechanism
`described hereinbelow used to get a program from the
`source computer. Associated with the icon is the nameof the
`program to get and the networking address of the source
`computer. A double click on the icon using a mouse button
`will then locate, load, and execute the program. As an
`enhancement, the target user may be prompted for either or
`both of the name of the program to get and the network
`address of the source computer whenthe iconis instantiated.
`Resulting from the issuance of the “Run X from <source
`computer>” commandis a following step that determinesif
`the target user (and/or the target computer) is authorized to
`access and execute program X. A query is presented to the
`source user at the source terminal (step 47). The query will
`inform the source user that the target user on the target
`computer desires usage of program X. The source user then
`responds to the query. If the source user denies the target
`user’s access request, the target user is so informed and the
`process terminates. If the source user approves access to
`program X,this approval is forwardedto the target computer
`and the process continues (step 49).
`In an alternate
`embodiment, permission processing can be removed, or
`automated using, e.g., a predefined security policy on the
`source computer.
`To accommodate program X,one step the target computer
`performs is allocating virtual memory space for program X.
`The target computer queries the source computer for the size
`of program X (step 51) such that it may allocate the proper
`amount of virtual memory space. The source computer
`responds with the size of program X (step 53) and the target
`computer accordingly allocates the appropriate amount of
`virtual memory space (step 55). Such allocation is per-
`formed using conventional virtual memory management
`techniques that will vary depending on the particular oper-
`ating hardware and software. In one embodiment in which
`the target computer comprises, ¢.g.. an “IBM” Personal
`Computer executing the “OS/2 WARP” Operating System,
`the OS/2 Page Manager(alsoreferred to herein as the virtual
`storage manager (“VSM”)) is used to manage virtual
`memory and may be instructed using conventional tech-
`niques to allocate the requisite virtual memory space for
`program X. VSM’s are described in detail in, for example,
`Designing OS/2 Applications, D. E. Riech, J. Wyley and
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`6
`Son’s Inc., 1993, Doc. # ISBN 0-471-58889-X; Inside OS/2
`2.1, Minasi, et al., NRP, 1993, ISBN 1-56205-206-3; and
`MVS/370 System Logic Library, Volume 3, IBM document
`number LY28-1067-01;, which are incorporated herein by
`reference in their entireties.
`According to the techniques of the present invention, in
`one example, the VSM of the target computer is passed a
`new parameter, (e.g., “NOTNEW”) informing it that the
`virtual memory pageswill not beinitially loaded, but will be
`retrieved from a remote paging device. Upon detection of
`this parameter, the VSM sets its internal tables and pointers
`as though the virtual memory pages have already been
`loaded, even thoughthey have not. Thus, upon encountering
`a first page fault, the VSM attempts to retrieve the memory
`page from a paging device, and does not expect (as it
`normally would upona first page fault) that the page will be
`’ filled in by a program.
`To continue, the origin of the allocated virtual memory
`space on the target computer is forwarded to the source
`computer (step 57), which then usesthis origin to create a
`target computer origin version of program X, which is stored
`on the source computerin its virtual memory pool or in a
`dataset (step 59). The target computer is notified after this
`step has been completed (step 61). In one embodiment,
`creation of an executable version of a program at a desig-
`nated origin is performable using a conventional relocatable
`program linkageeditor (the target and source computers are
`assumed compatible in terms of object code). As one
`example, the object code for program X and the desired
`origin are input to a linkage editor executing on the source
`computer. The linkage editor creates an executable version
`of the program beginning at the designated origin. The
`resulting executable code is stored within the memory space
`(e.g., real and/or virtual) of the source computer such that
`the memory pages associated with the program are acces-
`sible in succeeding steps. In, for instance, the “IBM OS/2
`WARP”operating system, the linkage editor is included as
`part thereof.
`In responseto the target computer being notified that the
`target origin version of program X has beencreated and is
`stored in the memory space of the source computer, a
`messageis sent to the Auxiliary Storage Manager(discussed
`further hereinbelow)of the target computer informing it that
`the virtual memory pages for program X are stored on the
`source computer (step 63). Virtual memory tables used by
`the Auxiliary Storage Manager of the target computer to
`identify the source of virtual memory pagesare then updated
`to point to the source computer regarding the memory pages
`of program X (see, ¢.g., FIG. 4 and the accompanying
`discussion below).
`Program X may now begin execution on the target com-
`puter (step 65—FIG. 2B). However, since none of program
`X has been paged into the allocated virtual memory of the
`target computer, a page fault results uponthe instantiation of
`execution of program X (step 67). The VSM of thetarget
`computer respondsto the page fault by retrieving the faulted
`page of memory from the source computer. Specifically, a
`request is sent (on behalf of the VSM) from the Auxiliary
`Storage Manager of the target computer to the source
`computer for the needed page of memory (step 69). The
`source computer retrieves the requested page of memory
`from the target computer origin version of program X in its
`memory andtransfers the page to the target computer (step
`71). Execution may then proceed. (Further details of the
`paging process are described below with respect to FIGS.
`3-9).
`During execution of program X on the target computer,
`further page faults may occur as execution proceeds into
`
`45
`
`5a
`
`55
`
`65
`
`

`

`7
`areas of the allocated virtual memory space that have not yet
`been loaded. As each page fault occurs, the above-described
`process of the target computer retrieving the necessary
`memory pages from the source computer continues (steps
`67, 69 & 71).
`In implementation of the techniques disclosed herein, a
`first matter that a typical program may attend to is the
`presentation of an interface (e.g., a GUI) to the user. In such
`a case, the above described initial execution and memory
`page loading would result in the memory pages correspond
`ing to the GUI being loaded and the GUI being presented to
`the target user (step 73). If the target user then selects a
`function (step 75) from the GUI (e.g., clicks using a mouse
`on a menu item), whose execution requires accessing a
`memory page not yet loaded, the above-described process
`repeats for the required memory pages. Specifically, a page
`fault occurs (step 77), a request is sent from the target
`computer to the source computer for the required memory
`page (step 79), the source computer forwards the required
`memory page to the target computer (step 81) and execution
`proceeds.
`It is possible that the same memory page may be
`requested from the source computer more than once. This
`may happen when, e.g., an unmodified virtual page is paged
`out, but its contents are simply discarded because it can be
`retrieved again from the paging device (e.g., source
`computer). It is also possible that, e.g., the memory page will
`be paged out to a conventional paging device and subse
`quent retrieval of the memory page will be from that paging
`device. Thus, as one variation on the techniques disclosed
`herein, when a page is written out from the target computer,
`30
`appropriate Auxiliary Storage Manager tables may be modi
`fied such that it is written to a conventional paging device,
`and not the source computer which was used to bring the
`page in.
`After the target user has completed using program X, he
`terminates its execution, e.g., by closing a window within
`program X's GUI (step 85—FIG. 2C). Control is accord
`ingly returned to the invoker of program X's execution
`which will issue a signal to the system to free the memory
`occupied by program X. The VSM of the target computer
`will then deallocate the virtual memory space program X
`resided in (step 87), thereby terminating the existence of
`program X on the target computer. After the VSM has freed
`the virtual memory it will signal the system to make the real
`pages occupied thereby available for use. Further, the target
`computer informs the source computer of the termination of
`usage and deallocation of program X (step 89). In response,
`the source computer also deallocates the memory that the
`target computer origin version of program X was stored in
`(step 91), and the process is completed.
`As one variation on the techniques disclosed herein,
`transmission of all memory pages of program X from the
`source computer to the target computer may be performed,
`however, with priority given to any immediately needed
`memory pages (due to, e.g., page faults). For example, after
`the target computer begins executing program X, it would,
`e.g., sequentially begin loading each memory page of the
`target computer origin version of program Xfrom the source
`computer. While this loading is occurring, if a page fault
`occurs on the target computer due to usage of program X by
`the target user, the transfer of the memory page required to
`remediate the page fault would be given priority and trans
`ferred to the target computer. As a result, the target user will
`be able to initially use program X without waiting for the
`entire program to be transferred. After the entire transfer of
`program X to the target computer, no data transfer delays
`will exist in accessing any portion of program X.
`
`35
`
`45
`
`50
`
`55
`
`65
`
`5,765,205
`
`10
`
`15
`
`20
`
`25
`
`8
`Further details regarding the techniques for transferring
`pages of memory between the source computer and the
`target computer are discussed hereinbelow with reference to
`FIGS, 3–9.
`Shown in FIG. 3 is one example of the computer system
`elements involved in virtual memory processing. A virtual
`storage manager (“VSM”) 101 handles virtual memory
`processing including, e.g., performing virtual memory
`allocation/deallocation, servicing page faults and coordinat
`ing access to virtual memory from various tasks. Coupled to
`VSM 101 is an Auxiliary Storage Manager (“Auxiliary
`Storage Manager”) 103 that controls the transfer of memory
`pages between real storage (e.g., system random access
`memory) and external paging storage. External paging stor
`age is provided on external paging devices such as, e.g., disk
`storage 105 and a remote paging device available on a
`network 107. Disk storage 105 may comprise, e.g., a local
`Small Computer System Interface (“SCSI") hard disk con
`nected to the computer system through a SCSI interface 109.
`Network 107 may comprise, e.g., a Transmission Control
`Protocol/Internet Protocol (“TCP/IP”) network connected to
`the computer system through, e.g., a token ring interface
`111.
`The particular implementat