Bare Metal JavaScript: The JavaScript Virtual Machine

Inspecting Inline Caches with Deopt Explorer

Miško Hevery

Miško Hevery

Qwik Creator (Previously Angular)
Bare Metal JavaScript: The JavaScript Virtual Machine

Check out a free preview of the full Bare Metal JavaScript: The JavaScript Virtual Machine course

The "Inspecting Inline Caches with Deopt Explorer" Lesson is part of the full, Bare Metal JavaScript: The JavaScript Virtual Machine course featured in this preview video. Here's what you'd learn in this lesson:

Miško demonstrates using deopt explorer to analyze JavaScript code, highlighting various aspects such as inline caches, deoptimizations, and object shapes The significance of monomorphic and polymorphic reads in optimizing code execution is also discussed in this segment.


Transcript from the "Inspecting Inline Caches with Deopt Explorer" Lesson

>> If you load this code again, inside of these awesome tool, notice he talks about functions ICs. These are called inline caches. The optimizations which we kind of talked about earlier, maps, which we'll talk about and profiling is just the amount of time spent in different locations. So let's look into the inline caches.

And let's look at our function. Okay, so let's look at our code here. Why is this actually red? That's a good question. Insufficient type feedback. It's, okay. Anyways, so this is your code, and notice how it gets color-coded, right? Certain things are green. Certain things are red, etc.

So for example, this timer is red, and it surprises me, it's complaining about some information. I think, I don't fully understand this. I think this is complaining about the fact that for the majority of time, it sees this thing only return true, and it never sees it return false.

And so it's like, I think bad things will happen when it returns false, and so I don't know how to optimize it. Which kind of makes sense because like it's a timer it usually returns true and only once returns false and never runs again, right. But notice that the array dot length is green what it means is that every time we got here the the hidden class ID was right here this is the hidden class ID for the array.

And you can actually click on this. It basically shows you like, hey, this hidden class ID was an array. And it had all of these properties on it and one of these properties should be linked somewhere. It isn't like this special, so maybe the length is not here.

But anyway, this talks about your object that you had In here right this is the array. This is not our objects is the array itself. And because array instance is always the same everywhere, array dot length is is an inline cashable items. So this is green, the system's like yep, I can get this value, no problem.

I never have issues with it, because every time I run the code array the hidden class for the array is always the same and therefore I know exactly where the length is, okay? And so now we're running over array one, so this contains always the same hidden class right.

And so when we do a dot value over here if I hover over it, it says, look, this is monomorphic. Every time I ran this code, I've always seen the same exact object. And I can click on this object and this object will click on it. Let me zoom into it.

Come on, escape. And this object always had property 0. It says it was of unknown type. I don't know why it's saying that, but it says this particular object that I've ever seen always had property 0. And in here, I've always gotten the same object, therefore I know exactly what the offset into the array is, and that's a fast access, right?

Now if I go to the second benchmark, we're going over array 2, and so now we know two different things in here, right. And again, the length is always green, right? Because the array instance is always the same hidden class. The shape of the array is always the same, right?

Cuz all arrays in the system have the same shape unless you start micing with prototypes. Don't do that. That has another bad benefit. But notice now, this isn't green, it's yellow. All right, so this box right here is yellow. And so if you hover over it, it says, originally I saw this value, but then sometimes I saw this other value.

So now I have two different things. So sometimes I saw something that had prop 1 on it and sometimes I saw something that had prop 0 on it. So now basically it's saying I saw two different objects on this particular thing. Actually, this is wrong, they should also say that there's a value on this as well.

I think there's a bug with the tool. So this tool should say it has value 0 and prop 0 and value 0 and prop 1, okay. But the point here is that you can see the shapes here. It's telling you what these things are. This is basically the memory location where the hidden class used to be stored so the VM could do these operations.

And so we know that in this particular case, we can still have an inline cache, even if it's 2, and we can see the same thing here. Notice there's three things in here now. We see the same thing here. Now there's 4 things in here now, right? Notice now it goes red.

It basically says we didn't know what it was, it became monomorphic. Then it became polymorphic. Then it was polymorphic in the department for some kept increasing. And then we gave up and said, screw this. This is mega morphic. We don't know what to do. And so we're gonna do the slow path over here.

In the code, it manifests itself as a red-read. It basically the tool is telling you like, this thing is slow. If you can make this thing somehow go faster if you can fix this problem, I can go faster, right. And so you can see just by looking at the tool which particular property reads are problematic, right?

So this is problematic and goes all the way down to here. All of these things are problematic values, right? Make sense? And as I said, the cool thing is that you can actually go and explore this. So inside of your explorer, you can see that there were lots of megamorphic reads because we created a lot of different properties.

And you can see where these things are. So for example, this one, it says, this is the worst offender right here. And of course, we know that's the worst offender. We designed it that way, right? You can see where monomorphic reads are. So for example, it says, this length property is monomorphic, right?

So you can kind of zoom in on all of these functions and you can kind of look around and say hey what's going on here? So in this particular function this benchmark one function, why is it so slow okay? This benchmark one function which is right here everything is green so it should basically come up with everything being monomorphic you see mono meaning one morphism, one shape, right?

Everything in here is green because everything is monomorphic. That's what you wanna see. And when you see the things that are not green, that's kind of a bad thing. So this is kind of a nice tool to kind of explore. These tools existed before. About a year ago, the released is Dopt explore and I think it makes a huge difference because it puts a nice UI, and you can go around and explore.

You could have always open this log files and generate, these log files, most people didn't know about the special instructions, and if you were determined enough, you could go to figure out what's going on. But this UI tool really makes it super, super nice to go over.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now