Method and apparatus for referencing thread local variables with stack address mapping

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

FIELD OF THE INVENTION

The present disclosure relates generally to the field of data processing, and more particularly to multithreading, with regard to methods and related apparatuses for referencing thread local variables.

BACKGROUND

In the field of computer software, the term “process” generally refers to a coherent sequence of steps or instructions undertaken by a computer program or application. From the perspective of a user, a data processing system may support multiple processes concurrently. For example, the processes that are executing concurrently in a data processing system may include an Internet browser application and a word processing application.

In addition, an application may utilize a technique known as “multithreading” to run two or more parts of a particular process concurrently, or virtually concurrently. For instance, a web browser process may launch two separate threads to download data from two different sources concurrently. Each of those threads may include a separate copy of a certain subset of instructions from the overall application. For example, each thread may include the instructions for a download function within the web browser application.

The local variables of each thread are typically unique. Thus, if two separate instances of a function are executing in two separate threads, each thread may include a distinct set of the local variables associated with that function. On the other hand, static variables and global variables are typically shared by all of the threads in a process.

Function local storage and thread local storage are two mechanisms that may be used to store local variables for a thread. With thread local storage, one can provide unique data for each thread in a process. The variables of a thread that reside in thread local storage may be referred to as “thread local variables” or simply “TLVs.” Under some operating systems, before TLVs can be defined, the process must allocate an index known as a “global index,” and that index must then be used to access any TLVs.

Many multithreaded applications use TLVs widely. For example, when supporting multithreaded Java applications, runtime systems such as Java virtual machines (JVMs) often use TLVs for tasks such as exception handling, garbage collection (GC), and runtime helper routines. Furthermore, a runtime system may access these variables frequently when running Java applications. For instance, when an exception is thrown from a method of the Java application, the JVM needs to perform stack unwinding to the method's previous (caller) frame, in case the thrown exception is not caught or handled by the current method. Unwinding operations are also required for GC, for instance to find the root set of live references during root set enumeration and to fill in the stack trace information for an exception object. One common mechanism in runtime systems for handling exception and stack unwinding is to use TLVs to record the contexts or activation records of the active Java methods of each live thread. TLVs may be used to implement various data structures, including linked lists, for instance.

In conventional systems, one constraint associated with TLVs is that threads must use a kernel system call to access the TLVs. For instance, a kernel system call (e.g., pthread_getspecific) is required to acquire a TLV head pointer in thread packages such as Linux pthread. A disadvantage associated with needing to use kernel system calls to access TLVs is that kernel system calls typically adversely affect the performance of a system, due to trapping into kernel mode or privileged mode. Such traps impose high overhead due to operations such as cache flushes, etc.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the present invention will become apparent from the appended claims and the following detailed description of one or more example embodiments, in which:

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram depicting an example embodiment of a suitable data processing environment in which certain aspects of the invention may be implemented;

<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram depicting an example embodiment of the user space and kernel space from the data processing environment of <figref idref="DRAWINGS">FIG. 1</figref>; and

<figref idref="DRAWINGS">FIG. 3</figref> is a flowchart illustrating a process for referencing thread local variables with stack address mapping, in accordance with one example embodiment of the present invention.

DETAILED DESCRIPTION

The present disclosure describes one or more example embodiments of methods and apparatuses which support referencing of thread local variables with little or no need for system kernel calls.

<figref idref="DRAWINGS">FIG. 1</figref> and the following discussion are intended to provide a general description of a suitable environment in which certain aspects of the present invention may be implemented. As used herein, the terms “processing system” and “data processing system” are intended to broadly encompass a single machine, or a system of communicatively coupled machines or devices operating together. Exemplary processing systems include, without limitation, distributed computing systems, supercomputers, computing clusters, mainframe computers, mini-computers, client-server systems, personal computers, workstations, servers, portable computers, laptop computers, tablet processing systems, telephones, personal digital assistants (PDAs), handheld devices, entertainment devices such as audio and/or video devices, and other devices for processing or transmitting information.

