vlax-release-object...cont'd

Anonymous · ‎09-26-2001

Some questions arise from R. Robert Bell's 9/18 post on releasing objects.
I'll start with only one to see if there's still interest in this topic.

For background here is the text from the Developer's Guide on releasing
objects...

Just as you can have different variables pointing to the same AutoCAD
entity, you can have multiple VLA-objects pointing to the same drawing
object. You can compare two VLA-objects with the equal function, which
returns T if both objects point to the same drawing object.
As long as a VLA-object points to a drawing object, AutoCAD will keep all
the memory needed for the object. When you no longer need to reference an
object, use the vlax-release-object function to indicate this to AutoCAD:

(vlax-release-object object)

After releasing an object, it is no longer accessible through the VLA-object
pointer. This is similar to closing a file. No memory is necessarily freed
when you issue vlax-release-object, but AutoCAD can reclaim the memory if
needed, once all references to the object have been released.
To test whether or not an object has been released, use the
vlax-object-released-p function:

(vlax-object-released-p object)

This function returns T if the object has been released, nil if it has not.
...

Question; if a variable is set to nil (or declared local) but not released
via vlax-release-object, does this have the same effect as releasing the
object? If not what happens when a pointer is set to nil without releasing
the object first? Help says that the object is no longer accessible through
the pointer when released so if the pointer is set to nil it has no access
either. To see what happens to the pointer when an object is released I ran
this little function:

(defun c:rel ( / acad)
(setq acad (vlax-get-acad-object))
(PRINC "\nacad = ") (PRINC acad)
(vlax-release-object acad)
(PRINC "\nreleased = ") (PRINC (vlax-object-released-p acad))
(PRINC "\nacad = ") (PRINC acad)
(princ)
)

acad = #
released = T
acad = #

