JP5164112B2 - Source code conversion method, server system, and server program - Google Patents

Description

  The present invention relates to a source code conversion method. In particular, the present invention relates to a method of converting an HTTP request into a source code with reduced overhead when converting into a character string type variable.

Conventionally, in order to express a character string, a String class is prepared in a script development environment such as Groovy or a program development environment using a so-called high-level language such as Java (registered trademark) and C # (registered trademark). . This String class has the following two features.
Feature 1) The String class uses Unicode characters for character string representation and UTF-16 for character code encoding in order to support multiple languages.
Characteristic 2) The String class is a class that generates an Immutable object. Immutable means immutable, and an Immutable object cannot change state after generation. In the following, (registered trademark) notes are omitted for Java and C #.

  The String class can be used to analyze an HTTP request received from a client on a Web server constructed by a program written in Java or C #. Specifically, a Web server constructed by a program written in Java or C # converts an HTTP request received from a client based on the HTTP protocol into a String class and analyzes the message . Processing for converting an HTTP request into a String class in a Web server written in Java will be described with reference to FIG.

  FIG. 11 is a schematic diagram showing a process of converting an HTTP request into a String class according to the prior art. White arrows represent the flow of HTTP requests and the flow of processing. This conversion process starts when the Web server equipped with the conversion process receives an HTTP request. First, an HTTP request received from a client is generally read from kernel to a ByteBuffer object bb1. The ByteBuffer object bb1 is a ByteBuffer object generated as a variable name bb from the ByteBuffer class (java.nio.ByteBuffer in the Java language). Since the HTTP request is UTF-8 in which a character string is percent-encoded, the HTTP request read into the ByteBuffer object bb1 is UTF-8 and consumes 1 byte per character as shown in FIG. In FIG. 11, for the sake of convenience, the HTTP request read into the ByteBuffer object bb1 is represented by characters instead of the UTF-8 character code.

  Next, the HTTP request stored in the ByteBuffer object bb1 is passed to the constructor of the String class as a byte [] array encoded in UTF-8. This constructor is represented by String (bb.array (), “UTF-8”). In the constructor, the HTTP request of byte [] array is converted from UTF-8 to UTF-16. The HTTP request converted to UTF-16 is copied, and this copy is converted into a char [] array 4 and stored in the String object s2. The String object s2 is a String object generated as a variable name s from the String class (java.lang.String in the Java language). Since the char [] array 4 is UTF-16, 2 bytes are consumed per character as shown in FIG. In this way, the HTTP request received by the Web server is converted into the String class.

  By the way, in the processing when generating dynamic content by JSP (Java Server Pages) or the like, the text in the JSP is converted to UTF-16 in order to support multiple languages. Therefore, in the process of converting the HTTP request to the String class, the text in the JSP is changed from UTF-16 to UTF-8 when executing the JSP in the same way as converting the HTTP request from UTF-8 to UTF-16. It has been converted. When executing a JSP, converting the text in the JSP from UTF-16 to UTF-8 is an overhead, and a method for reducing the overhead is disclosed (Patent Document 1).

