From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nautica.notk.org (ipv6.notk.org [IPv6:2001:41d0:1:7a93::1]) by hurricane.the-brannons.com (Postfix) with ESMTPS id B2EBD7893D for ; Mon, 24 Jul 2017 00:49:41 -0700 (PDT) Received: by nautica.notk.org (Postfix, from userid 1001) id BD902C01B; Mon, 24 Jul 2017 09:49:53 +0200 (CEST) Date: Mon, 24 Jul 2017 09:49:38 +0200 From: Dominique Martinet To: edbrowse-dev@lists.the-brannons.com Message-ID: <20170724074938.GB15044@nautica> References: <20170623205238.eklhad@comcast.net> <20170724052529.GB31626@nautica> <20170624024328.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170624024328.eklhad@comcast.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Edbrowse-dev] Object identifiers X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.24 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 07:49:41 -0000 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