...which shows that the pointer "exists" (it's not nil) after the release
but doesn't point to anything.

Anyone want to do a discourse on ActiveX objects?
--

Cliff

Anonymous · ‎09-27-2001

I once dit some tests with an automation server written in Delphi : in the
destroy method of the automation objects I added a line of code to give a
beep. That way I could find out when exactly and if the objects were
destroyed.
When I set an object reference to nil, without calling vlax-release-object
on it, the beep came only when I closed down AutoCAD.
This seems to confirm what you write here.

Frank Oquendo wrote in message
news:71EDE8FA31F1AF9541D26B41CFADFC5E@in.WebX.maYIadrTaRb...
> In order to mark the memory being used by a VLA object as reclaimable,
> it must be explicitly released. Otherwise, it's lost until you restart
> AutoCAD.
>

Anonymous · ‎09-27-2001

Making a VLA-object local is no guarantee that AutoCAD will reclaim
unused memory. You must bind a VLA-object reference to a symbol and
call vlax-release-object against that symbol. Any other combination
locks up RAM until AutoCAD is shut down.

--
"That's no ordinary rabbit."
http://www.acadx.com

Visit my site for a chance to win
a free, autographed copy of
Jerry Winters' "AutoCAD Visual Basics"

"John Uhden" wrote in message
news:E4806896CAC290E580455523C70B7E62@in.WebX.maYIadrTaRb...
> I'll take a chance on disagreeing with you.
>
> From the help on vlax-object-released-p:
>
> "NOTE Erasing a VLA-object (using command ERASE or vla-erase) does
not
> release the object. A VLA-object is not released until you either
invoke
> vlax-release-object on the object, normal AutoLISP garbage
collection
> occurs, or the drawing database is destroyed at the end of the
drawing
> session."
>
> Notice the garbage collection phrase. Strikes me that either using
a
> fuction with local variables bound to the VLA-OBJECT, or setting the
symbol
> nil followed by a forced (gc) should free up the memory.
>
> BTW, I found that the memory usage is per namespace. I can release
an
> object in the drawing namespace, without affecting its status in the
> separate namespace.
>
> --
> John Uhden, Cadlantic/formerly CADvantage
> --> mailto:juhden@cadlantic.com
> --> http://www.cadlantic.com
> 2 Village Road
> Sea Girt, NJ 08750
> Tel. 732-974-1711
> FAX 732-528-1332
>
> "Frank Oquendo" wrote in message
> news:71EDE8FA31F1AF9541D26B41CFADFC5E@in.WebX.maYIadrTaRb...
> > In order to mark the memory being used by a VLA object as
reclaimable,
> > it must be explicitly released. Otherwise, it's lost until you
restart
> > AutoCAD.
>
>
>

Anonymous · ‎09-27-2001

| Why would there be no pointer?

For instance in a function like this. The application and the menugroups
objects are created (opened?) and so what happens to them after the load
function is done?

(defun mnu:Load (fullname)
(vla-load (vla-get-menuGroups (vlax-get-acad-object)) fullname)
)
--
Cliff

Anonymous · ‎09-27-2001

Might you have something we can use to prove that? Perhaps the (mem)
function?

--
John Uhden, Cadlantic/formerly CADvantage
--> mailto:juhden@cadlantic.com
--> http://www.cadlantic.com
2 Village Road
Sea Girt, NJ 08750
Tel. 732-974-1711
FAX 732-528-1332

"Frank Oquendo" wrote in message
news:65BC4DA2E9031BB298B0E26DD074E928@in.WebX.maYIadrTaRb...
> Making a VLA-object local is no guarantee that AutoCAD will reclaim
> unused memory. You must bind a VLA-object reference to a symbol and
> call vlax-release-object against that symbol. Any other combination
> locks up RAM until AutoCAD is shut down.

Anonymous · ‎09-27-2001

I never stopped to realize that. Always been interested in just the values.
Now this release thing is just starting to make sense. It's all in the
pointers. But I still want to know if the alleged (gc) function will
release the object of a nilled symbol, nor do I know how to find out for
sure.

--
John Uhden, Cadlantic/formerly CADvantage
--> mailto:juhden@cadlantic.com
--> http://www.cadlantic.com
2 Village Road
Sea Girt, NJ 08750
Tel. 732-974-1711
FAX 732-528-1332

"Cliff Middleton" wrote in message
news:27D2416A7ED79E66C61D420EDF4DA62E@in.WebX.maYIadrTaRb...
> This makes sense because b is a. (setq b (eval a)) is the same as (setq b
> a).

Anonymous · ‎09-27-2001

Read Guido's post.

--
"That's no ordinary rabbit."
http://www.acadx.com

Visit my site for a chance to win
a free, autographed copy of
Jerry Winters' "AutoCAD Visual Basics"

"John Uhden" wrote in message
news:96390217ACE2BB3664C1F1167BF0CFC5@in.WebX.maYIadrTaRb...
> Might you have something we can use to prove that? Perhaps the
(mem)
> function?

Anonymous · ‎09-27-2001

I wonder, could you repeat that test adding (gc) after setting the reference
to nil?
--
Cliff

"Guido Rooms" wrote in message
news:BC07A326524B731F00CFD4FABFFE419D@in.WebX.maYIadrTaRb...
| I once dit some tests with an automation server written in Delphi : in the
| destroy method of the automation objects I added a line of code to give a
| beep. That way I could find out when exactly and if the objects were
| destroyed.
| When I set an object reference to nil, without calling vlax-release-object
| on it, the beep came only when I closed down AutoCAD.
| This seems to confirm what you write here.

Anonymous · ‎09-27-2001

| But I still want to know if the alleged (gc) function will
| release the object of a nilled symbol, nor do I know how to find out for
| sure.

The passage from help that you cite elsewhere in this thread seems to
indicate that yes, it would.

Anonymous · ‎09-27-2001

But Frank O. is saying that it isn't released. Don't you just love academic
arguments!
I was just messing with (setq a (vlax...)) then (mem) then (seta a nil)(gc)
then (mem). The (gc) appears to be freeing up memory, but who knows
where/if (mem) is reporting the object pointer memory.

--
John Uhden, Cadlantic/formerly CADvantage
--> mailto:juhden@cadlantic.com
--> http://www.cadlantic.com
2 Village Road
Sea Girt, NJ 08750
Tel. 732-974-1711
FAX 732-528-1332

"Cliff Middleton" wrote in message
news:8604F4536E82D7E49CB6E7FB8C0D6EDB@in.WebX.maYIadrTaRb...
> | But I still want to know if the alleged (gc) function will
> | release the object of a nilled symbol, nor do I know how to find out for
> | sure.
>
> The passage from help that you cite elsewhere in this thread seems to
> indicate that yes, it would.

Anonymous · ‎09-27-2001

Anonymous · ‎09-27-2001

"Cliff Middleton" writes:

> As long as a VLA-object points to a drawing object, AutoCAD will keep all
> the memory needed for the object. When you no longer need to reference an
> object, use the vlax-release-object function to indicate this to AutoCAD:

Then, why are we using Lisp? I mean, you shouldn't
worry about releasing memory using Lisp. The
garbage colector should worry about it.

IMHO Autodesk has screwed us with this
autolisp-activex thing. They could extend autolisp
to deal with new features/capabilityes in a
lispish way, but they decide to push a half-baked,
VBA-translated & undocumented implementation down
our throat. Now you are paying it.

--

Eduardo Muñoz

Anonymous · ‎09-27-2001

Well, I bit the bullet and ran some memory tests.

I created a drawing that had 100 layers. I ran a loop 1,000,000 times
binding the Layers collection to a variable, then clearing the variable,
(setq objLayers nil), and saw *no* memory hit. This was even without an
explicit (gc)!

(setq objDoc (vla-Get-ActiveDocument (vlax-Get-Acad-Object)))
(repeat 1000000
(setq
objLayers (vla-Get-Layers objDoc)
objLayers nil
)
)

--
R. Robert Bell, MCSE
http://www.acadx.com

"R. Robert Bell" wrote in message
news:FFF38D12A2C58891FFE3CB8FA468EAE8@in.WebX.maYIadrTaRb...
| "Cliff Middleton" wrote in message
| news:61DC44F1D41B21B3316685B2C7DE2A63@in.WebX.maYIadrTaRb...
| | Question; if a variable is set to nil (or declared local) but not
released
| | via vlax-release-object, does this have the same effect as releasing the
| | object? If not what happens when a pointer is set to nil without
| releasing
| | the object first? Help says that the object is no longer accessible
| through
| | the pointer when released so if the pointer is set to nil it has no
access
| | either. To see what happens to the pointer when an object is released I
| ran
| | this little function:
| |
|
| That is a question that I think only Autodesk's programmers can answer. I
| thought I might monitor memory usage in AutoCAD when allowing a bound
| variable to go out of scope without releasing the object, but could not
| reliably determine the effect.
|
| I do know that some other programmers have run into trouble getting out of
| AutoCAD if the ActiveDrawing or Application object are still bound.
|
| And I can echo Luis' comments regarding hybrid code. I'm in a world of
hurt
| over this issue...
|
|

Anonymous · ‎09-27-2001

I just ask to me this question why not any programmer from AutoDesk do not
answer this.

Or they don't know.

Anonymous · ‎09-27-2001

Just because the question is unanswered, no one may have screwed up nor may
we be paying any price. I think that nil and (gc) take care of these "witch
hunt" problems, as stated in the vlax-object-released-p help (maybe it's
actually correct and that Adeskers are just watching without chiding us with
"RTFM"). We just have to get Frank to either give in a little or show us I'm
wrong.