JP 2005-332146 A

  There is a problem that the following three overheads exist in the conversion process of the HTTP request to the String class described above.

  Problem a) There is an overhead due to a copy of the HTTP request stored in the ByteBuffer object. The HTTP request stored in the ByteBuffer object bb is always copied to ensure that the object generated from the String class is “immutable”, and the copied HTTP request is converted to a char [] array. This is because it is stored in the String object s.

  Problem b) There is an overhead due to the encoding conversion of the HTTP request from UTF-8 to UTF-16. The HTTP request is UTF-8 in which a character string is percent-encoded. On the other hand, the String class uses UTF-16 for character code encoding in order to support multiple languages. Therefore, it is necessary to convert the encoding of the HTTP request from UTF-8 to UTF-16.

  Problem c) There is overhead due to holding a string as UTF-16 in a String object. Since many HTTP requests are ASCII characters (0x00-0x7f), storing a character string as UTF-16 in a String object often consumes memory unnecessarily.

  These three overheads exist in the process of converting the HTTP request into the String class. Patent Document 1 describes a method of reducing overhead by converting text in JSP from UTF-16 to UTF-8. However, this can reduce only the overhead of the problem b) in the process of converting the HTTP request into the String class.

  An object of the present invention is to provide a method, a server system, and a server program for automatically converting source code into source code with reduced overhead in conversion processing of an HTTP request into a String class.

  In view of the above problems, the present invention provides the following solutions. The term “server device” described in the present specification is a device that performs processing according to information described in a character string in response to reception of the character string. For example, the character string is HTTP. In the case of a request, the server device is a Web server.

  The present invention provides a method for converting source code to reduce overhead in character string manipulation of a program. Specifically, a string type variable that directly holds a character string is referred to a buffer that stores the character string, and the character string is indirectly converted to a reference character string type variable that is converted into a reference code. A conversion method, a server system, and a server program are provided.

  According to one aspect of the present invention, a method for transcoding a program source code using a computer is provided. The code conversion method includes a step of identifying a character string type variable that holds a character string, and types the identified character string type variable into a reference character string type variable that holds a reference to a buffer that stores the character string. And a step of storing the source code obtained by converting the character string type variable into the reference character string type variable.

  According to this aspect, a character string type variable that holds a character string is converted into a source code that is type-converted to a reference character string type variable that holds a reference to a buffer that stores the character string. As a result, the character string type variable is replaced with the character string and holds a reference (pointer), so that the character string is not copied from the buffer storing the character string to the character string type variable. As a result, overhead is reduced.

  Here, the character string type variable is a variable for holding a character, for example, a java.lang.String class in the Java language and a String class in the C # language. The buffer is a storage area for temporarily storing data, here a character string, when a program is executed.

  In the aspect, the step of performing the type conversion further includes a step of determining whether or not the buffer is “Immutable”. Thereby, it is possible to have a reference character string type variable obtained by converting the character of the character string type variable being “invariant”. As a result, even if the character string is not stored in the character string type variable, the feature of “invariant” is maintained, and overhead is reduced.

  The present invention can be combined with existing technologies, and such combined technologies are also included in the technical scope of the present invention. Furthermore, the technique of the present invention provides the steps of the source code conversion method, including FPGA (field programmable gate array), ASIC (application specific integrated circuit), equivalent hardware logic elements, programmable integration. It may be provided as a program form that can be stored in the circuit or a combination thereof, that is, as a program product. Specifically, as a form of a custom LSI (Large Scale Integrated Circuit) having a data input / output, a data bus, a memory bus, a system bus, etc., an execution means, device, embedded device, etc. of the source code conversion method according to the present invention are provided. The form of a program product that can be provided and stored in such an integrated circuit is also within the scope of the present invention.

  According to the present invention, it is possible to provide a method, a server system, and a server program for automatically converting source code into source code with reduced overhead in the process of converting an HTTP request into a String class. Moreover, the time required for the conversion process of the HTTP request to the String class can be shortened by the source code with reduced overhead.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. These are merely examples, and the technical scope of the present invention is not limited thereto. Hereinafter, a case where the character string is an HTTP request will be described. Note that the character string is not limited to an HTTP request, but is converted to a character string type variable, and may be a character string of US-ASCII characters.

  In one embodiment of the present invention, source code including a description of processing for converting an HTTP request into a String class (hereinafter referred to as conversion processing for simplification) described in an arbitrary program written by a user, A), b), and c), which are problems in the present invention, are automatically converted into source code with three overheads reduced. Specifically, in order to convert the source code to reduce the three overheads in the conversion process, satisfy the conditions that can be converted to the source code using the new constructor of the String class String (java.nio.ByteBuffer bb) Judgment is made. If the condition is satisfied as a result of the determination, use the constructor of the String class (reference string type variable) that newly created String (java.nio.ByteBuffer bb) for the source code of the program created by the programmer. Convert to the source code that was.

  First, String (java.nio.ByteBuffer bb) will be described. String (java.nio.ByteBuffer bb) is newly added to the constructor of the String class. Unlike the conventional String class, this String class has the following characteristics. In order to distinguish the following, the constructor in which String (java.nio.ByteBuffer bb) is newly established in the constructor is called the String (ByteBuffer) constructor.