The data processing environment of <figref idref="DRAWINGS">FIG. 1</figref>, for example, may include a processing system <b>20</b> that includes one or more processors or central processing units (CPUs) <b>22</b> communicatively coupled to various other components via one or more buses <b>28</b> or other communication conduits or pathways. Such components may include one or more volatile or non-volatile data storage devices, such as random access memory (RAM) <b>24</b>, read-only memory (ROM), mass storage devices <b>29</b> such as integrated drive electronics (IDE) hard drives, and/or other devices or media, such as floppy-disks, optical storage, tapes, flash memory, memory sticks, digital video disks, biological storage, etc. For purposes of this disclosure, the term “ROM” may be used in general to refer to non-volatile memory devices such as erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash ROM, flash memory, etc.

The components coupled to processor <b>22</b> in processing system <b>20</b> may also include one or more PCI root bridges and one or more PCI-to-PCI bridges. One or more of the above bridges and buses may be used to connect processor <b>22</b>, either directly or indirectly, with storage devices and with additional components, such as one or more input/output (I/O) devices, ports, or controllers <b>26</b>. Such devices may include a video controller, a small computer system interface (SCSI) controller, a network controller, a universal serial bus (USB) controller, a keyboard controller, etc.

In one embodiment, one or more devices may be implemented as embedded controllers, using components such as programmable or non-programmable logic devices or arrays, application-specific integrated circuits (ASICs), embedded computers, smart cards, and the like. For instance, a PCI root bridge may be implemented as an embedded device, residing on a system backplane or motherboard.

Processing system <b>20</b> may be controlled, at least in part, by input from conventional input devices, such as a keyboard <b>32</b>, a mouse, etc., and/or by directives received from one or more remote data processing systems <b>34</b>, interaction with a virtual reality (VR) environment, biometric feedback, or other input sources or signals. Processing system <b>20</b> may send output to components such as a display device <b>30</b>, remote data processing system <b>34</b>, etc. Communications with remote data processing system <b>34</b> may travel through any suitable communications medium. Processing systems may be interconnected by way of a physical and/or logical network <b>36</b>, such as a local area network (LAN), a wide area network (WAN), an intranet, the Internet, etc. Communications involving network <b>36</b> may utilize various wired and/or wireless short range or long range carriers and protocols, including radio frequency (RF), satellite, microwave, Institute of Electrical and Electronics Engineers (IEEE) 802.11, Bluetooth, optical, infrared, cable, laser, etc.

The invention may be described by reference to or in conjunction with associated data including instructions, functions, procedures, data structures, application programs, etc. which when accessed by a machine result in the machine performing tasks or defining abstract data types or low-level hardware contexts. The data may be referred to in general as software, and it may be stored in volatile and/or non-volatile data storage.

For instance, in the illustrated embodiment, storage <b>29</b> includes one or more sets of instructions <b>70</b> to support referencing of TLVs with little or no need for system kernel calls. For purposes of this document, those instructions may be referred to as “TLV software” <b>70</b>. In the example embodiment, TLV software <b>70</b> may reside partially or completely within one or more libraries for a JVM or other managed runtime environment (MRTE) <b>64</b>, which may operate logically on top of an operating system (OS) <b>62</b>. In one embodiment, TLV software <b>70</b> may be copied from storage <b>29</b> to RAM <b>30</b> along with MRTE <b>64</b> when MRTE <b>64</b> is loaded. In other embodiments, software such as TLV software <b>70</b> may be loaded from other sources, such as network storage or remote data processing system <b>34</b>. In alternative embodiments, TLV software <b>70</b> may reside in other places, such as in one or more user applications <b>66</b>, in OS <b>62</b>, or in software to operate between OS <b>62</b> and user applications <b>66</b>, for example.

<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram depicting an example embodiment of a software environment <b>80</b> within data processing system <b>20</b> of <figref idref="DRAWINGS">FIG. 1</figref>. Software environment <b>80</b> may include a user space <b>42</b> logically supported by a kernel space <b>40</b>. Parts of OS <b>62</b> may operate in kernel space <b>40</b>, while other parts may operate in user space <b>42</b>. User applications <b>66</b>, MRTE <b>64</b>, and other software to operate logically between OS <b>62</b> and user applications <b>66</b> may also operate in user space <b>42</b>.