--
John Uhden, Cadlantic/formerly CADvantage
--> mailto:juhden@cadlantic.com
--> http://www.cadlantic.com
2 Village Road
Sea Girt, NJ 08750
Tel. 732-974-1711
FAX 732-528-1332

"Eduardo Muñoz" wrote in message news:uwv2kw9mm.fsf@jet.es...
> "Cliff Middleton" writes:
>
> > As long as a VLA-object points to a drawing object, AutoCAD will keep
all
> > the memory needed for the object. When you no longer need to reference
an
> > object, use the vlax-release-object function to indicate this to
AutoCAD:
>
> Then, why are we using Lisp? I mean, you shouldn't
> worry about releasing memory using Lisp. The
> garbage colector should worry about it.
>
> IMHO Autodesk has screwed us with this
> autolisp-activex thing. They could extend autolisp
> to deal with new features/capabilityes in a
> lispish way, but they decide to push a half-baked,
> VBA-translated & undocumented implementation down
> our throat. Now you are paying it.
>
>
>
> --
>
> Eduardo Muñoz

Anonymous · ‎09-27-2001

As if I'm the last word in VisualLISP programming. My opinion is
simply this: if I explicitly release an object, there is no question
concerning memory usage.

Code as you will, John.

--
"That's no ordinary rabbit."
http://www.acadx.com