Characteristic 1) When only ASCII characters are included in the ByteBuffer object bb (buffer), hold the string of the String object s, hold the pointer to the ByteBuffer object bb without holding the string in the String object s It is realized by doing.
Feature 2) When the String object s holds a pointer to the ByteBuffer object bb, when retrieving the character via the String class method, the necessary 8-bit character is read from the ByteBuffer object bb pointed to by the pointer. , 00 is added to the upper 8 bits, converted to char, and a value is returned. Detailed processing will be described later.
Feature 3) When String object s holds a pointer to ByteBuffer object bb, the character string held for ASCII characters and the character string held in ByteBuffer object bb are both UTF-8. Are the same encoding. For this reason, encoding conversion using String.getBytes (“UTF-8”), which has been conventionally performed when acquiring a character string from a String object s as a byte [] array, is not performed.

  Since the HTTP request is UTF-8 in which a character string is percent-encoded, the HTTP request stored in the ByteBuffer object bb is always a US-ASCII character. By utilizing the fact, by using the String (ByteBuffer) constructor, conversion from UTF-8 to UTF-16 when generating String objects s can be eliminated, and the problem of b) of the present invention is Overhead can be reduced. In addition, by using the String (ByteBuffer) constructor, the String object s can hold a pointer to the input ByteBuffer object bb. As a result, it is possible to eliminate storing character strings using UTF-16, so that the overhead mentioned in the problem c) can be reduced.

  There is a condition in the source code that can use the String (ByteBuffer) constructor described above. Therefore, it is necessary to check whether the source code created by the programmer can be converted into source code using the String (ByteBuffer) constructor. In order to be able to change, the condition is that the content of the ByteBuffer object bb is not changed after the HTTP request is written to the ByteBuffer object bb, that is, the ByteBuffer object bb is “invariant”. Whether or not this condition is satisfied can be determined by the following two methods.

Method 1) Perform syntax analysis using a compiler tool. The analysis algorithm will be described later.
Method 2) The programmer explicitly guarantees by annotation or the like.

  The String (ByteBuffer) constructor is only used when the ByteBuffer object bb in which the HTTP request is stored can be guaranteed by the above two methods that the ByteBuffer object bb is “invariant” in the interval where the String object s is used. To automatically convert to the source code that generates String objects s. It should be ensured that the ByteBuffer object bb is “invariant” by at least one of the two methods described above.

  By ensuring that the ByteBuffer object bb is “immutable” by the above method, it is guaranteed that the String class is “immutable”. As a result, it is possible to eliminate the need to copy to the char [] array in the instance of the String class to ensure that the object generated from the String class is "immutable". Overhead can be reduced.

  By generating a String object s using the String class in which String (java.nio.ByteBuffer bb) is newly added to the constructor in the source code where it is guaranteed that the ByteBuffer object bb is "immutable", issue a B) The overhead mentioned in c) can be reduced.

  FIG. 1 is a schematic diagram showing processing for converting an HTTP request into a String class according to an embodiment of the present invention. The conversion process shown in FIG. 1 is a conversion process by source code using the above-described String (ByteBuffer) constructor. White arrows represent the flow of HTTP requests and the flow of processing. The conversion process starts in response to the Web server having the conversion process receiving an HTTP request. First, the HTTP request received from the client is read from kernel to the ByteBuffer object bb1. This process is the same as that of the prior art shown in FIG.

  Next, the ByteBuffer object bb1 is passed to the String (ByteBuffer) constructor of the String class. The String object s created by the String (ByteBuffer) constructor stores a pointer 3 to the ByteBuffer object bb1. By doing so, the HTTP request is not converted from UTF-8 to UTF-16, copied to the char [] array in the String object s, and the HTTP request is sent to the String object s as UTF-16. There is no holding. That is, it is possible to solve the problems a), b), c) and three overheads, which are problems in the present invention.

Next, the conversion process whose outline is shown in FIG. 1 will be described using a flowchart. First, the flowchart of the conversion process according to the prior art, which is schematically shown in FIG. FIG. 12 is a flowchart of a process for converting an HTTP request into a String class according to the related art.
S10: The HTTP request received from the client by the Web server is read into the ByteBuffer object bb from the kernel of the Web server.
S20: bb.array () that returns the contents of the ByteBuffer object bb as a byte [] array is executed, and the HTTP request stored in the ByteBuffer object bb is converted into a byte [] array.

S30: The constructor of the String class is called with the HTTP request converted into the byte [] array in step S20 and UTF-8 as the format to be encoded as arguments.
S40: The HTTP request of the ByteBuffer object bb converted into the byte [] array is converted from UTF-8 to UTF-16 by the constructor of the String class called in step S30.
S50: The HTTP request converted into UTF-16 in step S40 is copied, and this copy is converted into a char [] array and held in the String object s.

Then, the flowchart of the conversion process which concerns on one Embodiment of this invention is shown. FIG. 2 is a flowchart of processing for converting an HTTP request into a String class according to an embodiment of the present invention.
S100: The HTTP request is read from the kernel of the Web server into the ByteBuffer object bb. This process is the same as step S10 in FIG.
S110: Call String (ByteBuffer) constructor of String class with ByteBuffer object bb as an argument.
S120: It is determined whether the HTTP request stored in the ByteBuffer object bb is only ASCII characters. If the determination result is YES, the process proceeds to step S130. On the other hand, if the determination result is NO, the process moves to step S20 in FIG. 1 to perform the conversion process according to the conventional technique shown in FIG.
S130: A pointer to the ByteBuffer object bb is acquired and held in the String object s.

  Subsequently, the source code including the description of the conversion processing according to the prior art shown in FIGS. 11 and 12 created by the programmer is described as the description of the conversion processing according to the embodiment of the present invention shown in FIGS. An algorithm for automatically converting to the included source code will be described. By converting the source code created by the programmer into the source code including the description of the conversion process shown in FIGS. 1 and 2, the source code can be reduced in the overheads mentioned in the problems a), b) and c).

  FIG. 3 is a flowchart illustrating an algorithm for converting source code to reduce overhead according to an embodiment of the present invention. This algorithm operates as follows when there is a description specifying the ByteBuffer object bb that holds the HTTP request in the source code written by the programmer. As a method for specifying the ByteBuffer object bb, there are methods such as describing in a program or giving from a configuration file from the outside. This algorithm is provided in the compiler and executed by the compiler. The source code generated by this algorithm for reducing overhead is stored in a storage means such as a hard disk. Instead of the source code for reducing overhead, object code (format executable on a computer) generated as a result of compiling the source code for reducing overhead by a compiler may be stored in the storage means.

  S200: It is determined whether the condition for guaranteeing that the ByteBuffer object bb is “invariant” is satisfied. If the condition for guaranteeing that the ByteBuffer object bb is “invariant” is not satisfied, the process ends. If satisfied, the process proceeds to step S210. The conditions for ensuring that the ByteBuffer object bb is “invariant” will be described later. As described above, in one embodiment of the present invention, the HTTP request can be referred to by holding a pointer to the ByteBuffer object bb storing the HTTP request in the String object s. Therefore, in order to satisfy the condition that the String class is “immutable”, the ByteBuffer object bb must be “immutable”.

  S210: Variables for substituting a String object for storing the converted character string in UTF-16 using the return value (b) of bb.array () and UTF-8 as the format to be encoded as arguments. It is determined whether or not an assignment statement “s = new String (b,“ UTF-8 ”)” with the assignment destination is detected. Here, the variable s is a String object, which is the same as the String object s described above. If the assignment statement can be detected, the process proceeds to step S220. If the assignment statement cannot be detected, the process ends.

S220: Immediately after “s = new String (b,“ UTF-8 ”)” detected in step S210, an assignment statement “s = new String (bb)” is generated.
S230: “s = new String (b,“ UTF-8 ”)” detected in step S210 is deleted.
S240: Delete an assignment statement related to a variable that is not used in the program from among the arguments of “s = new String (b,“ UTF-8 ”)” deleted in step S230.

  The conditions for guaranteeing that the ByteBuffer object bb is “invariant” will be described. Here, among the methods for ensuring that the ByteBuffer object bb is “invariant”, conditions in the method of performing analysis by the compiler tool of method 1) will be described. For the ByteBuffer object bb in which an HTTP request is stored, which is described in the program by the user, the compiler tool has the following five types within the range from the generation of the value of the ByteBuffer object bb in the method until it is no longer used. Analyze whether all the conditions are met.

  If all of these five conditions are satisfied, the value is not rewritten until the use ends after the value (HTTP request) is written to the ByteBuffer object bb by SocketChannel.read (). Therefore, by keeping the pointer to the ByteBuffer object bb passed to the constructor in the String object s, “invariance” of the String object is guaranteed even if the String object does not hold the character string.

Condition 1) ByteBuffer object bb is not assigned to an instance variable or class variable.
Condition 2) ByteBuffer object bb is not the return value of the method.
Condition 3) The ByteBuffer object bb is not an argument of a method call other than the SocketChannel.read (ByteBuffer) method.
Condition 4) ByteBuffer object bb does not appear on the left side after being referenced by SocketChannel.read (ByteBuffer).
Condition 5) The bb.put () and bb.put * () methods are not called after the ByteBuffer object bb is referenced in SocketChannel.read (ByteBuffer).

  If the ByteBuffer object bb does not appear on the left side as shown in condition 4), it means that the contents of the ByteBuffer object bb cannot be rewritten. In addition, when the ByteBuffer object bb appears on the left side, the portion immediately before that may be the analysis target. Further, bb.put * () shown in condition 5) means a method starting from put such as bb.putChar (int index, char value). The bb.put () and bb.put * () methods are not called, that is, the method that rewrites the contents of the ByteBuffer object bb is not called, and the contents of the ByteBuffer object bb cannot be rewritten. Show.

  Note that when the ByteBuffer object bb uses Object Pooling, the range from when the method for retrieving the ByteBuffer object bb from the Pool to the method for returning to the Pool is called becomes the analysis target. These two methods are assumed to be known as the compiler tool based on the Object Pooling specification used in the program. Here, Object Pooling is to store the generated objects in the pool (Pool), take out the objects from the pool when they are needed, and return the objects to the pool when they are no longer needed. It is. Using Object Pooling has the advantage that it is faster than the method of creating an object each time it is used.

  In addition, when the ByteBuffer object bb uses Object Pooling, it cannot be guaranteed that the String object is “invariant” by static analysis of the source code according to the above conditions 1) to 5). Introduce a Copy-On-Write mechanism that creates a new ByteBuffer object that retains the contents when the ByteBuffer class is written, and guarantees the "invariance" of the String object. However, it is necessary to introduce the Copy-On-Write mechanism to guarantee the “invariance” of the String object when the ByteBuffer object bb is returned to the pool within the interval in which the String object is used.

  Here, the Copy-On-Write mechanism means that when a copy of an object is requested, the copy is pretending to be referred to as it is and the original or copy is written. This is a technology that detects this, searches for and allocates a new free area for the first time, and executes copying.

  Each means in the server system for code conversion will be described with reference to the flowchart shown in FIG. The identifying means detects the assignment statement “s = new String (b,“ UTF-8 ”)” in step S210 of FIG. 3, that is, the variable (s) that substitutes the String object from the source code. Perform the process. The conversion means performs the processing of steps S220 and S230 of FIG. 3, that is, the assignment statement “s = new String (b,“ UTF-8 ”)” detected by the specifying means, and the assignment statement “s = new String (bb ) ". The storage means stores the source code converted into the assignment statement “s = new String (bb)” by the conversion means in a storage means such as a hard disk.

  Here, the String class method when the String object s holds a pointer to the ByteBuffer object bb, which is one of the features of the String class that newly created String (java.nio.ByteBuffer bb) in the constructor, A process for extracting characters via the network will be described. FIG. 4 is a flowchart of character acquisition processing in the String object s that holds a pointer to the ByteBuffer object bb according to an embodiment of the present invention.

S300: It is determined whether a pointer to the ByteBuffer object bb is held in the String object s. If the pointer is held, the process proceeds to step S310. If the pointer is not held, the char [] array is held in the String object s, so the char [] array is acquired and returned. Returns as a value.
S310: A necessary 8-bit character is read from the ByteBuffer object bb indicated by the pointer held in the String object s.
S320: 00 is added to the upper 8 bits of the 8-bit character read in step S310 to convert it into a char [] array.
S330: The char [] array converted in step S320 is returned as a return value.

  In this way, when the String object s holds a pointer to the ByteBuffer object bb, a character can be extracted from the ByteBuffer object bb.

  FIG. 5 is a diagram showing the implementation of the String class according to an embodiment of the present invention. Details of the implementation of the present invention will be described with reference to FIG. First, an example of the String class in which String (java.nio.ByteBuffer bb) is newly established in the constructor is shown using the java.lang.String class of Java language. In Fig. 5, the fields used inside the java.lang.String class, the java.lang.String class constructor (String (ByteBuffer) constructor) that sets a string as a representative method, and the java.lang.String The charAt () method for extracting one character from a character string, and the getBytes () method for copying a java.lang.String character string to the prepared byte [] array are shown.

  The String (ByteBuffer) constructor 10 checks the character string pointed to by the input ByteBuffer object bb. If a character of 0x80 or more is included, the character string is held in a normal UTF-16 representation. In other cases, the input ByteBuffer object bb is retained. In the charAt () method 11, when the ByteBuffer object bb is held as it is, the necessary 8-bit character is read from the ByteBuffer object bb, 00 is added to the upper 8 bits, and the value is converted to char. In the getBytes () method 12, when the ByteBuffer object bb is held as it is, the character string pointed to by the ByteBuffer object bb is UTF-8, so it is copied to the byte [] array as it is.

  Next, Copy-On-Write will be described using an example of java.nio.ByteBuffer class of Java language. An sref field of the SoftReference class is added to the ByteBuffer class indicating whether Copy-on-write is necessary when a method for changing the contents of the buffer held by the ByteBuffer object is called. Here, the buffer refers to a storage area in which data is temporarily stored in order to compensate for a difference in processing speed or transfer speed when exchanging data when the program is executed.

  First, when it is determined that the data is held in the byte [] array in String (ByteBuffer bb, int, int), the value obtained by bb.duplicate () is stored in the String class as value13. Then, a new soft reference (SoftReference) referring to the value 13 is created and assigned to bb.sref. When the contents of the buffer held by the ByteBuffer object are changed, this bb.sref is used to determine whether Copy-on-write is necessary. Specifically, the following processing is performed by a method (for example, put () method) that changes the contents of the buffer held by the ByteBuffer object.

