ON-DEMAND LOADING OF DYNAMIC SCRIPTING LANGUAGE CODE FOR REDUCED MEMORY USAGE

Abstract

A computer-implemented method and system for reducing the amount of memory space required to store applications written in dynamic scripting languages loads a program module into memory and removes a category of program code, such as debug information or function definitions, from the program module. The method and system also receives a request for debug information, or a function call or query, and determines whether or not the corresponding program code is in memory. If not, then the location in storage is identified where the program module is stored, and another copy containing the corresponding program code is loaded into memory. The corresponding program code is located and copied into the program module in memory, and a response is provided to the request.

Claims

1. A method for on-demand loading of code, the method comprising: storing, in a first memory, an initially compiled bytecode of a dynamic scripting language program and storing, in a second memory, a redacted source code placeholder in place of a function portion of a function of the dynamic scripting language program, the redacted source code placeholder identifying a location of the function portion in the second memory; creating, by at least one processor, a tree structure comprising a plurality of nodes, each node of the plurality of nodes including compiled bytecode for a corresponding function of the dynamic scripting language program; receiving, by the at least one processor, a call or query request for the function corresponding to the function portion, and in response to the call or query request: determining the function portion is not in in the first memory; searching the tree structure using the location to obtain the function portion compiled bytecode corresponding to the function portion; and storing the obtained compiled function portion bytecode in the first memory.

2. The method of claim 1, wherein the compiled bytecode is executed within a virtual machine.

3. The method of claim 1, wherein the location comprises a source file name.

4. The method of claim 1, wherein the location comprises a beginning line number.

5. The method of claim 1, wherein the location comprises an ending line number.

6. The method of claim 1, wherein the location comprises a column number.

7. The method of claim 1, wherein the redacted source code placeholder points to the redacted function portion in the source code.

8. The method of claim 1, wherein the redacted source code placeholder points to the redacted function portion in the source code in the second memory.

9. A device comprising: a memory storing instructions; and at least one processor in communication with the memory, the at least one processor configured, upon execution of the instructions, to perform the following steps: store, in a first memory, an initially compiled bytecode of a dynamic scripting language program and store, in a second memory, a redacted source code placeholder in place of a function portion of a function of the dynamic scripting language program, the redacted source code placeholder identifying a location of the function portion in the second memory; create a tree structure comprising a plurality of nodes, each node of the plurality of nodes including compiled bytecode for a corresponding function of the dynamic scripting language program; receive a call or query request for the function corresponding to the function portion, and in response to the call or query request: determine the function portion is not in the first memory; search the tree structure using the location to obtain the function portion compiled bytecode corresponding to the function portion; and store the obtained compiled function portion bytecode in the first memory.

10. The device of claim 9, wherein the compiled bytecode is executed within a virtual machine.

11. The device of claim 9, wherein the location comprises a source file name.

12. The device of claim 9, wherein the location comprises a beginning line number.

13. The device of claim 9, wherein the location comprises an ending line number.

14. The device of claim 9, wherein the location comprises a column number.

15. The device of claim 9, wherein the device comprises an on-demand loader.

16. The device of claim 9, wherein the redacted source code placeholder points to the redacted function portion in the source code.

17. The device of claim 9, wherein the redacted source code placeholder points to the redacted function portion in the source code in the second memory.

18. A non-transitory computer-readable media storing computer instructions for on-demand loading of code that configure at least one processor, upon execution of the instructions, to perform the following steps: storing, in a first memory, an initially compiled bytecode of a dynamic scripting language program and storing, in a second memory, a redacted source code placeholder in place of a function portion of a function of the dynamic scripting language program, the redacted source code placeholder identifying a location of the function portion in the second memory; creating a tree structure comprising a plurality of nodes, each node of the plurality of nodes including compiled bytecode for a corresponding function of the dynamic scripting language program; receiving a call or query request for the function corresponding to the function portion, and in response to the call or query request: determining the function portion is not in the first memory; searching the tree structure using the location to obtain the function portion compiled bytecode corresponding to the function portion; and storing the obtained compiled function portion bytecode in the first memory.