Visit my site for a chance to win
a free, autographed copy of
Jerry Winters' "AutoCAD Visual Basics"

"John Uhden" wrote in message
news:F98B5ACFE0F2BD708197BD50A7025DEF@in.WebX.maYIadrTaRb...
> Just because the question is unanswered, no one may have screwed up
nor may
> we be paying any price. I think that nil and (gc) take care of
these "witch
> hunt" problems, as stated in the vlax-object-released-p help (maybe
it's
> actually correct and that Adeskers are just watching without chiding
us with
> "RTFM"). We just have to get Frank to either give in a little or
show us I'm
> wrong.
>
> --
> John Uhden, Cadlantic/formerly CADvantage
> --> mailto:juhden@cadlantic.com
> --> http://www.cadlantic.com
> 2 Village Road
> Sea Girt, NJ 08750
> Tel. 732-974-1711
> FAX 732-528-1332
>
> "Eduardo Muñoz" wrote in message
news:uwv2kw9mm.fsf@jet.es...
> > "Cliff Middleton" writes:
> >
> > > As long as a VLA-object points to a drawing object, AutoCAD will
keep
> all
> > > the memory needed for the object. When you no longer need to
reference
> an
> > > object, use the vlax-release-object function to indicate this to
> AutoCAD:
> >
> > Then, why are we using Lisp? I mean, you shouldn't
> > worry about releasing memory using Lisp. The
> > garbage colector should worry about it.
> >
> > IMHO Autodesk has screwed us with this
> > autolisp-activex thing. They could extend autolisp
> > to deal with new features/capabilityes in a
> > lispish way, but they decide to push a half-baked,
> > VBA-translated & undocumented implementation down
> > our throat. Now you are paying it.
> >
> >
> >
> > --
> >
> > Eduardo Muñoz
>
>

Anonymous · ‎09-27-2001

ActiveX (rather COM) is designed as a reference counted memory handling
environment. COM objects delete themselves when they are good and ready --
the client has no direct control over this by design. The client can
*release* the object (aka reduce its reference count by 1) but it cannot
delete it. It's likely that many objects delete themselves when their
reference count goes to zero, but this is totally up to the object.
Furthermore, there is no requirement for *when* the object deletes itself;
most objects do not delete themselves as soon as their reference count goes
to zero -- rather they wait until the next idle time processing cycle, or
maybe stick around for a while in case they are needed again. What this
means is you can't reliably test for when it's deleted by making assumptions
that things happen in a linear order.

I don't know enough about ActiveX to conclusively tell you when you should
and should not explicitly release an object, but I'm quite confident that
you shouldn't have to release an object explicitly if it's only used
temporarily as part of a longer expression. That doesn't mean you can count
on the object being deleted at any specific time -- the point of COM is that
you the client aren't *supposed* to rely on or make any assumptions about
when the object is deleted. The object itself (with the help of COM) will
do what it thinks is best.

My gut feeling is that explicitly releasing an object should only be done
selectively where you really need to override the default behavior for a
specific purpose (and note that *releasing* an object is not the same thing
as *deleting* it). That said, it's entirely possible that Autodesk's
implementation of some objects causes the default behavior to work
unreliably, and leads to crashes. In other words, trial and error is the
only way to figure out what works. 🙂
--
Owen Wengerd
President, ManuSoft ==> http://www.manusoft.com
VP Americas, CADLock, Inc. ==> http://www.cadlock.com