1) If bb.sref = null, the String object does not refer to the contents of the buffer held by the ByteBuffer object, so normal processing is performed.
2) If bb.sref.get () = null, the String object has already been garbage collected (GC) and normal processing is performed. Here, garbage collection (GC) is a function of automatically releasing an unnecessary area among memory areas dynamically allocated by a program.
3) bb.sref.get ()! If = null, a new buffer is secured and the contents of the previous buffer are copied.

  FIG. 6 is a diagram showing an overview of the operation of Copy-on-write when String is GC before the contents of the buffer held by the ByteBuffer object are changed according to an embodiment of the present invention. FIG. 6A shows a relationship diagram between the ByteBuffer object and the buffer. When data is held in a byte [] array in String (ByteBuffer bb), the contents of the buffer 200 referred to by the ByteBuffer object bb100 are used as the value of the character string. Here, the buffer 200 is a byte [] array used internally by the ByteBuffer object bb100 in order to hold data read from the kernel to the ByteBuffer object bb100.

  FIG. 6B shows a relationship diagram of String objects that refer to the contents of the buffer 200. In order to refer to the contents of the buffer 200 in String (ByteBuffer bb), the value of bb.duplicate () is stored in the String object s. Then, SoftReference 110 that refers to the value obtained by bb.duplicate () is created and assigned to bb.sref. Specifically, the ByteBuffer object bb100 is shallow copied, a ByteBuffer object s_bb101 is created, and the String object s120 is referred to the ByteBuffer object s_bb101. Thereby, the String object s120 can use the contents of the buffer 200 referred to by the ByteBuffer object s_bb101 as the value of the character string. After making the String object s120 refer to the ByteBuffer object s_bb101, a SoftReference 110 that refers to the ByteBuffer object s_bb101 is created. By SoftReference 110, the ByteBuffer object bb100 and the ByteBuffer object s_bb101 can be associated with each other.

  FIG. 6C is a relationship diagram when the String object s120 is GC before the String object s120 is changed. When the String object s120 is GC, the value of the SoftReference 110 becomes null. At this time, since the buffer 200 is not referenced from the String object s120, the contents of the buffer 200 can be changed.

  FIG. 7 is a diagram showing an overview of copy-on-write operation when the contents of a buffer are changed before the String object is GCed according to an embodiment of the present invention. 7A and 7B are the same as FIG. FIG. 7C is a relationship diagram when the contents of the buffer 200 are changed before the String object s120 is GCed. If the value of the SoftReference 110 is not null, the String object s120 is not GC, and therefore, if the contents of the buffer 200 are changed, the “invariant” of the String object s120 cannot be maintained. Therefore, the contents of the buffer 200 are copied using a copy-on-write mechanism. The copied buffer 201 is held by the ByteBuffer object bb100, and the SoftReference 110 with the ByteBuffer object s_bb101 disappears. In this way, the “invariant” of the String class is retained.

  Finally, an application example of one embodiment of the present invention will be described. FIG. 8 shows an example of a simple server source code. The simple server source code processing shown in FIG. 8 will be described. When the HTTP request data is read from the 80th port to the ByteBuffer object bb, the procedure starts. First, the HTTP request read into the ByteBuffer object bb is converted from UTF-8 to UTF-16, and String objects s that hold the HTTP request converted to UTF-16 are generated. Next, the percent encoding of the HTTP request converted into UTF-16 held by the generated String object s is decoded. Finally, the decoded HTTP request is written to the standard output, and the process ends.

  First, the programmer finds a description specifying the ByteBuffer object bb of “ByteBuffer bb = ByteBuffer.allocateDirect (8192);”. Next, it is checked whether the ByteBuffer object bb is not rewritten and the above-mentioned conditions are satisfied. The ByteBuffer object bb in the source code shown in Fig. 8 is an argument only in the SocketChannel.read () method that only calls the bb.array () method, is not assigned to an instance variable / class variable. Since the value is not returned by the method, the value will not be rewritten after bb is written by the SocketChannel.read () method. Therefore, since bb can be passed to the new String (ByteBuffer) constructor according to an embodiment of the present invention, the server source code is a problem in the present invention a) b) c) Source code that reduces three overheads Can be converted to

  The server source code shown in FIG. 8 can be rewritten as shown in FIG. 9 according to the algorithm shown in FIG. 3, and the overheads a), b), and c) in the conversion process can be reduced. Since the String (ByteBuffer) constructor is non-public in order to satisfy the specifications of the Java language, it is actually necessary to call the String (ByteBuffer) constructor using reflection or the like.

  The present invention performs conversion processing according to an embodiment of the present invention when the contents of the buffer expressed by the program as String are only one that can be expressed by 1 byte, and in other cases, conversion processing according to the prior art Is to do. For this reason, when there is data that cannot be expressed in percent encoding, conversion processing is performed by the conventional technique. If an invalid character (for example, 0xff) as a URI (Uniform Resource Identifier) that cannot be expressed in percent encoding is present in the buffer storing the HTTP request specified by the user, as shown in FIG. bb, int start, int length) method `` value = StringCoding.decode (bb.array (), start, length); '' is executed, a String object is generated by the conversion processing according to the prior art, and the contents of the buffer are changed The same String object is obtained without losing the result of applying the present invention.

  Further, even when the message body (rfc2616) is present in the HTTP message by a POST command or the like, for example, when 0xff exists in the buffer storing the HTTP request specified by the user, as shown in FIG. `` Value = StringCoding.decode (bb.array (), start, length); '' of the (ByteBufferbb, int start, int length) method is executed, a String object is generated by the conversion processing according to the conventional technology, and the buffer contents The same String object as the result of not applying the present invention without losing is obtained.

  FIG. 10 is a diagram illustrating a hardware configuration of a server device that converts to source code that reduces overhead according to an embodiment of the present invention. In FIG. 10, an information processing apparatus 1000 is used as an apparatus that converts source code to reduce overhead, and the hardware configuration thereof is illustrated. In the following, an overall configuration of an information processing apparatus typified by a computer will be described, but it goes without saying that the minimum required configuration can be selected according to the environment.

  The information processing apparatus 1000 includes a CPU (Central Processing Unit) 1010, a bus line 1005, a communication I / F 1040, a main memory 1050, a BIOS (Basic Input Output System) 1060, a parallel port 1080, a USB port 1090, a graphic controller 1020, and a VRAM 1024. , An audio processor 1030, an I / O controller 1070, and input means such as a keyboard and mouse adapter 1100. Storage means such as a flexible disk (FD) drive 1072, a hard disk 1074, an optical disk drive 1076, and a semiconductor memory 1078 can be connected to the I / O controller 1070.

  A microphone 1036, an amplifier circuit 1032, and a speaker 1034 are connected to the audio processor 1030. A display device 1022 is connected to the graphic controller 1020.

  The BIOS 1060 stores a boot program executed by the CPU 1010 when the information processing apparatus 1000 is activated, a program depending on the hardware of the information processing apparatus 1000, and the like. An FD (flexible disk) drive 1072 reads a program or data from the flexible disk 1071 and provides it to the main memory 1050 or the hard disk 1074 via the I / O controller 1070. FIG. 10 shows an example in which the information processing apparatus 1000 includes a hard disk 1074. However, an external device connection interface (not shown) is connected to the bus line 1005 or the I / O controller 1070, and the information processing apparatus A hard disk may be connected or added to the outside of 1000.

  As the optical disk drive 1076, for example, a DVD-ROM drive, a CD-ROM drive, a DVD-RAM drive, or a CD-RAM drive can be used. In this case, it is necessary to use the optical disk 1077 corresponding to each drive. The optical disk drive 1076 can also read a program or data from the optical disk 1077 and provide it to the main memory 1050 or the hard disk 1074 via the I / O controller 1070.

  The computer program provided to the information processing apparatus 1000 is stored in a recording medium such as the flexible disk 1071, the optical disk 1077, or a memory card and provided by the user. The computer program is read from the recording medium via the I / O controller 1070 or downloaded via the communication I / F 1040 to be installed and executed in the information processing apparatus 1000. The operation that the computer program causes the information processing apparatus to perform is the same as the operation in the apparatus that has already been described.

  The aforementioned computer program may be stored in an external storage medium. As the storage medium, in addition to the flexible disk 1071, the optical disk 1077, or the memory card, a magneto-optical recording medium such as MD or a tape medium can be used. In addition, a storage device such as a hard disk or an optical disk library provided in a server system connected to a dedicated communication line or the Internet may be used as a recording medium, and a computer program may be provided to the information processing apparatus 1000 via the communication line. .

  In the above example, the information processing apparatus 1000 has been mainly described. However, the information described above is obtained by installing a program having the function described in the information processing apparatus in a computer and causing the computer to operate as the information processing apparatus. Functions similar to those of the processing device can be realized.

  The apparatus can be implemented as hardware, software, or a combination of hardware and software. A typical example of implementation using a combination of hardware and software is implementation on a computer system having a predetermined program. In such a case, the predetermined program is loaded into the computer system and executed, whereby the program causes the computer system to execute the processing according to the present invention. This program is composed of a group of instructions that can be expressed in any language, code, or notation. Such instructions may be either or both of the system directly performing a specific function, or (1) conversion to another language, code, or notation, and (2) copying to another medium. Can be executed after the Of course, the present invention includes not only such a program itself but also a program product including a medium on which the program is recorded. The program for executing the functions of the present invention can be stored in any computer-readable medium such as a flexible disk, MO, CD-ROM, DVD, hard disk device, ROM, MRAM, and RAM. Such a program can be downloaded from another computer system connected via a communication line or copied from another medium for storage in a computer-readable medium. Further, such a program can be compressed or divided into a plurality of parts and stored in a single or a plurality of recording media.

  Although the present invention has been described based on the embodiment, the present invention is not limited to the above-described embodiment. The effects described in the embodiments of the present invention are only the most preferable effects resulting from the present invention, and the effects of the present invention are limited to those described in the embodiments or examples of the present invention. Is not to be done.