19. The computer-readable media of claim 18, wherein the redacted source code placeholder points to the redacted function portion in the source code.

20. The computer-readable media of claim 18, wherein the redacted source code placeholder points to the redacted function portion in the source code in the second memory.

Description

DESCRIPTION OF THE DRAWINGS

[0015] FIG. 1 is a schematic view illustrating a dynamic-scripting-language virtual machine that employs an on-demand source-code loader in accordance with an embodiment of the present invention.

[0016] FIG. 2 is a schematic view depicting a computing system that can implement the dynamic-scripting-language virtual machine of FIG. 1.

[0017] FIG. 3 is a flowchart representing a method of on-demand dynamic-scripting language source-code debug information loading in accordance with an embodiment of the present invention.

[0018] FIG. 4 is an illustration of a redacted function placeholder and a compiled dynamic scripting-language application tree structure in accordance with an embodiment of the present invention.

[0019] FIG. 5 is a flowchart representing a method of on-demand dynamic-scripting language source-code function loading in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION

[0020] An embodiment of the present invention is shown in FIG. 1, which illustrates an exemplary dynamic-scripting-language virtual machine 10 that employs an on-demand dynamic scripting-language source-code loading process in order to reduce the memory space required to store an application in dynamic-scripting-language source code 12. The virtual machine 10 includes a code loader 14, an on-demand loader 16, an interpreter 18, an object 20 and a client 22.

[0021] The code loader 14 reads the original-text source code 12, redacts each application object 20 by removing a category of program code, and loads, or inserts, a redacted source code placeholder for each object 20 into memory. For example, in one embodiment the code loader 14 removes debug information from each of the function objects in the source code 12 during online compiling, and loads the redacted source code for each object 20 into memory. In another embodiment, the code loader 14 generates a function stub for each function in the original source code 12. For example, the function stub records meta information, such as the source code filename, the function proto, and the start and end location (line and column numbers) of the function in the source file.

[0022] Thus, the virtual machine 10 removes a category of program code, such as debug information or function code, and stores the location where to find the original source code, when the virtual machine 10 loads and compiles the source code into bytecode in memory. In an alternative embodiment, the redacted function code section data is stored in secondary storage, such as a hard disk drive. Because the source code placeholders occupy relatively less memory space compared to the full source code, the memory consumption of the dynamic-scripting language application is reduced.

[0023] When the object 20 subsequently is called or queried, or debug information is requested, the on-demand loader 16 prompts the code loader 14 to reload the source code 12 and create a compiled tree structure of the function objects including the full function section code or debug information. The on-demand loader 16 searches the tree structure for the function object that corresponds to the called or queried object or the requested information. The code section or debug information is copied from the tree structure to the object 20, which is returned to the requesting or calling client 22.

[0024] In various embodiments of the invention, the virtual machine 10 runtime environment generates the requested debug information or code section on demand and dynamically modifies the function stub to form a complete function object according to the runtime behaviors. Thus, only functions actually executed at run time are filled with code section or debug information in memory. All other functions in the source code are represented in memory by a redacted placeholder, for example, a function stub or a function object without debug information.

[0025] The on-demand dynamic-scripting-language source-code loading systems described herein can offer advantages such as reduced memory consumption. The amount of memory required to store the bytecode is essentially reduced by the quantity of debug information or code removed, yet the detailed code sections or debug information is made available when requested. There are no language specific limitations, so this approach can be used with any dynamic scripting language. All of the components of the source code application can maintain the original features. In this transparent, purely dynamic approach, no additional precompilation step is required. The original source code can be maintained in storage using any known compression algorithm.

[0026] As illustrated in FIG. 2, an exemplary computing device 30 that can implement the dynamic-scripting-language virtual machine 10 of FIG. 1 includes a processor 32, a memory 34, an input/output device (I/0) 36 storage 38 and a network interface 40. The various components of the computing device 30 are coupled by a local data link 42, which in various embodiments incorporates, for example, an address bus, a data bus, a serial bus, a parallel bus, or any combination of these.

