> I'm not quite sure it will help, if the problem is a desynchronisation
> between what we think is still linked and what duktape thinks is still linked

Well if we call upon an object with id 17, and there is no such object, for any reason, we get back eb$idl[17] which will not crash the process, and is probably the null object, which is what we want.
It won't have the properties we look for, and if we try to set properties it won't do anything.
But as Chris pointed out, it will never be garbage collected away, because it always has at least one reference, our registry eb$idl[17].
That's good and bad.
We can mess with extinct objects all we want, because they're still there, but objects accumulate and never go away.
Not until you close the window.
Some web pages perform some kind of update every few seconds, like my example http://www.eklhad.net/async
and these would just accrue objects in js and tags in edbrowse for as long as the page is open.

I don't think my generated id plan is prohibitive, probably 2 or 3 days work to get it functioning.
There are advantages to that plan, and advantages to your free interceptor.
If I don't maintain a registry of objects then they will indeed go away when they should.
I only need wrapper free, because the pointer to the object is valid until it is thrown away.
But is the pointer returned by get_heapptr() the same as the base of the allocated region for that object?
Probably, but we really don't know.
It could be a structure inside the region, so malloc and free would not be the same pointers as get_heapptr and push_heapptr.
Only way to know is to write a stand-alone test program.
We'd sure want to do that before going down that path.
And hope duktape never changed that internal design.

So what to do when a pointer is freed?
Since the heap holds everything, you have to loop through all tags in all open windows in edbrowse,
and if any tag has the pointer, and there should be only one, mark it dead or otherwise delete it.
Well that's not too awful, if JS1 is set and everything is one process.
In the 2 process model it's a pain!
At an unpredictable time while javascript is running, it frees some object and we can see the pointer that is freed.
But we're in the wrong process.
I guess I'd need another side effect, pass the freed pointers back to edbrowse along with the response to whatever js function ran.
Then edbrowse can run its own version of gc as described above.

> I also think most implementations will have a way to use our own
> allocation functions

I don't believe mozilla allowed for this.
In other words, we couldn't have considered this approach last month.

> What do you think?

I tentatively like it - even though I just spent a few hours working on the generated id design...
Oh well.

Karl Dahlke