It is a schematic diagram which shows the conversion process to the String class of the HTTP request based on one Embodiment of this invention. It is a flowchart of the conversion process to the String class of the HTTP request based on one Embodiment of this invention. It is a flowchart which shows the algorithm which converts into the source code which reduces overhead according to one Embodiment of this invention. It is a flowchart of the character acquisition process in the String object s holding a pointer to the ByteBuffer object bb according to an embodiment of the present invention. It is a figure which shows implementation of the String class based on one Embodiment of this invention. It is a figure which shows the operation | movement outline | summary of Copy-On-Write when String is GC before the content of the buffer which ByteBuffer object hold | maintains changes based on one Embodiment of this invention. It is a figure which shows the operation | movement outline | summary of Copy-On-Write when the content of a buffer is changed before String object is GC according to one Embodiment of this invention. It is a figure which shows the server program example. It is a figure which shows the server program example converted into the source code which reduces an overhead. It is a figure which shows the hardware constitutions of the server apparatus converted into the source code which reduces overhead based on one Embodiment of this invention. It is a schematic diagram which shows the conversion process to the String class of the HTTP request based on a prior art. It is a flowchart of the conversion process to the String class of the HTTP request based on a prior art.

Explanation of symbols

1 ByteBuffer object bb
2 String objects
3 Pointer 4 char [] array

Claims (9)

A method of transcoding a program source code using a computer,
Identifying a string variable that holds the string;
Converting the identified string type variable into a reference string type variable that holds a reference to a buffer that stores the string; and
Storing the source code obtained by converting the character string type variable into the reference character string type variable;
Including transcoding.   The method of claim 1, wherein the step of converting further comprises determining whether the buffer is immutable.   The method according to claim 2, wherein in the determining step, a compiler determines based on information obtained by parsing the source code. The step of converting the type further includes:
If the determination is true, perform type conversion to the reference string type variable,
3. The method of claim 2, wherein otherwise no type conversion to the reference string type variable is performed. The reference character string type variable holds a reference to a buffer for storing the character string when the character string is an ASCII character string.
Otherwise, the method of claim 1, wherein the string is retained.   The method of claim 1, wherein the string is an HTTP request. A server program for converting the source code of a program for changing the expression of the character string received in response to reception of the character string using a server device,
A computer identifying a string variable holding the string;
Converting the identified string type variable into a reference string type variable that holds a reference to a buffer that stores the string; and
Storing the source code obtained by converting the character string type variable into the reference character string type variable;
A server program that executes A server system for transcoding a source code of a program for changing the expression of the received character string in response to reception of the character string;
A specifying means for specifying a character string type variable that holds the character string;
Conversion means for converting the identified character string type variable into a reference character string type variable that holds a reference to a buffer that stores the character string;
Storage means for storing the source code obtained by converting the character string type variable into the reference character string type variable;
Including server system. A server program for transcoding a source code of a program for changing the expression of the received HTTP request in response to reception of an HTTP request using a server device,
A computer identifying a string variable holding the HTTP request;
Converting the identified string type variable into a reference string type variable that holds a reference to a buffer that stores the HTTP request; and
Storing the source code obtained by converting the character string type variable into the reference character string type variable,
Further comprising determining whether the buffer is immutable;
If the determination is true, perform type conversion to the reference string type variable,
Otherwise, do not perform type conversion to the reference string type variable,
The reference character string type variable is a server program that holds the HTTP request when the HTTP request is not an ASCII character string.

Images