[0027] The computing device 30 communicates information to and requests input from the user or other devices by way of the I/0 36, which in various embodiments incorporates, for example, an interactive, menu-driven, visual display-based user interface, or graphical user interface (GUI), a pointing device, such as a, with which the user may interactively input information using direct manipulation of the GUI. In some embodiments, direct manipulation includes the use of an alphanumeric input device, such as a keyboard, a pointing device, such as a mouse, a touchpad, a trackball, a joystick or a stylus, to select from a variety of windows, icons and selectable fields, including selectable menus, drop-down menus, tabs, buttons, bullets, checkboxes, text boxes, and the like. Nevertheless, various embodiments of the invention may incorporate any number of additional functional user interface schemes in place of this interface scheme, with or without the use of an alphanumeric input device, a pointing device, buttons or keys, for example, using direct voice input.

[0028] The computing device 30 can be coupled to a communication network by way of the network interface 40, which in various embodiments incorporates, for example, any combination of devices, as well as any associated software or firmware, configured to couple processor-based systems, including modems, access points, network interface cards, LAN or WAN interfaces, wireless or optical interfaces and the like, along with any associated transmission protocols, as may be desired or required by the design.

[0029] For example, the source code 12 can, in some embodiments, be contained in a remote storage communicatively interconnected to the computing system 30 by way of a communication network. In various embodiments, the communication network can include any viable combination of devices and systems capable of linking computer-based systems, such as the Internet; an intranet or extranet; a local area network (LAN); a wide area network (WAN); a direct cable connection; a private network; a public network; an Ethernet-based system; a token ring; a value-added network; a telephony-based system, including, for example, T1 or El devices; an Asynchronous Transfer Mode (ATM) network; a wired system; a wireless system; an optical system; a combination of any number of distributed processing networks or systems or the like.

[0030] The computing device 30 can be used, for example, to implement the functions of the components of the dynamic-scripting-language virtual machine of FIG. 1. In various embodiments, the computing device 30 can include, for example, a server, a controller, a router, a workstation, a mainframe computer, personal computer (PC), a note pad, a computing tablet, a personal digital assistant (PDA), a smart phone, or the like. Programming code, such as source code, object code or executable code, stored on a computer-readable medium, such as the storage 38 or a peripheral storage component coupled to the computing device 30, can be loaded into the memory 34 and executed by the processor 32 in order to perform the functions of the dynamic scripting- language virtual machine 10.

[0031] Referring now to FIG. 3, an exemplary process flow is illustrated that may be performed, for example, by the dynamic-scripting-language virtual machine 10 of FIG. 1 to implement an embodiment of the method described in this disclosure for on-demand dynamic scripting-language source-code loading. Blocks shown with dashed lines in FIG. 3 are optional items that may not be performed in all implementations. The process begins at block 50, where an object, such as a function, in the source code of an application written in a dynamic-scripting language is parsed. For example, in an embodiment, the object is parsed at run time by a code loader module of a dynamic-scripting-language virtual machine.

[0032] The object is redacted, in block 52, to remove all debugging information from the code. For example, in an embodiment, the debug information is removed when the source code is compiled into bytecode. A placeholder is loaded, or inserted, into the bytecode in memory, in block 54. For example, in an embodiment, the placeholder includes the source code file location, along with the source code file line and column numbers that delineate the beginning and end of the segment of source code corresponding to the code redacted from the bytecode memory.

[0033] In block 56, a request for debug information in the object is received from a runtime client, such as the error handling component or the reflection component of the virtual machine. The process checks, in block 58, to verify whether or not the requested debug information is currently in memory. For example, if the debug information from the object has previously been requested during program execution, and a cleanup procedure, such as garbage collection, has not been performed in the time that has intervened, then the requested debug information may still be loaded in memory. If so, the requested debug information is read from memory and returned to the requesting client.

