Hello, everyone. I’m the teacher who gave the people the nickname doug Tooth.

Let’s start with writing JVM classes. The enrollment of the first class of handwriting JVM has been completed. Thank you for your trust and support. It’s my job to make you look great, to make you the big shots people think you are. I will continue to optimize and upgrade courses for this purpose.

At present, there is no one in the market to teach this content, so there are still small partners to consult. The handwritten JVM class is implemented in two stages. The first stage is implemented in Java, and the second stage is implemented in C++. I predict that I can follow the first class if I sign up before the end of May, and then I can only follow the second class. If you want to register to learn to write JVM to implement your own Java virtual machine, at the same time master the ability of C++ development project partners can add my wechat: jvm-ziya.

Today’s question is from someone who has been badly abused during an interview. Don’t worry, I’ve calmed him down for trying to cut the interviewer down. Actually see this question, I still quite sigh: now the interview question has been difficult to this extent? This question requires a complete understanding of how the JVM implements OOP encapsulation. So, a word of advice: don’t make your resume Versailles. It brings attention and high expectations. The immediate result is to ask extremely difficult interview questions that will leave you in the dark at the beginning.

Problem analysis

So let’s look at this problem. If you want to know the underlying mechanism of how to access object instance properties, you need to know how they are stored. Storage understand, access is a matter of a word. Figuring out storage, however, is not a simple matter. The storage of object instance attributes in the JVM is even more complex than native C++ objects. Why do you say that? Back.

There are two important concepts for object-oriented typed languages: classes and objects. All information about a class is determined at compile time. But an object is a runtime structure, and its instance property information is not known until the constructor of the current method and its parent class has executed. In this case, you can define a list to store instance attributes of the object. The type of the instance attribute can be char, int, double, pointer… It seems that your T can only be received with an 8-byte data type to be compatible with all cases. The problem with this is that it wastes a lot of memory.

What about C++ and Java? Memory weaving. To paraphrase the term: weaving, in the abstract, means elaborating construction. Memory weaving, that is, fine structure memory. To save memory, an object is created by filling the memory with data of different types.

Why is the JVM’s object instance property storage mechanism more difficult than C++? The JVM has runtime data structures: arrays. What does that mean? That is, the meta-information for non-array classes is determined at compile time, while the meta-information for arrays is determined at run time; Second, the JVM has developed pointer compression techniques to save memory. One open and one close, two sets of mechanisms need to be studied; Third, in order to save more memory than C++, the JVM introduced the field rearrangement mechanism, which added to the difficulty of research.

OK! The problem has been analyzed and the difficulty has been basically determined. This article will only reveal the mystery, not cover everything. The rest is up to the competent and curious.

Instance property storage in C++

Comparison learning effect is better! Let’s look at how instance attributes are stored in C++

class Person {
private:
    short s;
    int i;
    long l;
};
Copy the code

This code generates an object that looks like this in memory, taking up 16B and wasting 2B

If I change the code, int goes under long, it’s completely different. It becomes 24 bytes, 10 bytes wasted.

As any expert knows, attributes should be defined according to the small byte type first and the large byte type later. Is it too much trouble? We don’t have to worry about this problem when we write Java code, the JVM has solved it for us by technical means. How did you solve it? Back.

Instance property storage in the JVM

The object memory model for the JVM is called the object memory model.

  1. When creating an object for attribute weaving, the object is knitted in the order of 8 bytes, 4 bytes, 2 bytes, 1 byte, and pointer. The pointer can be at the end, or at the front, and can be controlled by parameters. The default is last.
  2. Weaving brings together properties of the same type. So you don’t have to worry about the order in which the attributes are defined. This is a field rearrangement unique to the JVM. It’s not easy to implement, it’s a lot of thinking.

Again, the JVM object’s memory model looks like this

If the picture above is abstract, look at this one

Isn’t the JVM great? I love studying the JVM anyway, and the process really surprised me. Have to admire, compare with these big guy, I how bashful sleep! ^_^

Instance property access in the JVM

The JVM’s object memory model has been analyzed to provide an answer. There’s actually another problem here, which is that memory is stateless, so if I have two ints and I want to pick the second one, how do I know which one I’m picking? At this time, we need to find the class information of the object, find the property table stored in the class information, and then complete the value. The pseudo code

Property sheet = object. Property table Property address = Property table [int][1]Copy the code

conclusion

I am ziya teacher, like to delve into the bottom layer, in-depth study of Windows, Linux kernel, JVM. Like to share core knowledge, if you also like to study the bottom, like core knowledge, you can pay attention to my public number: hard nuclear teeth.