Anonymous · ‎09-27-2001

Wow! Thanks, Owen. No offense, but it actually makes sense.

--
John Uhden, Cadlantic/formerly CADvantage
--> mailto:juhden@cadlantic.com
--> http://www.cadlantic.com
2 Village Road
Sea Girt, NJ 08750
Tel. 732-974-1711
FAX 732-528-1332

"Owen Wengerd" wrote in message
news:BCB646CF4FE290F8C71FCCBE0684573F@in.WebX.maYIadrTaRb...
> ActiveX (rather COM) is designed as a reference counted memory handling
> environment. COM objects delete themselves when they are good and
ready --
> the client has no direct control over this by design. The client can
> *release* the object (aka reduce its reference count by 1) but it cannot
> delete it. It's likely that many objects delete themselves when their
> reference count goes to zero, but this is totally up to the object.
> Furthermore, there is no requirement for *when* the object deletes itself;
> most objects do not delete themselves as soon as their reference count
goes
> to zero -- rather they wait until the next idle time processing cycle, or
> maybe stick around for a while in case they are needed again. What this
> means is you can't reliably test for when it's deleted by making
assumptions
> that things happen in a linear order.
>
> I don't know enough about ActiveX to conclusively tell you when you
should
> and should not explicitly release an object, but I'm quite confident that
> you shouldn't have to release an object explicitly if it's only used
> temporarily as part of a longer expression. That doesn't mean you can
count
> on the object being deleted at any specific time -- the point of COM is
that
> you the client aren't *supposed* to rely on or make any assumptions about
> when the object is deleted. The object itself (with the help of COM) will
> do what it thinks is best.
>
> My gut feeling is that explicitly releasing an object should only be
done
> selectively where you really need to override the default behavior for a
> specific purpose (and note that *releasing* an object is not the same
thing
> as *deleting* it). That said, it's entirely possible that Autodesk's
> implementation of some objects causes the default behavior to work
> unreliably, and leads to crashes. In other words, trial and error is the
> only way to figure out what works. 🙂
> --
> Owen Wengerd
> President, ManuSoft ==> http://www.manusoft.com
> VP Americas, CADLock, Inc. ==> http://www.cadlock.com
>
>

Anonymous · ‎09-27-2001

Fair enough, Frank. Thanks for helping us to be more aware.

--
John Uhden, Cadlantic/formerly CADvantage
--> mailto:juhden@cadlantic.com
--> http://www.cadlantic.com
2 Village Road
Sea Girt, NJ 08750
Tel. 732-974-1711
FAX 732-528-1332

"Frank Oquendo" wrote in message
news:1B67232CFA760CFF51CFFF022BEE8523@in.WebX.maYIadrTaRb...
> As if I'm the last word in VisualLISP programming. My opinion is
> simply this: if I explicitly release an object, there is no question
> concerning memory usage.

Anonymous · ‎09-27-2001

Thank you for the primer, Owen. I am glad you stopped by.
--
Cliff

Anonymous · ‎09-27-2001

"Eduardo Muñoz" wrote in message news:uwv2kw9mm.fsf@jet.es...
| "Cliff Middleton" writes:
|
| > As long as a VLA-object points to a drawing object, AutoCAD will keep
all
| > the memory needed for the object. When you no longer need to reference
an
| > object, use the vlax-release-object function to indicate this to
AutoCAD:
|
| Then, why are we using Lisp? I mean, you shouldn't
| worry about releasing memory using Lisp. The
| garbage colector should worry about it.

Well, at least the old way of doing things is still intact. We don't HAVE
to use COM objects.

|
| IMHO Autodesk has screwed us with this
| autolisp-activex thing. They could extend autolisp
| to deal with new features/capabilityes in a
| lispish way, but they decide to push a half-baked,
| VBA-translated & undocumented implementation down
| our throat. Now you are paying it.

Still, it beats manual drafting (or a stick in the eye:). Like my old
machine shop teacher used to say when we would complain about our situation,
"You bought your ticket, you take your ride".
--
Cliff

vlax-release-object...cont'd

Forums Links

Post to forums