[0034] Otherwise, if the requested debug information is not currently in memory, the corresponding source file location is retrieved, in block 60. For example, in an embodiment, the on-demand debug information loader reads the source file location in the placeholder in memory. In block 62, the object source code is re-parsed. For example, in an embodiment, the on-demand loader module asks the code loader module to reload the source code for the object, including the debug information. In block 64, the object source code is optionally recompiled, with the accompanying debug information, into bytecode.

[0035] In some embodiments, the source code for the entire application, or part of the application source code in addition to that of the immediate function, such as the source code of a calling function or a called function, is re-parsed and optionally recompiled in block 62 and block 64. In particular, parsing and compiling the source code for the whole application is required with programming languages that apply lexical scoping, for example, dynamic scripting languages that use the “upvalue” concept. Otherwise, the resulting compiled function may not include the correct instructions and variables.

[0036] For example, in the Lua programming language, the following function can be globally compiled or locally compiled with respect to function B() with differing results:

TABLE-US-00001        function A()                local a;                function B ()                       local b = a;                       print (b);                end         end

Function B() is correctly translated by globally compiling function A() before isolating function B(), as follows:

TABLE-US-00002         .local “b” ; 0         .upvalue “a” ; 0         .const “print” 0         [1] getupval 0 0 ; a         [2] getglobal 1 0 ; print         [3] move 2 0         [4] call 12 1         [5] return 0 1

However, locally compiling function B() yields an incorrect translation of function B() with different upvalue tables, as well as with different instructions, as follows:

TABLE-US-00003         .local “b” ; 0         .const “a” ; 0         .const “print” ; 0         [1] getglobal 0 0 ; a         [2] getglobal 1 1 ; print         [3] move 2 0         [4] call 1 2 1         [5] return 0 1

[0037] In block 66, the debug information relevant to the request but not included in the bytecode in memory is identified, and in block 68, the debug information is copied into the bytecode in memory.

[0038] Referring to FIG. 4, for example, the source code of a complete application written in a dynamic scripting language is compiled into a tree structure 80, in accordance with block 62 and block 64 of FIG. 3. A fake top 82 represents the entry into the application, and the bytecode corresponding to each of the functions in the application source code is represented in the tree: for example, Function A() 84, corresponding to source code lines 1-1 0; Function D() 86,corresponding to source code lines 12-20; Function B() 88,corresponding to source code lines 3-5; and Function C() 90,corresponding to source code lines 7-9.

[0039] The tree structure 80 is searched by source location, and the debug information corresponding to the relevant function for which debug information was requested in accordance with block 56 of FIG. 3 (depicted as Function B() in FIG. 4) is identified in accordance with block 66 of FIG. 3. The debug information from the counterpart function object in the compiled tree is copied into the corresponding Function B() 92 in the bytecode in memory 94, supplementing or replacing the placeholder that was included when the bytecode was initially compiled.

[0040] Referring again to FIG. 3, the requested debug information is returned to the client, in block 70, in support of execution of the application. This completes the on-demand dynamic scripting-language source-code debug information loading process.

[0041] Referring to FIG. 5, an exemplary process flow is illustrated that may be performed, for example, by the dynamic-scripting-language virtual machine 10 of FIG. 1 to implement another embodiment of the method described in this disclosure for on-demand dynamic scripting-language source-code loading. Blocks shown with dashed lines in FIG. 3 are optional items that may not be performed in all implementations. The process begins at block 100, where a function object, in the source code of an application written in a dynamic-scripting-language is parsed. For example, in an embodiment, the function is parsed at run time by a code loader module of a dynamic-scripting-language virtual machine.

[0042] The object is redacted, in block 102, to remove the function code section. For example, in an embodiment, the function code is removed when the source code is compiled into bytecode. A placeholder is loaded, or inserted, into the bytecode in memory, in block 104. For example, in an embodiment, the placeholder includes the source code file location, along with the source code file line and column numbers that delineate the beginning and end of the segment of source code corresponding to the code redacted from the bytecode memory.

