Re: [Edbrowse-dev] Object identifiers

[Dominique Martinet <asmadeus@codewreck.org>]

Karl Dahlke wrote on Mon, Jul 24, 2017:
> 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.

Ok, so you do use duktape to hold the array, in that case the design is
solid yes; just need to worry about when to release objects if we go
that way as you describe.
I am not quite sure how to do that before we close the window... Will
have a think.


> 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?

Hm, good point. I think they are by definition.
I just checked and it works.
By the way, realloc is very important too, it happens all the time and
addresses are also reused after realloc, the base pointer changes too.
It happened js_hello_duk so imagine for edbrowse!

> And hope duktape never changed that internal design.

We can only hope, but I think it is a definition of the function but it
is only how I interpret this, they might think differently.



> 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.

Right, we might need to keep an internal id just for that, so the main
process only uses our id, and the js process has a table that does id to
pointer?
Or we can allocate a bit more and keep some edbrowse data in the pointer
itself at the start of what we allocated, so free/realloc know what
edbrowse id this is about and can operate quickly without traversal.
(There are nice 'container_of' macros for that)

I had forgotten that the js process cannot message back to edbrowse, but
with this model the id are only ever modified in the js process and the
main process never needs to know if we do not reuse them.

It is a bit of both ideas, and does not need too many messages passed, I
like it.


(taken from irc)
> Browsing jsrt generates 17821 calls to free() - so my concerns about
> performance are justified.

Hm, we cannot have too many id either, but I do not think alloc can tell
if the pointer will be useful or not.
Maybe always give a new number to each malloc but not using every number
to keep a pointer to the heapptr; when we need a heapptr the first time
we get the id back and add it to our table with another edbrowse number.

That way most free will not have anything to do if the alloc number has
not been used.

Something like extra 64 bits at the start.
First bit is used/not used, if not used then free/realloc do nothing.
If used, other 63 bits are our ID and we need to find it in table.



I think this needs a bit more thinking over, so let's not rush this but
we can play with different ideas and see how it works.



> Then edbrowse can run its own version of gc as described above.

I would rather not add a gc algorithm if we can get away without it, one
is bad enough to debug, imagine when something goes wrong if we cannot
tell which gc removed our value!



-- 
Dominique