[Autogenerated] Let's see how many handles.
We can create in the process, and also see some of the effects of having.
So, many handles.
So we're going to create a console application here like always.
So that's going to be a mac handle, that could be the name of the project here.
Let's call the solution demos, and click create,
I'm going to Usually remove the boiler plate,
code here.
So we can put our own code So first, I'm going to add,
an code four Windows dot page to get everything we need in terms of Windows
API I S and then We'll start doing our testing So in fact,
we can create maximum number of handler in two ways.
Let's start with the first way.
And The first way would be to create a kernel object or kernel object,
to be more precise as many as we possibly can.
So I'm going to have a counter here.
And have an infinite loop I'm going to Go ahead.
And create an object such as a mute, ax,
and It doesn't matter in this case,
what kind of object I'm creating as long as I'm creating
a kernel object where I can get back, a handle.
So we'll start with the tex and see if what happens if you
replace that with something perhaps different.
So if it fails the handle, to the Tex, is returned as null,
and we can break out of this loop otherwise we can in increase the count here.
And fi Finally, we can write the total here as number of handles.
We managed uh to get, I'm going to add, an code for STD,
io for this purpose as well.
To be able to use the print ef function,
and in the main function, I'm going to call test one,
and then I'm going to Just make sure.
That the process doesn't close because we want to make sure the handles.
Are kept open while we examine the results.
I'm just going to use, get S here.
To force.
Waiting until the user presses the enter key.
So that should be good enough.
Let's build that and take a Look at task manager
while we're doing the test here.
So if you look at task manager, we can see certain things,
let me just hide some columns that are Not interesting at this point.
Let's look at the number of handles.
I'm going to select, columns here, and add handles here as the possible column.
Let's find that Here it goes.
And you, can see that Currently, we have a number of handles for every process.
Let be sort by handles, and Currently,
you can see that The system process has 4000 handles explored next,
has 2900 something handles.
So we're talking about handles.
In the thousands as the common case here for many of these processes,
that consume lots of handles.
So let's run this and See what happens while it's running let press control,
a five here, and You know this number of handles here in mac handles,
is growing very rapidly.
And Eventually it's going to stop,
and You notice the total report by the application.
Is 60,000,711 631 which is a bit lower than the actual maximum
in the process which is 16,000,711 and 680 handles.
Why do We see less number of handles.
In the output simply because some handles existed.
In the process even before we started actually
creating those mute access So in fact,
this number 60 million 711 and 680 handles,
is the maximum handles you can create in a process
which obviously is pretty a lot.
So we shouldn't really run out of handles.
In the First place.
What about the memory consumption associated with these handles.
So for that I'm going to add another column,
and that column,
is called page pull it's going to Show me the page pull consumption,
which is normal kernel memory um in that is attributed to This process.
In this case, this is where the actual handle uh entries,
are going, to be allocated from.
Let me see if I can find it.
Uh page pool So that's the one I missed.
That Uh At first you can see the page pull here,
is roughly 256 mega bytes and If you divide that by
60 bytes As we've seen earlier, in the slide,
then We get roughly these 16 million something handled.
So it actually proves that This actually works.
In the way, that we described.
Let me close.
That and run this again.
Notice it takes some time for the process.
To close because it now needs to kill 60 million mute,
access Let me run this again.
And see these things growing, and We'll take a look at object explore as well.
So I'm running this again.
Notice number of handles grows,
and same goes for the page pull in the Same way as we've seen earlier.
Going to object explorer.
Here, you'll notice that in terms of objects types.
If you go back, to object types, and look at the maximum of objects here.
Notice we have many many Mutis now, in the system, 60 million something.
Mutti access because it's not just objects, it's also handles.
So we have 60 million handles.
And 60 million objects because we created each tex with its own handle.
So we created, in fact, many muti, access and So the result here,
is not just about handles for the handles.
We lost 256 mega bytes of page memory.
But in fact, we lost even more in terms of memory for these mute,
access going back, to task manager here,
let's go.
To these statistics here.
And Look at memory notice memory consumption here,
in the non page pool is 3.1 giga bytes If I go ahead,
and close this process,
you notice this memory will start to get lower very quickly.
And settle on some lower number.
Notice the drop in physical memory.
Why?
Is that the case going back, to object types here in object explore,
we can see that mutt, check are facts Let's just look here.
You can see the peak number of objects.
Is still maintained.
Of course, being this number of mut,
access Here it's going to be allocated from non page pool non executable So
this is a non page pool allocation for any kind of tex,
which means that When we allocate 60 million something,
Mutt, access we consume a lot of memory.
So here's the again running this notice the growth of the non
page pull and the physical memory in general.
Because non page pull is always in physical memory.
That's by definition, and Again,
you can see the growth here because of those 60 million something mut,
access we're actually creating right now.
So the memory consumption here, is big,
not really because of those handles but because of
the objects behind the handles.
Because in the this case,
we're creating one object for each one of these handles.
So we have lots of memory being consumed here.
And things could be even worse.
In the sense, that If we select something different,
not a Tex,
but something which might be bigger in terms of the size it
consumes in memory such as a job object,
a job object, for example,
is much bigger than a mu tax and If you use a job object here,
it doesn't matter from a handle perspective.
We're still going to get to the same maximum that we can have however,
might in fact run out of memory way before that because a job object,
is so big and it's also going to be allocated from non page
pull Notice the information here for jobs.
Let we find jobs.
So jobs also have these flag for non page non executable which means
that they are Also going to be allocated from non page pull But because
they are much bigger memory consumption will,
will skyrocket pretty quickly.
In fact, I may run out of memory completely before the 60 billion handles.
Is reached.
So notice the number of the memory consumption grows.
In a very, very high rate.
In fact, I'm out of physical memory at this point.
And paging, is Now happening.
And the page file might be might be extended,
but in fact, I might be completely running out of memory the system.
Is completely frozen.
I'm actually out of memory here.
Its its very difficult to kind of make forward progress,
notice, that I only get 23 million handles,
and the reason is that I've run out of memory,
that is just as simple as that because this particular system has only 16
gigabytes of ram and So we can't even create 16 million job objects without
running out of memory because these job objects.
Are always allocated from, from non page pull from non page memory,
which is always by definition in ram.
Now let's take another look at creating many handles.
But instead of creating many objects, let's just create one object.
And duplicate, that handle as many times as we possibly can.
We'll do that in the Next clip.