In the example embodiment, OS <b>62</b> supports multiple threads <b>110</b> for a process executing within software environment <b>80</b>, as illustrated within kernel space <b>40</b>. For purposes of discussion, threads <b>110</b> may be referenced individually as Thread A, Thread B, etc. As illustrated by the dashed boxes within MRTE <b>64</b>, portions of each thread <b>110</b> may also be accessible from user space <b>42</b>.

OS <b>62</b> may maintain a process stack <b>100</b> that includes a thread stack <b>102</b> for each existing thread <b>110</b>. For purposes of discussion, thread stacks <b>102</b> may be referenced individually as Stack A, Stack B, etc. OS <b>62</b> may use each thread stack <b>102</b> to store information such as program execution history or context and local data structures for the corresponding thread <b>110</b>.

As illustrated with square brackets, OS <b>62</b> may allocate each thread stack <b>102</b> beginning at a distinct address, such as 0xf0100000, 0xf0200000, etc. In particular, the characteristics of one embodiment include the following: (a) each live thread <b>110</b> has its own stack space that does not overlap the stack space for any other thread <b>110</b>, (b) all live threads <b>110</b> have the same maximum stack size, and (c) the starting address for each thread stack <b>102</b> is aligned with respect to the common maximum stack size. For example, threads <b>110</b> may use a thread stack size of 1 megabyte (MB), and OS <b>62</b> may align all thread stack start addresses on 0x100000 (i.e., 1 MB). The space within process stack <b>100</b> occupied by a thread stack may also be referred to as a “thread stack chunk.” In the example embodiment, process stack <b>100</b> is illustrated as having been divided into N thread stack chunks <b>102</b>, with each chunk having the same size and starting at an address that is aligned on a multiple of the 1 MB address.

As indicated by the dotted lines that subdivide MRTE <b>64</b> horizontally, MRTE <b>64</b> may support multiple different types of storage for the threads operating in software environment <b>80</b>. For instance, MRTE <b>64</b> may support thread local storage <b>52</b> for storing TLVs, function local storage <b>54</b> for storing the local variables of a thread's functions, and thread global storage <b>50</b> for storing global variables. As illustrated by the dashed boxes within MRTE <b>64</b>, individual threads (e.g., Thread A) may include variables and data in function local storage <b>54</b>. Each individual thread may also include its own distinct set of TLVs, represented in <figref idref="DRAWINGS">FIG. 2</figref> by TLVs <b>120</b>A, <b>120</b>B, . . . , <b>120</b>N within Thread A, Thread B, . . . Thread N, respectively.

According to the illustrated embodiment, bits <b>21</b> through <b>28</b> of each thread stack start address can be used to distinguish and identify different threads. For example, as illustrated by the two boldface digits within each illustrated thread stack start address for thread stacks <b>102</b>, the index <b>01</b> can be used to identify Thread A, since Stack A corresponds to Thread A. Likewise, the index <b>02</b> can be used to identify Thread B, and the index <b>254</b> (0xfe) can be used to identify Thread N.

In the example embodiment, a global array of head pointers <b>122</b> is created in thread global storage <b>50</b> within MRTE <b>64</b>. Global array <b>122</b> may be named “thread_local_var_array,” for example. When a thread <b>110</b> is created, TLV software within MRTE <b>64</b> adds a value for that thread to global array <b>122</b> at the index derived from bits <b>21</b>-<b>28</b> of the start address of the thread stack <b>102</b> for that thread <b>110</b>. In particular, the value that is added to global array <b>122</b> is the head pointer of the TLVs for that thread. For purposes of illustration, the head pointer of the TLVs of Thread A is shown within global array <b>122</b> as “Head Pointer A”, the head pointer of the TLVs of Thread B is shown as “Head Pointer B,” etc.

For example, when Thread A is created, the head pointer of the TLVs of Thread A is added to global array <b>122</b> at index <b>01</b>. For purposes of discussion, the individual cells within global array <b>122</b> may be referred to as records or entries.

