[Vm-dev] Re: Ephemerons - hope it is right this time :)

[Igor Stasenko]

There is one slight thing, which i had doubts about.
Initially, when i was revising the algorithm, i followed the same road
as in paper:
"
In the third phase, the collector traces the remaining objects,
beginning at the ephemerons still on the queue. Any ephemerons
encountered in this phase are treated as ordinary objects, and all
fields traced’.
"

It means that VM will report only the topmost ephemerons (which has
keys non-reachable from roots),
but not consider ephemerons which are reachanble from those ones,
which will be discovered later, when queue will be processed.

The difference is, whether VM should also report nested ephemeron or not.
Consider a following test:

testNestedEphemerons

	" test that we will get a notification from nested ephemeron"
	
	| e key key2 val list count |

	list := WeakFinalizationList forEphemerons.

	e := Ephemeron newForList: list.

	key := Object new.
	key2 := Object new.

	e key: key value: (
		Array with: (
		(Ephemeron newForList: list)
			key: key2 value: 1 at 2 )
	).

	key := key2 := nil.
	Smalltalk garbageCollect.

	count := 0.
	list finalizationAction: [:eph | count := count + 1].
	list finalizeValues.
	
	self assert: count = 2
	

Here, the top ephemeron (e)
should be reported as one which having almost-collectable key.
But then VM has to mark its fields (otherwise they will be lost, and
we don't want that before image can handle it),
and discovers a nested ephemeron.
But nested one also has its key almost-collectable.
So, here the difference: should VM trace this ephemeron as usual
object (with all slots as strong references, like paper says),
or it should also report this ephemeron as one with almost-collectable key.

By following a paper description, at this stage, a nested ephemeron
should not be reported (so, in above test , a resulting count must be
== 1, but not 2).

This is quite obscure case (usually ephemerons not form a nested
loops), since then it is a question, which one should be finalized
first, and which one second.
So, for most use cases, this difference will not affect anything.
But if this will happen, it may lead to situation, that nested
ephemeron won't be finalized, so you could forget to free external
resources etc.
That's why i think, its better to report even nested ephemerons.
Otherwise if you finalize the topmost ephemeron and set its key (or
values) to nil,
then there will be no other references to nested ephemeron and it will
be garbage collected without any notice.
But if we report it, then image side can decide if it needs to be
finalized or not, regardless that the only reference to given
ephemeron are coming
from another ephemeron , which also needs to be finalized.

-- 
Best regards,
Igor Stasenko AKA sig.