ASP - Terminating objects in memory

[Lauren the Ravishing]

Hi,

In ASP, is it absolutely necessary to set an object to Nothing after
being used?

set myObj = server.createObject("myDLL.myClass")
call myObj.useClass
set myObj = Nothing <--- can I omit this?

I'm dealing with a large number of files with nested includes. There
are many places where I use the object, I want to avoid initializing
the object any more than necessary, and I want to change as few pages
as possible. The simplest way for me to do this is to not set the
object to nothing. Will ASP implicitly remove the object from memory,
or will I have a memory leak?

~ L

 

[Anthony Jones]

Hi,

In ASP, is it absolutely necessary to set an object to Nothing after
being used?

set myObj = server.createObject("myDLL.myClass")
call myObj.useClass
set myObj = Nothing <--- can I omit this?

I'm dealing with a large number of files with nested includes. There
are many places where I use the object, I want to avoid initializing
the object any more than necessary, and I want to change as few pages
as possible. The simplest way for me to do this is to not set the
object to nothing. Will ASP implicitly remove the object from memory,
or will I have a memory leak?

~ L

ASP will implicitly call the release method on any interface pointer
currently held by a variable when it passes out of scope. This includes
when the script has completed resulting in the script context being reset.

Not using set to nothings will not, of itself, introduce a memory leak.
However there is no harm in using set to nothing either and some developers
consider it good practice (I'm not one of them though).

Anthony.

 

[Mike Brind]

ASP will implicitly call the release method on any interface pointer
currently held by a variable when it passes out of scope. This includes
when the script has completed resulting in the script context being reset.

Not using set to nothings will not, of itself, introduce a memory leak.
However there is no harm in using set to nothing either and some developers
consider it good practice (I'm not one of them though).

Why is it considered "good practice" by some?

 

[Bob Barrows [MVP]]

Why is it considered "good practice" by some?

Some of the reasons I've seen cited include:

1. Being in control of when objects are created and released - this is the
one I used to see most often in the "x tips for writing code" lists I used
to read in books and on the web.The upshot being that one could not consider
oneself to be a "good" programmer if this level of control was not retained.
This tip was usually about the recommendation against using the VB "dim x as
new object" syntax, but many authors included the requirement to always
explicitly destroy objects when no longer needed. I read this so often that
it did become ingrained.
2. Self-documentation: it's easy to see when one is finished using the
object
3. Resource management: releasing large-footprint objects from memory at the
first opportunity can't be bad.
4. Various bugs related to the failure to set objects to nothing have been
documented - these bugs typically involve child objects where the order of
releasing them is important (DAO and ADO), and memory leaks have been
reported, to the point where IIS stops responding.
5. Distrust of the automatic garbage collector (GC) - given the existence of
the various bugs, distrust did develop and combined with the need for
control nentioned in 1, the use of the set x=nothing became ingrained for
many of us.

 

[Anthony Jones]

Why is it considered "good practice" by some?

I think Bob pretty much covered it. The main driver for this whole 'you
should set to nothing' business is bugs in the first versions of ADO. If you
didn't release references to related connection, command and recordset
object in a specific order you could leak memory. Whilst VB(5|6|A|Script)
guarantees to release out of scope references it doesn't guarantee the order
in which it will release them. So the workround to this bug was to release
them yourself in the order needed to avoid the affects of the bug.

This lead to a common myth that VB can't be trusted to release references so
therefore you must do them yourself.

 

[Janette]

Hi,

So is the myth that vbscript can't be trusted in the order it releases
memory, and therefore having the potential to cause a memory leak, which can
bring IIS to a halt, likely to be still be an issue for vbscript running in
an ASP page in Windows 2000 in IIS 5?

If so, what kind of errors what you expect to get as IIS freezes up, and are
there any performance monitors that you could use to detect that it is
happening?

Thanks
Janette

Why is it considered "good practice" by some?

I think Bob pretty much covered it. The main driver for this whole 'you
should set to nothing' business is bugs in the first versions of ADO. If
you
didn't release references to related connection, command and recordset
object in a specific order you could leak memory. Whilst VB(5|6|A|Script)
guarantees to release out of scope references it doesn't guarantee the
order
in which it will release them. So the workround to this bug was to
release
them yourself in the order needed to avoid the affects of the bug.

This lead to a common myth that VB can't be trusted to release references
so
therefore you must do them yourself.

 

[Anthony Jones]

Hi,

So is the myth that vbscript can't be trusted in the order it releases
memory, and therefore having the potential to cause a memory leak, which can
bring IIS to a halt, likely to be still be an issue for vbscript running in
an ASP page in Windows 2000 in IIS 5?

Not quite sure what you are saying or asking.

The order in which memory itself is released is not going to cause a leak.
Bugs of this form are invariably found in the components being used by the
ASP pages rather than in ASP/VBScript itself.

If so, what kind of errors what you expect to get as IIS freezes up, and are
there any performance monitors that you could use to detect that it is
happening?

Set your application protection to high (isolated)
Process -> Virtual Bytes (Choose the DLLHOST instance that represents the
application that your having a problem)

If this continues to grow progressively then that would indicate a leaky
app.

This may also be useful:-

Asp Server Pages -> Request Executing

If this grows it can show hung Requests once this uses up the available
threads the site will hang.
This is likely caused by using a COM component not designed for use in
unattended mutlithreaded apps.
For example a component which attempt to alert the user to problem via a
message box will just hang the thread.

Thanks
Janette

 

[Janette]

Hi Anthony,

Thanks for the information. One more question, how do you identify what a
dllhost instance is associated with?

Thanks
Janette

 

[Anthony Jones]

Hi Anthony,

Thanks for the information. One more question, how do you identify what a
dllhost instance is associated with?

It's a bit of a messy. First fire up Component Services from Administrative
tools, expand the tree down to COM+ applications and select that node. In
the tool bar select Status View. The list of COM+ application names should
contain an application called IIS-{...} where the contents of {} is
recognizable to you as your application. (This assumes you have set
application protection to high). The PID column shows the process ID of the
DLLHOST.exe process that is running your web app.

In performance monitor add a counter: Choose the Process performance object,
select the ID Process counter (which is a static value that will match the
PID and select the first DLLHOST in the instances list. ID Process doesn't
match the PID delete the counter and add a counter for the next DLLHOST#1 in
the list and so on until find the one that has a matching PID. Now add the
counters you want to monitor against that instance.