In <figref idref="DRAWINGS">FIG. 2</figref>, the dashed arrow from the starting address of Stack A to the first record in global array <b>122</b> indicates that the first record in global array <b>122</b> can be associated with Thread A, based on the stack address for Thread A (i.e., based on the starting address of Stack A). The dashed arrow from the first record in global array <b>122</b> to TLVs <b>120</b>A within thread local storage <b>52</b> indicates that the Head Pointer A value within global array <b>122</b> points to the TLVs for Thread A.

Similarly, when Thread B is created, the head pointer of the TLVs of Thread B are added to global array <b>122</b> at index <b>02</b>, and when Thread N is created, Head Pointer N is added to global array <b>122</b> at index <b>254</b> (0xfe).

Consequently, each item in global array <b>122</b> can be indexed by thread stack addresses with simple bit mask operations. Thus, the TLV head pointer for any thread <b>110</b> can be obtained from global array <b>122</b> by simply indexing global array <b>122</b> with bits <b>21</b> through <b>28</b> of the thread stack start address for that thread. TLVs can therefore be quickly located, based on the current thread stack address.

The following program code or pseudo code depicts an example code sequence or instruction sequence to implement referencing of TLVs through use of a global array of TLV head pointers, such as global array <b>122</b>.

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> 1</entry><entry>void SET_THREAD_LOCAL_VAR (void* p_thread_local_var,</entry></row><row><entry /><entry>unsigned int stack_address)</entry></row><row><entry> 2</entry><entry>{</entry></row><row><entry> 3</entry><entry>unsigned int stack_key;</entry></row><row><entry> 4</entry><entry>stack_key = (stack_address &amp; STACK_MASK) &gt;&gt;</entry></row><row><entry /><entry>STACK_SHIFT_BITS;</entry></row><row><entry> 5</entry><entry>thread_local_var_array[stack_key] = p_thread_local_var;</entry></row><row><entry> 6</entry><entry>}</entry></row><row><entry> 7</entry></row><row><entry> 8</entry><entry>void* GET_THREAD_LOCAL_VAR (unsigned int stack_address)</entry></row><row><entry> 9</entry><entry>{</entry></row><row><entry>10</entry><entry>unsigned int stack_key;</entry></row><row><entry>11</entry><entry>stack_key = (stack_address &amp; STACK_MASK) &gt;&gt;</entry></row><row><entry /><entry>STACK_SHIFT_BITS;</entry></row><row><entry>12</entry><entry>return thread_local_var_array[stack_key];</entry></row><row><entry>13</entry><entry>}</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> © 2004 Intel Corporation.

In the above sequence, thread_local_var_array corresponds to global array <b>122</b>. The function SET_THREAD_LOCAL_VAR sets the head pointer of the TLVs for a thread. The function GET_THREAD_LOCAL_VAR returns the head pointer of the TLVs for a thread, so the head pointer may be used to access those TLVs. As indicated by the parameter stack_address, both functions use the current stack address (i.e., the stack start address for the current thread) as the basis for the index into thread_local_var_array.

Lines 4 and 11 depict a formula for mapping a thread stack address to a unique index in thread_local_var_array. In the illustrated embodiment, the thread stack address is masked with a bit mask represented by STACK_MASK, and the result is then shifted to the right by an amount represented by STACK_SHIFT_BITS. The values for data items such as STACK_MASK and STACK_SHIFT_BITS may be set as appropriate for a particular environment, OS, thread package, etc. For instance, in the example embodiment, STACK_MASK is 0x0ff00000 and STACK_SHIFT_BITS is 20.

Functions like SET_THREAD_LOCAL_VAR and GET_THREAD_LOCAL_VAR which support the operations described herein for manipulating or accessing the global array of head pointers while reducing or eliminating the need to use kernel mode processing may be referred to in general as “thread local variable functions” or simply “TLV functions.” For purposes of the present disclosure, the different TLV functions and related objects, logic, etc. that may be used in different environments and implementations, such as the software associated with reference number <b>70</b> in <figref idref="DRAWINGS">FIG. 1</figref>, may be referred to in general as “TLV software.”

<figref idref="DRAWINGS">FIG. 3</figref> is a flowchart illustrating a process for referencing thread local variables with stack address mapping, in accordance with an example embodiment of the present invention. That process is described with regard also to <figref idref="DRAWINGS">FIGS. 1 and 2</figref>. The process of <figref idref="DRAWINGS">FIG. 3</figref> may begin with OS <b>62</b>, MRTE <b>64</b>, and one or more user applications <b>66</b> operating in processing system <b>20</b>. At block <b>200</b> MRTE <b>64</b> initializes global array <b>122</b>.

At block <b>202</b> MRTE <b>64</b> determines whether a new thread is required, for example in response to a request for a new thread from a user application <b>66</b>. If a new thread is required, MRTE <b>64</b> creates the new thread, as indicated at block <b>203</b>. In conjunction with creating the new thread, MRTE <b>64</b> obtains the head pointer for the TLVs for that thread at block <b>204</b>. MRTE <b>64</b> may use a conventional OS call (e.g., a call to the function pthread_getspecific in Linux) to obtain the head pointer. Accordingly, processing system <b>20</b> may enter kernel mode when the head pointer is first being obtained.

MRTE <b>64</b> then obtains the stack address for the new thread, as indicated at block <b>206</b>. At block <b>208</b>, MRTE <b>64</b> uses the stack address to determine the appropriate index into global array <b>122</b> for the new thread, as described above. MRTE <b>64</b> then adds the head pointer to global array <b>122</b> at that index, as indicated at block <b>210</b>.

After the head pointer has been added to global array <b>122</b>, or after a negative determination at block <b>202</b>, MRTE <b>64</b> may determine at block <b>220</b> whether access to one or more TLVs is desired. Alternatively, MRTE <b>64</b> may be designed to automatically use TLV software <b>70</b> to retrieve a head pointer whenever appropriate, such as in advance of instructions that will require access to a TLV. In either case, MRTE <b>64</b> may obtain the stack address for the current thread at block <b>222</b>, and MRTE <b>64</b> may use that stack address to determine the appropriate index into global array <b>122</b> at block <b>224</b>, as described above. MRTE <b>64</b> may then use that index to retrieve the head pointer for the current thread's TLVs, as indicated at block <b>226</b>. At block <b>228</b> MRTE <b>64</b> may then use the head pointer to access one or more TLVs of the current thread, for use in processes such as stack unwinding for GC and exception handling, runtime helper routines, etc.

In the example method depicted in <figref idref="DRAWINGS">FIG. 3</figref>, many of the determinations and calls to TLV functions are made by MRTE <b>64</b>. In alternative embodiments, however, other components may make the same or related determinations and calls to TLV functions. For instance, a user application running directly over an OS without a managed runtime environment may make the same or related determinations and calls to TLV functions. For example, a multi-threading web browser may use TLV functions for managing the state of different threads used for downloading.

As described above, TLV software <b>70</b> provides a very efficient mechanism for allowing threads to access TLVs. For instance, in one or more of the above embodiments, once TLV head pointers have been stored in global array <b>122</b>, MRTE <b>64</b> allows threads to access TLVs without using any kernel system calls. In the example embodiment, access to global array <b>122</b> is always lightweight. That is, access is provided while remaining completely in user mode. Calls are made only to user space functions. MRTE <b>64</b> thus avoids the high overhead associated with trapping into kernel or privileged mode. By keeping a global array of head pointer for TLVs and using thread stack addresses to index that global array, the runtime environment allows threads to access TLVs with almost negligible overhead.

The size of the global array may vary for different implementations. Factors in determining a suitable size may include the system capability of multithreading such as the maximum number of threads, the process stack size, and the thread stack size. In one embodiment, the global array is allocated with a size equal to the process stack size divided by the thread stack size. If a thread package prefers to reuse the stack area of a destroyed thread before allocating a new stack area, the size of the global array could be the maximum number of supported threads, which may be smaller than process stack size divided by thread stack size.

