Subj : Re: JavaScript memory allocation To : netscape.public.mozilla.jseng From : Matthew Mondor Date : Tue Aug 23 2005 05:25 am Hi Micheal, Since your questions are mostly JS internals related, this does seem like an appropriate mailing list/usenet group, On Tue, 23 Aug 2005 09:11:15 +0200 Michael Vincent van Rantwijk wrote: > It is my understanding, but maybe I'm totally wrong in this, that if I > use something like this: var someVar = "foobar"; the JavaScript engine > allocates a six (6) byte memory block and assigns a pointer to it, right? More than six bytes, but at least 6 characters (the JSString object has to be created/allocated, characters could also be unicode or ASCII), it must be linked to the context and/or parent object, etc if you need exact details the SpiderMonkey source might be best to look at, but maybe some people can actually remind and post the details by heart > My first question is: "What happens when I use something like this: > someVar = "" / someVar = null; someVar = undefined; ? > > Will that clear the pointer *and* allocated memory or will there be a > trace left of the text "foobar" i.e. is that still 'available' in > readable text somewhere in memory? Even if the engine replaced the new string contents by another one, and eventually did free the old string contents, it could still remain readable in the process heap's memory. This largely depends on the internal OS/libc-specific malloc()/calloc()/free()/realloc() allocators. If I understand, there is no provision in SpiderMonkey to clear any memory before it gets dismissed. Most (all?) code in SpiderMonkey eventually rely on JS_free() to free actual memory (and that is normally done once the Garbage Collector freed unnecessary objects, when this happens depends on the application, memory currently in use and various factors). JS_free() just relies on the OS/libc specific free() function, which might or might not clear memory prior to release and can use various algorithms. malloc() itself can allocate more or less memory (and always more memory than requested) depending on the implementation. > My second question is: if the latter is the true, I guess that setting > someVar to = "123456" will overwrite the text "foobar" (right?) but what > happens when I set if to a shorter/longer text string? Will that re-use > the same allocated memory block, or will it allocate a new block and > will that also keep the text "foobar" in memory or will that be cleared? A new string will be created, because in JS strings are immutable. The old string, if no longer referenced, will belong to the GC and will eventually be freed when needed. My guess (although only a guess) is that your purpose is to make sure that some memory is not accessible anymore after it is discarded (i.e. a password or cryptographic session key). If this is the case, what I recommend is to create a new native object for JavaScript in C using SpiderMonkey with custom properties and methods and internal data, which could provide a method which when called realy causes the internal memory to be zeroed, and/or to cause the finalizer of that object to do so. However, because of the way JavaScript works, this could be partly useless depending on several factors. For instance, if you provide a method to return the internal data as a string, the caller can then actually create new JSString objects holding copies of that data just by calling it (since such a method/property needs to create a JSString, to fill it and to return it of course). If, on the other hand, you only provide methods/property to say, set a password and verify if it matches another, this might be less of a problem, but still, where does the user password originate from? If it doesn't originate from another custom system there are many chances that the data has copies in the memory heap. If those parts can be worked around, then there always remains the way memory is allocated. On Unix systems, one can allocate anonymous pages of physical memory using mmap(2) and then subsequently locking them in RAM using mlock(2) to ensure that they cannot be swapped out (to the swap virtual memory device), when such information is very critical. I am not sure how this is done on other paging Operating Systems, but in any case this means that the custom module must rely on such a function if the information loss is that critical instead of to malloc(3)/free(3). Because on systems with virtual memory, even if free(3) made sure to first zero the buffer, or if a custom method was provided to cause the internal data to be zeroed, if load is high enough and/or another process requireing a lot of RAM is considered more vital by the OS, the process can be swapped out to the swap device for more physical RAM to become available, at any time. This means that another physical entity would have the data written to it. If discarding such information is the purpose, is there a particular reason or situation which causes you to easily access this unwanted information? Perhaps that other solutions to this particular situation could be found. Some of what I posted is related to the most extreme critical situations (i.e. OpenSSL code) and might not even be necessary... Matt -- Note: Please only reply on the list, other mail is blocked by default. Private messages from your address can be allowed by first asking. .