[0043] In block 106, a call or query request for the function is received from a runtime client, such as the execution component of the virtual machine. The process checks, in block 108, to verify whether or not the requested function code section is currently in memory. For example, if the function has previously been requested during program execution, and a cleanup procedure, such as garbage collection, has not been performed in the time that has intervened, then the requested function code may still be loaded in memory. If so, the requested function code is read from memory and returned to the requesting client, in block 120.

[0044] Otherwise, if the requested function code is not currently in memory, the corresponding source file location is retrieved, in block 110. For example, in an embodiment, the on-demand code section loader reads the source file location in the placeholder in memory. In block 112, the function source code is re-parsed. For example, in an embodiment, the ondemand loader module asks the code loader module to reload the source code for the function object. In block 114, the object source code is optionally recompiled into bytecode.

[0045] As explained above with reference to FIGS. 3 and 4, in some embodiments the source code for the entire application, or part of the application source code in addition to that of the immediate function, such as the source code of a calling function or a called function, is reparsed and optionally recompiled in block 112 and block 114. In particular, parsing and compiling the source code for the whole application is required with programming languages that apply lexical scoping, for example, dynamic scripting languages that use the “upvalue” concept. Otherwise, the resulting compiled function may not include the correct instructions and variables, as described above.

[0046] In block 116, the code that is relevant to the request but not included in the bytecode in memory is identified, and in block 118, the complete function is copied into the bytecode in memory. In an alternative embodiment, the redacted code sections are stored in secondary storage, and the function can be copied directly from the secondary storage into the bytecode in memory. The requested function is returned to the client, in block 120, in support of execution of the application. This completes the on-demand dynamic-scripting-language source-code function loading process.

[0047] In alternative embodiments, a cleanup process can be performed after the requested function or debug information has been returned. For example, a garbage collection process can remove the section code or debug information from the bytecode in memory to again reduce the memory space required to store the bytecode.

[0048] Aspects of this disclosure are described herein with reference to flowchart illustrations or block diagrams, in which each block or any combination of blocks can be implemented by computer program instructions. The instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to effectuate a machine or article of manufacture, and when executed by the processor the instructions create means for implementing the functions, acts or events specified in each block or combination of blocks in the diagrams.

[0049] In this regard, each block in the flowchart or block diagrams may correspond to a module, segment, or portion of code that including one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functionality associated with any block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or blocks may sometimes be executed in reverse order.

[0050] A person of ordinary skill in the art will appreciate that aspects of this disclosure may be embodied as a device, system, method or computer program product. Accordingly, aspects of this disclosure, generally referred to herein as circuits, modules, components or systems, may be embodied in hardware, in software (including firmware, resident software, micro-code, etc.), or in any combination of software and hardware, including computer program products embodied in a computer-readable medium having computer-readable program code embodied thereon.

[0051] In this respect, any combination of one or more computer readable media may be utilized, including, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of these. More specific examples of computer readable storage media would include the following nonexhaustive list: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a Flash memory, a portable compact disc read-only memory (CD-ROM), an optical storage device, network-attached storage (NAS), a storage area network (SAN), magnetic tape, or any suitable combination of these. In the context of this disclosure, a computer readable storage medium may include any tangible medium that is capable of containing or storing program instructions for use by or in connection with a data processing system, apparatus, or device.

[0052] Computer program code for carrying out operations regarding aspects of this disclosure may be written in any combination of one or more programming languages, including object oriented programming languages such as Java, Smalltalk, C++, or the like, as well as conventional procedural programming languages, such as the “C,” FORTRAN, COBOL, Pascal, or the like. The program code may execute entirely on an individual personal computer, as a stand-alone software package, partly on a client computer and partly on a remote server computer, entirely on a remote server or computer, or on a cluster of distributed computer nodes. In general, a remote computer, server or cluster of distributed computer nodes may be connected to an individual (user) computer through any type of network, including a local area network (LAN), a wide area network (WAN), an Internet access point, or any combination of these.

[0053] It will be understood that various modifications may be made. For example, useful results still could be achieved if steps of the disclosed techniques were performed in a different order, and/or if components in the disclosed systems were combined in a different manner and/or replaced or supplemented by other components. Accordingly, other implementations are within the scope of the following claims.