A number of advantages may be provided by one or more embodiments. For instance, each thread may access only one item in global array <b>122</b> using a simple stack address mapping. The system may therefore avoid much of the overhead (e.g, searching and synchronization) associated with storing head pointers to and retrieving head pointers from more complex data structures, such as linked lists. Global array <b>122</b> may also provide improved memory locality, and memory accesses may therefore be reduced. For instance, in systems that provide a cache line of 32 bytes, 8 consecutive records from global array <b>122</b> may be loaded in the cache line at once. Relative data may therefore be referenced more quickly. Also, when destroying a thread, there is no need to clear its corresponding cell in the global array, because the cell will not be referenced until a new thread is created to occupy the stack chunk, and the old cell will then be initialized to the new head pointer of the newly created thread.

Moreover, the teachings of the present disclosure may be used to advantage in a wide variety of operating environments. For instance, the teachings may be used in a wide variety of runtime environments, including MRTEs designed for systems using Intel Corporation's XScale® technology or for any other type of data processing system. The types of MRTEs that may benefit from the teachings of the present disclosure include, without limitation, JVM runtime systems, Common Language Infrastructure environments such as Common Language Runtime (CLR), Perl/Parrot virtual machines, etc.

Moreover, the present teachings are not limited to use in runtime environments, but may be used to advantage in a wide variety of software architectures, environments, or products, including any multi-thread aware application. Examples of alternative embodiments include, without limitation, embodiments in which the operations for saving and retrieving head pointer for TLVs are implemented (a) in other types of middleware running logically between the OS level and the user application level, (b) as part of an OS, preferably to execute primarily in the user space rather than in the kernel space, and (c) as part of an end user program, application, or suite of applications.

Additionally, alternative embodiments include embodiments in which different aspects of TLVs are stored in and retrieved from a global data structure such as global array <b>122</b>. For example, for user functions that do not store complex data structures in TLVs but store only simple items such as integers, the actual value could be stored in the global array, instead of storing a head pointer to the TLVs. Thus, one alternative embodiment includes a global array of TLVs, instead of or in addition to a global array of head pointers to TLVs. Alternative embodiments may also include embodiments in which data structures other than arrays are used to store the head pointers in the user space.

Accordingly, in light of the principles and example embodiments described and illustrated herein, it will be recognized that the illustrated embodiments can be modified in arrangement and detail without departing from such principles. And, though the foregoing discussion has focused on particular embodiments, other configurations are contemplated. In particular, even though expressions such as “in one embodiment,” “in another embodiment,” or the like are used herein, these phrases are meant to generally reference embodiment possibilities, and are not intended to limit the invention to particular embodiment configurations. As used herein, these terms may reference the same or different embodiments that are combinable into other embodiments.

Similarly, although example processes have been described with regard to particular operations performed in a particular sequence, it will be apparent to those of ordinary skill in the art that numerous modifications to the processes could be applied to derive numerous alternative embodiments of the present invention. For example, alternative embodiments may include processes that use fewer than all of the disclosed operations, processes that use additional operations, processes that use the same operations in a different sequence, and processes in which the individual operations disclosed herein are combined, subdivided, or otherwise altered.

Alternative embodiments of the invention also include machine accessible media encoding instructions for performing the operations of the invention. Such embodiments may also be referred to as program products. Such machine accessible media may include, without limitation, storage media such as floppy disks, hard disks, CD-ROMs, ROM, and RAM; as well as communications media such antennas, wires, optical fibers, microwaves, radio waves, and other electromagnetic or optical carriers. Accordingly, instructions and other data may be delivered over transmission environments or networks in the form of packets, serial data, parallel data, propagated signals, etc., and may be used in a distributed environment and stored locally and/or remotely for access by single or multi-processor machines.

It should also be understood that the hardware and software components depicted herein represent functional elements that are reasonably self-contained so that each can be designed, constructed, or updated substantially independently of the others. In alternative embodiments, many of the components may be implemented as hardware, software, or combinations of hardware and software for providing the functionality described and illustrated herein.

In view of the wide variety of useful permutations that may be readily derived from the example embodiments described herein, this detailed description is intended to be illustrative only, and should not be taken as limiting the scope of the invention. What is claimed as the invention, therefore, is all implementations that come within the scope and spirit of the following claims and all equivalents to such implementations.