IS BOUND IS NOT INITIAL IS ASSIGNED IS BOUND IS BOUND IS NOT INITIAL IS ASSIGNED IS BOUND IS BOUND

This article continues this discussion from the perspective of the different reference types in ABAP and the Java programming language.

Have you noticed the ABAP abstract class CL_ABAP_REFERENCE? This abstract class has only one GET method that returns a reference to an object.

Its two subclasses CL_ABAP_SOFT_REFERENCE and CL_ABAP_WEAK_REFERENCE, respectively, realize the abstract class GET method, but are implemented in the ABAP Kernel, for ABAP application developers, can not see the source code, is a black box.

How do you use this class? Again, check out the SAP help documentation:

An object in the system class CL_ABAP_WEAK_REFERENCE represents a weak reference to an object in a class. Unlike regular object references, a weak reference is ignored during execution of the garbage collector. This means that a weak reference does not prevent the referenced object from being deleted when the garbage collector is executed.

CL_ABAP_WEAK_REFERENCE class instance, which represents a weak application pointing to an object instance. Literally, if there is a weak reference, there is also a strong application of its opposite. Suppose there is an ABAP class lcl_person:

DATA: lo_person TYPE REF TO lcl_person.
CREATE OBJECT lo_person.
Copy the code

The above code defines a strongly referenced variable named LO_Person to an instance of the Lcl_person object. When the garbage collector is working, the memory area occupied by the Lcl_PERSON object instance is not freed by the ABAP garbage collector as long as the strong reference to lo_person of the lCL_Person object instance is still valid (that is, no CLEAR call is made, or no reassignment is made to another object instance). In other words, if there is at least one strong reference to an lCL_PERSON object instance, its memory area will not be reclaimed by the ABAP garbage collector under any circumstances.

Weak references, on the other hand, are simply ignored during the garbage collection phase. This means that when the ABAP garbage collector starts working, if an object instance does not have any strong references pointing to it, the object instance cannot escape being collected regardless of whether there are weak references pointing to it.

Let’s look at a specific example.

This 30-line ABAP report implements a simple LCL_PERSON class. Line 17 creates an instance of this class whose strong reference is stored in the reference variable lo_person.

Line 18 creates a weak reference to LO_weak that wraps an instance of the LCL_PERSON object. Calling the get method with a weak reference to lo_weak returns two different results in two different cases:

(1) If the instance of the lcl_person object created on line 17 has already been collected by the garbage collector, get returns an empty reference; (2) Return a reference to the lcl_person object instance if it has not been reclaimed.

Those who need the source code for this article can find it on my SAP community blog:

Weak reference in ABAP and Java

I gave the ABAP program two input parameters, clear and GC, to control whether to clear the strongly referenced variable lo_person and whether to call the ABAP garbage collector with code, respectively.

Clear: lo_person. If clear is set to true when the program is executed, clear: lo_person. According to the ABAP help, CLEAR is applied to the reference variable lo_person, which points to a null reference after execution.

If gc is set to true, the ABAP garbage collector is started in code: cl_abap_memory_utilities=>do_garbage_collection.

The opening and closing of these two switches constitute four different permutations. Under these four permutations, will the object instances pointed to by the weak reference LO_weak be collected by the ABAP garbage collector? The results are as follows:

Thus, an object instance pointed to by a weak reference that is not pointed to by at least one strong reference variable after ABAP garbage collector starts will be collected by the garbage collector.

The s_memory_inspector creates a Memory Snapshot after the garbage collector starts and finds that the lCL_PERSON object instance has been collected under the first arrangement in the table above: No Memory objects found.

For the other three permutations, lcl_person escapes the garbage collector:

Also has a corresponding CL_ABAP_WEAK_REFERENCE weak references in Java implementation: Java. Lang. Ref. WeakReference.

Jerry’s ABAP program, translated into Java code, looks like this:

Because weak references in both programming languages work exactly the same way, the Java version of Jerry’s example above will not be repeated.

In line 25, we set the object pointed to by the strongly referenced jerry variable to NULL. In line 26, we start the Java garbage collector. In line 27, we call the weak-referenced get method and get null.

So what are the usage scenarios for this weak reference?

The best way to learn is to perform the where-used operation on CL_ABAP_WEAK_REFERENCE to find which SAP standard applications use this class.

In the SAP CRM system Jerry uses below, weak references are used in many ways.

Among the 500 or so usage scenarios, the most typical is the implementation of Cache. The GGET_DATA_TYPE_HANDLER method on the Application Enhancement Tool(AET) factory class returns the handler instance based on two input parameters, the field data type and the field behavior type. These processors are instantiated to read data from several database tables and store it in memory, so the initialization process takes some time. To prevent this method from spending time repeatedly accessing the database table and creating new instances each time it is called, the factory class introduces a caching mechanism, namely the table gT_type_handler_cache in line 21 below. Each time the GET method is called, the inner table is checked to see if the corresponding handler instance exists. If so, it returns directly, saving time-consuming processor instantiation.

If you look at the cache design, in the line item type structure, the handler type is not a concrete IF_AXT_DATATYPE_HANDLER, but a weak reference.

Technically, the seventh line in the figure above should read:

Handler TYPE REF TO IF_AXT_DATATYPE_HANDLER is also the correct design, and is the most common cache design for most ABAP applications. For the sake of discussion, I will refer to this common scheme as Scheme B, and the AET factory class above, which uses weak application pointing to the processor instance, as scheme A.

The advantage of plan A is that you can advance and defend.

Into can attack, that is, if the ABAP garbage collector didn’t call, and there are at least A strong reference to an actual processor, as two kinds of scheme runtime not big difference, the only slight difference in the cache is to plan A reading list, get stored in the buffer after A weak reference, and then call the get method of weak references, Take the processor instance and return it. In scheme B, after the table in the buffer is hit, the buffer is the processor instance itself, which can be directly returned to the calling end.

Fallback means that once there are no strong references to the processor instance in the program and the ABAP garbage collector starts working, the weak reference to the processor instance is destroyed, freeing up the memory it consumed. The next time the GET method is called again, it reloads the data from the database, initializes the processor instance (red area below), and recreates the weak reference (blue area below).

In short, CL_ABAP_WEAK_REFERENCE is best used to describe object instances that are useful but not necessarily resident in memory. Therefore, it is widely used in the cache design of many framework codes in SAP CRM.

In addition to strong and weak references, ABAP also has a third type of reference: soft reference (CL_ABAP_SOFT_REFERENCE).

In contrast to weak references, objects referred to by soft references are destroyed only if they are not referred to by any strong references and the garbage collector runs out of memory. What percentage of free memory is insufficient? Soft references are not implemented in ABAP, so we can’t continue the discussion.

In addition to weak and soft references, Java also has phantomreferences.

As the name suggests, a virtual reference in Java is “null” because the result obtained from the get method of a virtual reference is always null.

In some Chinese materials, PhantomReference is also translated into “PhantomReference” or “PhantomReference” because of its behavior. The name reminds me of Wraith, the Terran ghost fighter from StarCraft.

Virtual references are used to track the activity of an object instance being reclaimed by the garbage collector and must be used in conjunction with the ReferenceQueue (ReferenceQueue). When the garbage collector is about to reclaim an object, if it finds that there are still virtual references to the object instance, it adds the virtual reference to the reference queue associated with it before reclaiming the instance’s memory.

Since there are no false references in ABAP, Jerry does not expand the narrative.

I hope this article has given you an overview of the design and function of two types of ABAP references: strong and weak, as well as two other types of references that exist in programming languages like Java: soft and virtual. Thanks for reading.

For more of Jerry’s original articles, please follow the public account “Wang Zixi “: