What are the 'shadow$_klass_' and 'shadow$_monitor_' variables for in java.lang.Object?

JavaAndroidAndroid 5.0-LollipopArt Runtime

Java Problem Overview


In the latest Android update (SDK 21), it appears that two new variables have been added to java.lang.Object:

private transient Class<?> shadow$_klass_;
private transient int shadow$_monitor_;

I notice that shadow$_monitor_ is briefly used in hashCode():

public int hashCode() {
    int lockWord = shadow$_monitor_;
    final int lockWordMask = 0xC0000000;  // Top 2 bits.
    final int lockWordStateHash = 0x80000000;  // Top 2 bits are value 2 (kStateHash).
    if ((lockWord & lockWordMask) == lockWordStateHash) {
        return lockWord & ~lockWordMask;
    }
    return System.identityHashCode(this);
}

But otherwise there are no references to them. Are they somehow related to GC in ART? Or some sort of native stuff?

Java Solutions


Solution 1 - Java

They are indeed connected to GC. They seem to have been added in order to support Brooks pointers. I found some information on Brooks pointers here:

> The idea is that each object on the heap has one additional reference field. This field either points to the object itself, or, as soon as the object gets copied to a new location, to that new location. This will enable us to evacuate objects concurrently with mutator threads

See especially these two commits:

libcore: a7c69f785f7d1b07b7da22cfb9150c584ee143f4

art: 9d04a20bde1b1855cefc64aebc1a44e253b1a13b

Solution 2 - Java

These are classes related to Shenandoah Garbage Collection in JDK.

There are 4 older GC in OpenJDK Serial,Parallel,Concurrent Mark Sweep, & G1. Yet the problem with these lie in the fact that they need to compact the entire old heap atleast once & if the heap is large, this will be very heavy. Shenandoah is designed with <10ms pauses for 100Gb+ heaps.

This is achieved by using Forwarding Pointers based on Brooks Pointers.The shadow_$klass & shadow$_monitor are these forwarding pointers.

The primary idea in Shenandoah GC, is that it allows application threads to interact with objects in heap while they're being moved around during compacting (moving referenced objects to a better location), removing the need to "stop-the-world"

Look at this other SO answer: Brooks Pointer in Object class

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionTspoonView Question on Stackoverflow
Solution 1 - JavaPetterView Answer on Stackoverflow
Solution 2 - JavaChandrahas ArooriView Answer on Stackoverflow