Abstract:
A method of compiling byte code into native code disclosed together with a server ( 100 ) and a receiving terminal ( 101 ) for the same. The method comprises the steps of transmitting byte code files containing byte code from a server to a receiving terminal; transmitting grouping information relating to the grouping of byte code files to the receiving terminal; and compiling byte code files received at the receiving terminal to native code. The byte code files are selected for compilation as a function of the grouping of byte code files.

Description:
FIELD OF INVENTION 
     This invention relates to a method of compiling byte code into native code and in particular where the byte code is contained in byte code files transmitted from a server to a receiving terminal for subsequent compilation. 
     BACKGROUND TO INVENTION 
     Digital Video Broadcasting (DVB) is an organization which undertakes standardization activities in the field of digital broadcasting (see http://www.dvb.org). DVB&#39;s Multimedia Home Platform (MHP) standard (ETSI reference TS 101 812, version 1.1.1, blue book reference A057 05/00) is a series of measures designed to promote the harmonized transition from analogue television (TV) to a digital interactive multimedia future. In particular, the MHP defines a generic, i.e. hardware independent, interface between interactive digital applications and the terminals on which those applications execute. This enables digital content providers to address all types of terminals ranging from low-end to high-end set top boxes, integrated digital TV sets and multimedia PCs. The MHP supports many kinds of applications including the following examples: electronic program guides, information services (enhanced teletext, news and stock tickers etc.), applications synchronized to TV content, gaming and e-commerce. 
     The DVB MHP standard and its composite elements are known and well documented, and therefore only those elements which relate to the present invention are elaborated upon hereafter. 
     Digital Storage Media Command and Control (DSM-CC) is employed in DVB&#39;s MHP as a toolkit for developing control channels associated with MPEG-1 and MPEG-2 streams. Principally defined in part 6 of the MPEG-2 standard (Extensions for DSM-CC), it enables amongst other things broadcast carousels to be defined. Such carousels are mechanisms for assembling data sets into a buffer which are played-out in a cyclic manner, i.e. broadcast periodically. For example, such a carousel may be used to broadcast all the application files including Java class files, textual information and graphical data required for the receiver to execute MHP applications. 
     The DSM-CC Object Carousel is used not only in DVB&#39;s MHP but also in some digital terrestrial television broadcasts including, for example, ONdigital, BBC TV and Channel 4 digital broadcasts in the UK. 
     MHP is based around a platform known as DVB-J and includes a virtual machine as defined in the Java Virtual Machine (JVM) specification from Sun Microsystems. Java provides a means of producing hardware independent, executable “byte code” which is executed on a JVM. Different hardware platforms can have different JVM implementations but all will execute the same byte code. This is ideal for broadcast environments such as digital TV, where applications can be written, compiled and broadcast to a variety of different set-top boxes or integrated digital TVs. 
     Java source code is compiled with a Java compiler into byte code and stored in class files, which can be executed by a JVM. With DVB&#39;s MHP, Java application class files are broadcast to a receiver using DSM-CC which may prescribe a corresponding file structure which can then be replicated to store or cache the class files at the receiver. In addition, the DSM-CC may be used to defining modules comprising groups of related Java class files and other files for broadcast. 
     In the first JVM implementations, the byte code was interpreted however modern JVMs compile the byte code into faster executing, native instructions. Such compilation may typically occur in any of the following ways: 
     Just in Time (JIT) 
     This is where byte code is compiled to native code either when a class file is loaded or a method (a section of byte code which performs a certain function) within a class file is executed. A disadvantage of JIT implementations is that the JVM must spend an amount of time compiling a class or method when it is first accessed. During this time the JVM waits until the compilation is completed, pausing the execution of the Java application. Typically the more optimization that is performed by the compiler the larger the latency, but the faster the native code will run. 
     Runtime Analysis 
     These are based on an interpreted JVM. The JVM takes measurements at runtime and assesses which classes or methods would produce the best performance gain if they were compiled. This could include measuring the number of times a class or method is used and the amount of time spent executing byte code from that class or method. Once identified these can be compiled in the foreground (introducing latency) or compiled in the background, using otherwise wasted processor time. JVMs using this technology have less latency when new class files are loaded or previously unused methods are executed than JIT implementations, but run at a slower speed since some interpretation is always performed. The storage of runtime information has a small overhead on the execution speed. This technique requires both a byte code interpreter and a byte code to native code compiler. 
     Ahead of Time (AOT) 
     The byte code is processed after compilation and a new class file is produced. The new class file contains native implementations of methods. The JVM recognizes these native implementations and uses them instead of byte code. Typically better optimizations can be performed by AOT time compilation than JIT since compile time does not hold up the execution of the Java application. The native code is specific to a single processor, thus AOT compilation is not well suited to a broadcast environment since there is likely to be wide range of processors used by different receiver manufacturers. 
     OBJECT OF INVENTION 
     It is an object of the invention to provide an alternative and efficient method of compiling byte code contained in byte code files transmitted from a server to a receiving terminal into native code. 
     SUMMARY OF INVENTION 
     According to the present invention, such a method comprising the steps of transmitting byte code files containing byte code from a server to a receiving terminal, e.g. using a broadcast carousel; transmitting grouping information relating to the grouping of byte code files to the receiving terminal; and compiling byte code files received at the receiving terminal to native code, wherein the byte code files are selected for compilation as a function of the grouping of byte code files. After compilation, the byte code files may be cached in a memory for subsequent execution. 
     The method of the present invention enables selected byte code to be compiled ahead of time whilst still retaining platform independence, and without the latency associated with JIT compilation or run-time analysis. 
     The grouping information may relate to the grouping of the byte code files for transmission; the directory structure of the byte code files as stored at the server; or the directory structure to be used to store the byte code files at the receiving terminal. 
     In the case of the first option, the byte code files may be selected for compilation upon either the interpretation, compilation or execution of other byte code files transmitted in the same group. For example, such grouping information may be described using DSM-CC protocols of the DVB&#39;s MHP standard. 
     In the case of the later two options, a single group would typically relate to a single directory such that byte code files may then be selected for compilation upon the interpretation, compilation or execution of other byte code files residing in the same directory. 
     Again in the case of the later two options, the grouping information may comprise file locations appended to the file name of each respective byte code file, i.e. a new use of information which is conventionally already broadcast. 
     Further provided in accordance with the present invention is a server as claimed in claims  14  to  18  and receiving terminal as claimed in claims  19  to  27 . 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
       The present invention will now be described, by way of example only, with reference to the accompanying schematic figures in which: 
         FIG. 1  shows a TV broadcasting system and corresponding receiving system configured in accordance with the present invention; 
         FIGS. 2 and 3  shows respective directory and module grouping structure of Java class files and other related files as utilized by the broadcasting system of  FIG. 1 . 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  shows a TV broadcasting system  100  adapted to transmit TV audio and video data together with ancillary application data to a corresponding receiving system  101  in accordance with the DVB&#39;s MHP standard. For example, the TV broadcasting system may be a satellite broadcasting system belonging to a commercial satellite broadcaster and the receiving system may be one of many corresponding combinations of a satellite receiving dish and a set-top box for processing the received data for display on a TV  116 . Equally, the broadcasting system and corresponding receiving system could be terrestrially based. In either case, the design, manufacturing and operation of such systems are well known and those parts which do not relate to the present invention will not be elaborated upon here further. 
     Through audio  105 , video  104  and data  106  inputs, the broadcasting system  100  is fed audio and video data steams from storage media  102  containing pre-recorded audio and video TV content and an application data stream from a computer  103  comprising Java class files and related graphics files. The application data is for providing an enhanced data/teletext service (not shown) which includes ancillary information associated with the audio and video content, and through which information the user can navigate whilst the audio and video data is displayed at the same time. 
     The audio, video and data streams are multiplexed in a multiplexer  107  before being broadcasted using a transmitter  108  over a single channel to corresponding receiving systems. In the receiving system shown, the incoming transmissions are receiver by a receiver  109 , demultiplexed in a demultiplexer  110  and audio, video and application data streams are outputted through respective audio  112 , video  111  and data  113  outputs. Display data derived from the application data is then feed with the audio and video data in to a TV signal processing unit  115  from which a corresponding TV signal is outputted for display on a TV  116 . 
     The Java class files of the application data may be provided for, amongst other things, generating windows in which to display the ancillary information associated with the audio and video content, and associated graphics files may be provided for aesthetics including for displaying decorative framing windows and menu navigation options. An example of such an enhanced data/teletext service might be where the audio and video content represents a performing pop group and the application data provides a data/teletext service with a web style interface to be displayed in a window over part of the audio and video display, and in which fans of the pop group may peruse pages of information details forthcoming concerts, gossip and the like. 
     Certain Java class files will be related to each other to the extent that the interpretation or compilation of one class file will result or is likely in the interpretation or compilation of another. I.e. one class file is likely to call for execution another. This information could be obtained by run-time analysis at the receiver but as previously stated, this introduces latency. Fortunately however, upon authoring the application data, it will be appreciated which class files are so related and these class files can be grouped accordingly. In accordance with the present invention, these groupings are identified by the receiving system whereby certain class-files are pre-compiled and cached in a memory for later execution upon either the interpretation, compilation or execution of other byte code files in the same group. 
     The groupings of the class files may be conveyed to the receiving system in accordance with either of the following examples: 
     EXAMPLE 1 
     The grouping is defined in relation to the arrangement of the byte code files during transmission. Such grouping may be defined using the DSM-CC of DVB&#39;s MHP which is able to group class files and other files in to modules for broadcast wherein the contents of a module are associated with a particular application. For example, referring to  FIG. 2 , module  1  contains a list of all the class files in directory “dir 1 ”; module  2  contains class files “file 1 .class”, “file 4 .class”, “file 5 .class” and a list of class files in directory “dir 2 ”; and module  3  contains class files “file 2 .class”, “file 3 .class”, “file 6 .class”, “file 7 .class” and a list of all class files in directory “dir 2 ”, and also graphics file “file 8 .gif”. Byte code files may then be selected for compilation upon either the interpretation, compilation or execution of other byte code files transmitted in the same group. 
     EXAMPLE 2 
     The grouping is defined by the directory structure of the byte code files as stored at the server prior to transmission, and whereby a single group corresponds to a single directory. In this case, the grouping information may be distributed amongst the byte code files in that it may comprise file locations appended to the file name of each respective byte code file. For example, referring to  FIG. 3 , the directory structure shown may correspond to 3 groups of class files, group  1  corresponding to directory “dir 1 ” which contains all the class files; group  2  corresponding to “dir 2 ” which contains class files “file 4 .class” and “file 5 .class”; and group  3  corresponding to “dir 3 ” which contains class files “file 6 .class” and “file 7 .class”. In this case, a given class file can belong to more than one group although it need only be broadcast once. Byte code files may then be selected for compilation whereby those class files in the groups corresponding to directories “dir 2 ” and “dir 3 ” are selected upon the interpretation, compilation or execution of other byte code files residing in the same directory; and upon compilation of class files “file 1 .class”, “file 2 .class” and “file 3 .class” (i.e. those in directory “dir 1 ” but not directories “dir 2 ” or “dir 3 ”), all the class files in directory “dir 1 ” (including those in “dir 2 ” and “dir 3 ”) are compiled. 
     EXAMPLE 3 
     Similar to example 2 except that the grouping is defined by the directory structure to be used to store the byte files at the receiving terminal which need not be the same as the directory structure of the files as stored at the server. 
     EXAMPLE 4 
     The grouping is defined by additional information transmitted with the class files and provided specifically for the sole purpose of defining groups of class files for efficiently compilation. 
     The embodiments above describe the invention primarily in the context of a broadcast system broadcasting byte code on a carousel. However, the invention is equally applicable to other arrangements where byte code is transmitted to a receiving system including Internet transfers of Java applets and the like.