Patent application number | Description | Published |
20100199259 | Methods and Apparatus for Dynamic Class Reloading and Versioning - Methods and apparatus for dynamic class reloading and versioning that allow developers to change and recompile classes and to have running programs adopt the new versions of the classes dynamically, without redeploying the application. A dynamic class reloading component detects if the environment supports dynamic class redefinition and uses it if supported but does not require it. As the component loads a managed class, it modifies the bytecode of the class and generates additional classes and interfaces to support type-safe class versioning. Unique names are generated for successive versions of a managed class. A separate interface may be generated for each distinct method name and signature implemented on managed classes. Each generated class may implement all the generated interfaces that correspond to its methods. The same class loader that would load each managed class without the component loads the component-generated classes and interfaces. | 08-05-2010 |
20110202725 | SOFTWARE-ACCESSIBLE HARDWARE SUPPORT FOR DETERMINING SET MEMBERSHIP - A method and processor supporting architected instructions for tracking and determining set membership, such as by implementing Bloom filters. The apparatus includes storage arrays (e.g., registers) and an execution core configured to store an indication that a given value is a member of a set, including by executing an architected instruction having an operand specifying the given value, wherein executing comprises hashing applying a hash function to the value to determine an index into one of the storage arrays and setting a bit of the storage array corresponding to the index. An architected query instruction is later executed to determine if a query value is not a member of the set, including by applying the hash function to the query value to determine an index into the storage array and determining whether a bit at the index of the storage array is set. | 08-18-2011 |
20150301807 | Partial Specialization of Generic Classes - Generic classes may have more than one specializable type parameter and it may be desirable to specialize one or more of the type variables while not specializing others. The result of partial specialization may be one or more additional generic classes that are further specializable on the remaining type parameters. A runtime specializer may partially specialize a generic class to produce a partially specialized class and may subsequently further specialize the partially specialized class to generate a fully specialized class. Thus, rather than performing the specialization of a generic class all at once, such as by specializing Map into Map or Map, one type parameter may be partially specialized, such as resulting in Map, and then at some later time the remaining type parameter(s) may be specialized, such as to generate Map or Map. | 10-22-2015 |
20150301808 | Manual Refinement of Specialized Classes - While a runtime specializer may always be able to generate an automated specialized version of a generic class, in some cases an alternate form of user control over specialization may allow the use of automated specialization while also adding (or overriding) specialization-specific method implementations. In general, the set of members of a generic class may not change when the class is specialized. In other words, the same members may exist in the auto-specialized version as in the generic version. However, manual refinement of specialized classes may allow a developer to hand specialize a particular (possibly a better) representation and/or implementation of one or more methods of the specialized class. | 10-22-2015 |
20150301809 | Wholesale Replacement of Specialized Classes - Wholesale replacement of specialized classes may involve the ability to replace the auto specialization of a generic class may not be used at all and instead, a completely different, hand-written, class when the class is specialized for particular type parameterizations, according to some embodiments. The replacement class may have the same interface as the generic or auto specialized version, but it may have a completely different representation and/or implementation. A runtime environment may load the alternate version of the class, based on information identifying the alternate version, whenever the particular specialization is instantiated. The runtime may not have to load the generic or auto specialized version of the class when using the alternate version of the class. | 10-22-2015 |
20150301812 | Metadata-driven Dynamic Specialization - Metadata-driven dynamic specialization may include applying a type erasure operation to a set of instruction in a generic class or to a method declaration that includes typed variables using an encoded form of an instruction or an argument to an instruction. The instruction may operate on values of the reference types and the argument may be a signature that indicates the reference types. The encoded form may be annotated to include metadata indicating which type variables have been erased and which reference types are the erasures of type variables. Additionally, the metadata may indicate that the instruction operates on values of, and that the argument indicates reference types that are erasures of, the type variables of the class (or method) declaration. Moreover, the encoded form of the instruction or argument may be used directly without specialization or transformation. | 10-22-2015 |
20150301825 | Decomposing a Generic Class into Layers - The domain of genericity of an existing generic class may be expanded to include not just reference types, but also primitive and value types even though some members of the existing class do not support the expanded genericity. A subdivided version of the class may be created that includes a generic layer including abstract versions of class members and a reference-specific layer that including non-abstract versions of class members that are abstract in the generic layer. The subdivided version of the class may also include information that indicates to which layer a class member belongs. Problematic methods (e.g., methods that have built-in assumptions regarding the domain of genericity) may be moved into the second, reference-specific, layer, thereby retaining compatibility with classes that currently instantiate or reference those methods, while still allowing use within the expanded domain of genericity. | 10-22-2015 |
20150301837 | Structural Identification of Dynamically Generated, Pattern-Instantiation, Generated Classes - Structural identification of dynamically generated, pattern-instantiation classes may be utilized using structural descriptions. Instead of describing classes only by name, and using that name to locate that class, a class may be referred to by a generator function and arguments to the generator function. A structural description may specify the generator function and the parameters. In addition, a structural description of a class may be used as a parameter to a generator function specified by another structural description. A structural description may be used similarly to a class name for virtually any situation in which a class name may be used. Classes may be compared using their structural descriptions. For example, two structural descriptions may be considered to be the same class if they specify the same generator function and parameters. | 10-22-2015 |
20150301840 | Dependency-driven Co-Specialization of Specialized Classes - The loading or operation of a specialized class may trigger the specialization of other classes. A compiler may be configured to recognize dependency relationships between generic classes and to describe the classes in terms of the type variables of the triggering types (e.g., the types and/or type parameterizations) that trigger the specialization of classes based on the specialization of a first class. A compiler may include information, such as structural references, indicating dependency relationships between classes when generating class files. Thus, the class file may include information indicating that a class extends a class resulting from applying a specialization code generator to an argument. Loading a first class may trigger the loading of a second class described by a structural description such that a specializer (and/or class loader) may apply the structural description to generate and load the second class for the particular parameterization. | 10-22-2015 |