On 10/2/2017 9:40 PM, Eric Dobson wrote:
George: I don't see that invariant for java in anything that I search
for on Java finalizers. Do you have a reference? In particular java
only has one finalizer per object (the finalize method) and across
objects the references I found seem to imply that there is no
seems to imply no ordering across finalizers.
What I recall was that members were guaranteed to be finalized (if
needed) before their parent object - the reverse of the initialization
process. This did not necessary conflict with "objects may be finalized
in any order" ... it simply meant that when the parent was to be
finalized, some or all of the members also needing finalization might
have already been done.
Unfortunately I don't recall exactly where I saw it ... I'm pretty sure
it was in a paper on JVM internals and so was maybe about what was
actually done vs what was guaranteed by specification. And it was quite
a while ago that I was studying virtual machines, so it may no longer be
true of current implementations. I'll have to look around and see if I
can find it again.
Even so, my question to Matthew was - would something like this be
workable for Racket? I don't know how much additional bookkeeping would
Matthew: Ok, I'll just file a bug to track the issue. I'm trying to do
the best available solution following standard practices, and not
actually that worried about the memory leak for my program.
On Mon, Oct 2, 2017 at 1:48 PM, George Neuner <gneun...@comcast.net
IIRC, the JVM executes finalizers in reverse order of registration
- expecting that, in your example, A would have been allocated
before B. Is that something that would work here? [He asks naively.]
You received this message because you are subscribed to the Google Groups "Racket
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.