Questions for Instantiations on the finalize queue size

You are correct...there are no documented answers to this question.

I queried John and looked on the vm side of the fence.  We both are not aware of why this was the chosen limitation.

Of course, as John correctly stated to me...that doesn't mean there isn't one:)

*Very* strictly speaking, the only limitation I could come up with was that the value must be within a SmallInteger boundary.

Do you actually hit situations where you find this to be limiting?

-- Seth

On Thursday, March 6, 2014 3:28:18 PM UTC-5, Richard Sargent wrote:

Why is the finalize queue hard-code to a maximum size of 4096? (1,365 objects)

What are the consequences of increasing the size of the queue beyond this?

How much of this limit is/was predicated on technology limits of the early 90s, which might no longer apply?
(Ok, this is an archeology question for which there may be no documented answers.)


Thanks guys!

Thanks for the information, Seth. Yes, I have hit it in the past, And I expect to hit it again in the future.

The situation in the past was a large and complicated application window. When we closed it, it wouldn't get garbage collected soon enough and would interfere with the next attempt to open the window. This was about 9 or 10 years ago, so I don't remember the precise details.

And with GBS (GemBuilder for Smalltalk), we can create a lot of objects on the client reflecting the application's replication of server objects. It would be good to have them cleaned up, rather than cluttering the mapping cache.

Naturally, I will perform some experiments to determine whether there is a "sweet spot" for the maximum size.