Smalltalk › Instantiations

GF/ST and GDI handles

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

jtuchel

GF/ST and GDI handles

Hi,

we're getting into deep trouble using GF/ST with VAST 8.02. After opening our figure a few dozen times, the Image is unresponsive and has to be shut down from the Task Manager. Looking at the GDI resources, we see that we reach 9999 or 10000 GDI handles.

As far as I understand the old Polymorphic documentation, the implementation of GFGraphicObject>>finalize should be sufficient to free GDI handles, but it seems that's not true (it simply calls self release). A System globalGarbageCollect or abtScrubImage dioes not free many GDI resources (maybe 40 or so, while each instance of the figure takes about 400 GDI handles, according to the Windows Task Manager).

Who has experiences with GF/ST and this GDI problem? What doe people do to clean up properly?

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/a6uaQyERPFAJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

John O'Keefe-3

Re: GF/ST and GDI handles

Joachim -

OK, I guess it's time to do something about finalization. Here is the current situation (don't shoot the messanger!):

Finalization only runs when the system is idle (see EsImageStartUp class>>#idleProcess) -- not exactly true, but close enough for this discussion.
The idle process loops, finalizing one weak object at a time, until the finalizeQueue is empty.
The finalizeQueue in a new image is initialize to hold 6 entries and its size is capped at about 1365 entries.
When the finalizeQueue is full, garbage collection can't put any more items onto the finalizeQueue until finalization is run.
When finalization is run:

It will notice that the finalizeQueue is getting full and grow it by 50% until the cap size is reached (see ProcessScheduler>>#finalizeCycle). So, it grows from 6 to 9 to 13 to 19 to ... (it takes a number of garbage collection cycles for the queue to grow to its maximum size).
It will remove one entry from the finalizationQueue.

This works OK in a system that is creating only a small number of weak objects -- GF/ST doesn't fall into this category.

So what can be done? I suggest:

Increasing the intial size of the finalize queue from 19 to 511 entries (> 25x the current initial size)
Increase the cap to 16384 entries (4x the current cap)

This does not address the issue (yet) of the need for both a garbage collet (to put weak object onto the queue) and idle tiem (to take them off), but it is a quick and easy way toinprove the management.

John

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/vEGQE7Q35sYJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: GF/ST and GDI handles

John,

I guess I wouldn't survive shooting you for very long, even if I wanted to (which I don't for several reasons) ;-)

Thanks for your insightful answer. I was somehow expecting an answer like: "you forgot to release GDI handles by sending xxx to your GO's, stupid!" - I know you wouldn't use that last word, but I often get to hear it ;-)
I'd like to understand your answer a bit better: If our problem is a finalization problem, shouldn't invoking the GC with System globalGarbageCollect solve the problem? I mean, GC does lead to finalization before objects get finally trashed, no?

I may be wrong, but if the above is true, we're probably only lucky to run into GDI problems before we run out of memory because the GO's won't go away, but are small enough to fit into our memory bounds....

BTW: There is something strange in the GF ST documentation in the chapter about releasing GO's:

VA Smaltalk

In GF/ST under Visual Smalltalk and VisualAge/IBM Smalltalk, we have chosen to make use of finalization the default when you create new instances of GFGraphicObject. However, for finalization to work in Visual Smalltalk versions prior to 3.1 (it is included by default in 3.1), you must have the finalization “extra“ provided by Visual Smalltalk loaded into your image. If you don’t, GF/ST will still work without errors (since we handle the DoesNotUnderstand exception when we tell a GO it needsFinalization). However, you will then have to release GO’s manually. We highly recommend that you load the finalization extra when using GF/ST. Finalization is available in the \EXTRAS\FINALIZE subdirectory in the Visual Smalltalk 3.0 release.

We implement a default finalize in GFGraphicObject that says:

self release.

We can therefore be sure that every nodeGO will receive the message finalize, resulting in the release of host window system resources, when it is no longer held onto by anybody.

The whole section bares a headline of "VA Smalltalk" but seems to cover VisualSmalltalk. (The error was not introduced by Instantiations but has been in the original document already).

It also seems to be incorrect, because we tried putting breakpoints and halts into GOs finalize method and never got a Debugger, which either means VAST catches and swallows the respective exceptions in the finalize cycle or our GO's never get finalized...

So you see me puzzled ;-)

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/2L9p-QvqMaIJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: GF/ST and GDI handles

Hi again,

skimming through the GFST manual in VAST online help, I find many places in which the VAST balloon Icon has been added to sections that cover VisualSmalltalk (and probably also mention vast). That is misleading in many situations...

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/adjd_O2qxZ8J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.