Smalltalk › Instantiations

Any idea why an Object only held weakly is not getting garbage collected?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

12 messages Options

Richard Sargent

Any idea why an Object only held weakly is not getting garbage collected?

Administrator

John provided some very nice background information in a reply on GF/ST (https://groups.google.com/d/msg/va-smalltalk/lgQt2ykkGy8/vEGQE7Q35sYJ).

However, even if explicitly and repeatedly call System globalGarbageCollect, the object in question is not getting collected. I have run an explicit look up of the object and asked for its #allReferences (there are two of them) and asked whether each #isWeak. They are.

I'm baffled. Any ideas? Anyone?

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

Richard Sargent

Re: Any idea why an Object only held weakly is not getting garbage collected?

Administrator

By the way, 100 timesRepeat: [System globalGarbageCollect] finally cleaned up the weak references. I don't know how many of the 100 iterations were needed.

On Friday, March 21, 2014 1:50:15 PM UTC-7, Richard Sargent wrote:

John provided some very nice background information in a reply on GF/ST (<a href="https://groups.google.com/d/msg/va-smalltalk/lgQt2ykkGy8/vEGQE7Q35sYJ" target="_blank" onmousedown="this.href='https://groups.google.com/d/msg/va-smalltalk/lgQt2ykkGy8/vEGQE7Q35sYJ';return true;" onclick="this.href='https://groups.google.com/d/msg/va-smalltalk/lgQt2ykkGy8/vEGQE7Q35sYJ';return true;">https://groups.google.com/d/msg/va-smalltalk/lgQt2ykkGy8/vEGQE7Q35sYJ).

However, even if explicitly and repeatedly call System globalGarbageCollect, the object in question is not getting collected. I have run an explicit look up of the object and asked for its #allReferences (there are two of them) and asked whether each #isWeak. They are.

I'm baffled. Any ideas? Anyone?

Seth Berman

Re: Any idea why an Object only held weakly is not getting garbage collected?

Hi Richard,

I'll research a little.

One thing you could try is to increase the size of your new space segments.

During GGC, the inactive new space segment is used to hold the weak marking stack.

If overflow occurs, then remaining weak objects must be added to the strong marking stack and will have to wait for a subsequent GGC round.

I'm not sure what the density of weak objects are in your system, so this simply a possibility. I will look for some others.

On Friday, March 21, 2014 6:39:18 PM UTC-4, Richard Sargent wrote:

By the way, 100 timesRepeat: [System globalGarbageCollect] finally cleaned up the weak references. I don't know how many of the 100 iterations were needed.

On Friday, March 21, 2014 1:50:15 PM UTC-7, Richard Sargent wrote:
John provided some very nice background information in a reply on GF/ST (<a href="https://groups.google.com/d/msg/va-smalltalk/lgQt2ykkGy8/vEGQE7Q35sYJ" target="_blank" onmousedown="this.href='https://groups.google.com/d/msg/va-smalltalk/lgQt2ykkGy8/vEGQE7Q35sYJ';return true;" onclick="this.href='https://groups.google.com/d/msg/va-smalltalk/lgQt2ykkGy8/vEGQE7Q35sYJ';return true;">https://groups.google.com/d/msg/va-smalltalk/lgQt2ykkGy8/vEGQE7Q35sYJ).

However, even if explicitly and repeatedly call System globalGarbageCollect, the object in question is not getting collected. I have run an explicit look up of the object and asked for its #allReferences (there are two of them) and asked whether each #isWeak. They are.

I'm baffled. Any ideas? Anyone?

Richard Sargent

Re: Any idea why an Object only held weakly is not getting garbage collected?

Administrator

On Friday, March 21, 2014 4:53:32 PM UTC-7, Seth Berman wrote:

One thing you could try is to increase the size of your new space segments.
During GGC, the inactive new space segment is used to hold the weak marking stack.
If overflow occurs, then remaining weak objects must be added to the strong marking stack and will have to wait for a subsequent GGC round.

I'm not sure what the density of weak objects are in your system, so this simply a possibility. I will look for some others.

Thanks, Seth. That looks like some good advice.

We use weak references quite heavily in GBS, so it wouldn't surprise me if we were running out of stack. I'm pretty certain my image is using the default new space size, so I will try something larger.

Richard Sargent

Re: Any idea why an Object only held weakly is not getting garbage collected?

Administrator

In reply to this post by Seth Berman

On Friday, March 21, 2014 4:53:32 PM UTC-7, Seth Berman wrote:

One thing you could try is to increase the size of your new space segments.
During GGC, the inactive new space segment is used to hold the weak marking stack.
If overflow occurs, then remaining weak objects must be added to the strong marking stack and will have to wait for a subsequent GGC round.

Is there any way for the application to detect if this weak marking stack overflow has occurred?
e.g., as a bit in the #gcEvent: callback, or in the Core registry somewhere, etc.

Richard Sargent

Re: Any idea why an Object only held weakly is not getting garbage collected?

Administrator

In reply to this post by Seth Berman

On Friday, March 21, 2014 4:53:32 PM UTC-7, Seth Berman wrote:

One thing you could try is to increase the size of your new space segments.
During GGC, the inactive new space segment is used to hold the weak marking stack.

Well, I have the "as shipped" new space setting (newSpaceSize=2097152). That seems like it should be plenty for the number of weak references I have during these tests.

Can you summarize the formula for how much new space is needed for each entry in the weak marking stack and what an entry represents? e.g. is it just a reference to the weakly held object (meaning 4 bytes for each) or is it something more?

Thanks,
Richard

Seth Berman

Re: Any idea why an Object only held weakly is not getting garbage collected?

In reply to this post by Richard Sargent

H Richard,

No, not easily. Unfortunately there is is no gc event for this situation.

The inactive newspace memory and internal segment pointers are reset

after the mark phase and reused again during the compactor phase (to store relocation info).

I was going to offer an interesting use of EsMemorySegment API to be able to tell, with a high degree of probability, that the stack did overflow.

But the compactor's use of the space ruins all that:(

-- Seth

On Friday, March 21, 2014 8:04:37 PM UTC-4, Richard Sargent wrote:

On Friday, March 21, 2014 4:53:32 PM UTC-7, Seth Berman wrote:
One thing you could try is to increase the size of your new space segments.
During GGC, the inactive new space segment is used to hold the weak marking stack.
If overflow occurs, then remaining weak objects must be added to the strong marking stack and will have to wait for a subsequent GGC round.

Is there any way for the application to detect if this weak marking stack overflow has occurred?
e.g., as a bit in the #gcEvent: callback, or in the Core registry somewhere, etc.

Seth Berman

Re: Any idea why an Object only held weakly is not getting garbage collected?

In reply to this post by Richard Sargent

Hi Richard,

I figured as much...overflow would suggest "A LOT" of weak objects.

The entries are just ref slots (EsObjectHeader **)...so 4 bytes currently.

-- Seth

On Monday, March 24, 2014 11:41:12 AM UTC-4, Richard Sargent wrote:

On Friday, March 21, 2014 4:53:32 PM UTC-7, Seth Berman wrote:
One thing you could try is to increase the size of your new space segments.
During GGC, the inactive new space segment is used to hold the weak marking stack.

Well, I have the "as shipped" new space setting (newSpaceSize=2097152). That seems like it should be plenty for the number of weak references I have during these tests.

Can you summarize the formula for how much new space is needed for each entry in the weak marking stack and what an entry represents? e.g. is it just a reference to the weakly held object (meaning 4 bytes for each) or is it something more?

Thanks,
Richard

Richard Sargent

Re: Any idea why an Object only held weakly is not getting garbage collected?

Administrator

On Monday, March 24, 2014 2:36:15 PM UTC-7, Seth Berman wrote:

I figured as much...overflow would suggest "A LOT" of weak objects.

Well, we have had such an overflow in the VW version of GBS. But I believe its memory space for the weak marking stack is a lot smaller.

Richard Sargent

Re: Any idea why an Object only held weakly is not getting garbage collected?

Administrator

In reply to this post by Seth Berman

On Monday, March 24, 2014 2:29:37 PM UTC-7, Seth Berman wrote:

No, not easily. Unfortunately there is is no gc event for this situation.

That might be a nice feature to have at some point. Our tests are fairly small and don't really load up the weak memory spaces. Our customers, on the other hand, can and do work with much larger data sets.

- - - - -
And while I have your ear, perhaps you can elaborate on this topic.

As I understand it, there is no guarantee that all weak references to the same object will be nilled in one iteration through the garbage collector. Is that correct?

Example:
In GBS, we have two weak mappings, client to server and server to client. It would be ideal if a client object were GCed and nilled from the two weak collections "at the same time", once the weak collections were the only references to it.

And are you aware of and able to admit to any plans to improve it?

Seth Berman

Re: Any idea why an Object only held weakly is not getting garbage collected?

Hi Richard,

That is correct, there is no guarantee.

We discussed extreme edge cases like weak stack overflow already, but I think the more likely reason for this would be that the finalization queue is full and no more entries can be added.
In this case, we do not severe that link because we must guarantee finalization will occur (hopefully sooner rather than later).

Therefore we must wait until that weak obj->weak ref entry can be added to the queue before we cut ties.

There are no concrete plans at the moment, but we certainly can take a strong look at the finalization queue size policy.

-- Seth

On Monday, March 24, 2014 6:37:07 PM UTC-4, Richard Sargent wrote:

On Monday, March 24, 2014 2:29:37 PM UTC-7, Seth Berman wrote:
No, not easily. Unfortunately there is is no gc event for this situation.

That might be a nice feature to have at some point. Our tests are fairly small and don't really load up the weak memory spaces. Our customers, on the other hand, can and do work with much larger data sets.

- - - - -
And while I have your ear, perhaps you can elaborate on this topic.

As I understand it, there is no guarantee that all weak references to the same object will be nilled in one iteration through the garbage collector. Is that correct?
Example:
In GBS, we have two weak mappings, client to server and server to client. It would be ideal if a client object were GCed and nilled from the two weak collections "at the same time", once the weak collections were the only references to it.
And are you aware of and able to admit to any plans to improve it?

Richard Sargent

Re: Any idea why an Object only held weakly is not getting garbage collected?

Administrator

I can say that "bumping" it from 1,024 entries to 90,000 (30,000 finalizations) improved the execution of one test case that was being "fussy".

Please let me know if you ever come across anything that suggests there is a real limit to the size, after which performance is impacted.

On Mon, Mar 24, 2014 at 5:59 PM, Seth Berman <[hidden email]> wrote:

Hi Richard,

That is correct, there is no guarantee.
We discussed extreme edge cases like weak stack overflow already, but I think the more likely reason for this would be that the finalization queue is full and no more entries can be added.
In this case, we do not severe that link because we must guarantee finalization will occur (hopefully sooner rather than later).
Therefore we must wait until that weak obj->weak ref entry can be added to the queue before we cut ties.

There are no concrete plans at the moment, but we certainly can take a strong look at the finalization queue size policy.

-- Seth

On Monday, March 24, 2014 6:37:07 PM UTC-4, Richard Sargent wrote:

On Monday, March 24, 2014 2:29:37 PM UTC-7, Seth Berman wrote:
No, not easily. Unfortunately there is is no gc event for this situation.

That might be a nice feature to have at some point. Our tests are fairly small and don't really load up the weak memory spaces. Our customers, on the other hand, can and do work with much larger data sets.

- - - - -
And while I have your ear, perhaps you can elaborate on this topic.

As I understand it, there is no guarantee that all weak references to the same object will be nilled in one iteration through the garbage collector. Is that correct?

Example:
In GBS, we have two weak mappings, client to server and server to client. It would be ideal if a client object were GCed and nilled from the two weak collections "at the same time", once the weak collections were the only references to it.

And are you aware of and able to admit to any plans to improve it?

--
You received this message because you are subscribed to a topic in the Google Groups "VA Smalltalk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/va-smalltalk/2G4HQ0FGj1I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

Richard Sargent
Business Development Manager
503-766-4719
[hidden email]

GemTalk Systems
15220 NW Greenbrier Parkway #240
Beaverton, OR 97006