Re: how many objects r eligible for garbage Collection ?
Andreas Leitgeb wrote:
Lew <lew@lewscanon.com> wrote:
The spoiler (^L'ed and rot13'ed) was, that ...
This is some kind of poetry? Should I have seen the post to which you are
referring? Were you the poster?
I was speaking of article <slrnfqav36.4ug.avl@gamma.logic.tuwien.ac.at>
I realize I am being obtuse, and I truly apologize, but you are losing me six
ways from Sunday. The URI you post, my newsreader interprets as an email
address and opens a new email to that address when I click on it. I know what
rot13 is, I just hadn't seen anything in that format. I am missing antecedents.
Most newsclients (of those I've yet seen) seem to interpret a
Ascii-formfeed character (aka ^L, or \v, or \013) such that they
do hide away the text that follows until some key is pressed.
I saw no post with either a formfeed nor rot13 "encoded" text.
Google-groups doesn't do this, so I also encoded the text with
"rot13" (google for it, if you want to know about it), which I
considered also quite common in usenet. Many readers have some
feature to toggle "rot13"-encoding of the article on some
keystroke, so it's not much of a burden with those.
I just haven't seen any rot13 text to decode, is the problem.
I don't understand, how "poetry" enters the game.
It wasn't even in rhymes...
What does rhyme have to do with poetry?
Poetry is the use of language for purely evocative purpose. When I see
statements that do not parse well as prose, I try the "poetry" template on it.
In the case of my question, you referenced ^L and rot13, and I had seen
neither elsewhere in the thread. My question was rhetorical, designed to
illustrate the degree of confusion I feel. The "poetry" would have been in
the metaphorical "clearing" of my mental screen and "scrambling" of the sense
of things, represented by your citations of ^L and rot13. Absent any tangible
antecedent, I hypothesized that you were reveling in metaphor.
When you disagreed with my point, I wasn't sure, whether you
had missed that explanation (the "spoiler"), or whether you
were one step further and had spotted any flaw in it.
As it seems, it was the former.
I have yet to find this "spoiler" to which you keep referring.
Now that I understand your answer, that no objects may be eligible for
collection at the given point, I find it cogent.
As I stated:
I do not find this beside the original point at all.
It is very relevant and you raise an excellent point.
Good catch.
Andreas:
In a discussion of eligibility for GC, the possibility
of GC having happened already is IMO entirely uninteresting,
despite it's possibility.
Just so. My original "disagreement" with your analysis had to do with how I
interpreted the pedagogical conditions of when '// do stuff' happens. You
allowed a finite interval between the dereferencing of the first Card and the
breakpoint. I interpreted it as "at time epsilon after the dereferencing such
that no intervening GC could have occurred." I would call the scenario of GC
having already occurred between dereference and the breakpoint as the
degenerate case. Clearly the intent of the question was to reason about the
state under the assumption of no intervening GC activity.
However, I had not even considered the degenerate case until you brought it
up. Now I distinguish the pedagogical scenario, when we may assume no
intervening GC, from the real world, where I'd bloody well better consider the
possibility.
Thanks to you.
If instead the question had been: "why isn't the finalizer
for this object called *at or after* this particular point?",
then the same would have been much more of a useful and serious
answer :-)
Now you've involved finalizers, which if non-trivial induce at least a second
GC cycle before an object can be truly collected, and could emergently prevent
complete collection altogether. Trivial finalizers (i.e., unchanged from that
inherited from Object) are never called.
Having to account for that in the answer does, indeed, make it more serious,
and for certain things more useful. However, the question of GC /per se/ is
more generally applicable and relevant even when finalizers are not at issue.
--
Lew