Follow-up on my previous post (mea culpa) -- I added v8::V8::Dispose() in the functions responsible for shutting V8 down. Dispose() invokes TearDown(), which effectively cleans up the memory. I bumped into the method while examining the V8.h include file. As these things go, the "Hello world" examples from the V8 developer site does not include Dispose() -- I suppose it has not been updated recently. Anyhow, Dispose() seems to do the trick, at the cost, of course, of terminating for good the V8 engine.
Frederic On Mar 19, 12:52 pm, fcharp <[email protected]> wrote: > I have been developing a substantial library on V8 for over a year, so > I am -- by now -- somewhat familiar with its inner workings. But I > still have this fundamental issue with what appears to be V8 memory > leaks. I updated my code snapshot yesterday thinking that he problem > may have gone away. But much to my surprise, the leaks were worse. I > spent hours stepping through the V8 code and got the general > impression that some memory chunks assigned by the MapSpace and > Heap::Setup when V8 intializes are never reclaimed. I established that > by intercepting every call to the OS memory allocation functions and > reconciling those calls with the leaked block addresses. All the > memory leaks could be traced back to a V8 request. > > In an attempt to clarify the situation, I simply created a barebones > Win32 program that embeds the V8 "Hello World" example. It does not > get much cleaner than that. The application is built on Visual Studio > 2008 with default Win32 wizard settings. The V8 version is 2.1.6.2. > The code generated by the VS wizard was not modified. The Hello World > code was not modified either. The program is run in Debug mode with > the debug V8 library. > > Running this program by simply opening and closing it results in > memory leaks. These match the ones I get in my library (which does > perform thousands of V8 invocations). Here is the dump: > > Detected memory leaks! > Dumping objects -> > {223} normal block at 0x006DED60, 4096 bytes long. > Data: < D$ T$ D$ T$ > 8B 44 24 04 8B 54 24 08 8B 44 24 04 8B 54 24 > 08 > {222} normal block at 0x006DCD20, 8192 bytes long. > Data: < > 00 00 00 00 00 20 00 00 CD CD CD CD CD CD CD > CD > {217} normal block at 0x006FDA90, 4088 bytes long. > Data: < > AD DE AD 0B AD DE AD 0B AD DE AD 0B AD DE AD > 0B > {206} normal block at 0x006C8900, 12 bytes long. > Data: < lA ( D > D8 6C 41 01 28 9E 44 01 02 05 00 00 > {205} normal block at 0x006C88B8, 12 bytes long. > Data: < lA XbD ; > D8 6C 41 01 58 62 44 01 CF 3B 00 00 > {204} normal block at 0x00A4BF58, 68 bytes long. > Data: < l l l ` l > 80 85 6C 00 A8 86 6C 00 F0 86 6C 00 60 86 6C > 00 > {203} normal block at 0x00A4BF10, 12 bytes long. > Data: < lA `TD > D8 6C 41 01 60 54 44 01 F6 0D 00 00 > {202} normal block at 0x00A4BEC8, 12 bytes long. > Data: < lA p=D > D8 6C 41 01 70 3D 44 01 E3 16 00 00 > {201} normal block at 0x00A4BE80, 12 bytes long. > Data: < lA D 6 > D8 6C 41 01 D8 06 44 01 92 36 00 00 > {200} normal block at 0x006C87D0, 12 bytes long. > Data: < lA C ;5 > D8 6C 41 01 90 D1 43 01 3B 35 00 00 > {198} normal block at 0x006C8870, 12 bytes long. > Data: < lA C @ > D8 6C 41 01 A0 90 43 01 EF 40 00 00 > {197} normal block at 0x006C8828, 12 bytes long. > Data: < lA jC & > D8 6C 41 01 08 6A 43 01 92 26 00 00 > {196} normal block at 0x006C8738, 12 bytes long. > Data: < lA +F > D8 6C 41 01 10 2B 46 01 11 0E 00 00 > {194} normal block at 0x006C8788, 12 bytes long. > Data: < lA F & > D8 6C 41 01 E8 0C 46 01 26 1E 00 00 > {193} normal block at 0x006C8660, 12 bytes long. > Data: < lA E Q > D8 6C 41 01 E8 BA 45 01 F3 51 00 00 > {191} normal block at 0x006C86F0, 12 bytes long. > Data: < lA 0=E } > D8 6C 41 01 30 3D 45 01 B3 7D 00 00 > {190} normal block at 0x006C86A8, 12 bytes long. > Data: < lA (E R > D8 6C 41 01 D8 28 45 01 52 14 00 00 > {188} normal block at 0x006C8618, 12 bytes long. > Data: <X > 58 BF A4 00 11 00 00 00 0E 00 00 00 > {187} normal block at 0x006C8580, 12 bytes long. > Data: < lA 0 D > D8 6C 41 01 30 A3 44 01 A7 85 00 00 > {167} normal block at 0x00A47C28, 25 bytes long. > Data: <Top::js_entry_sp> 54 6F 70 3A 3A 6A 73 5F 65 6E 74 72 79 5F 73 > 70 > {166} normal block at 0x00A47BC0, 39 bytes long. > Data: <Top::external_ca> 54 6F 70 3A 3A 65 78 74 65 72 6E 61 6C 5F 63 > 61 > {165} normal block at 0x00A47B60, 31 bytes long. > Data: <Top::pending_exc> 54 6F 70 3A 3A 70 65 6E 64 69 6E 67 5F 65 78 > 63 > {164} normal block at 0x00A47B08, 21 bytes long. > Data: <Top::context_add> 54 6F 70 3A 3A 63 6F 6E 74 65 78 74 5F 61 64 > 64 > {163} normal block at 0x00A47AB0, 24 bytes long. > Data: <Top::c_entry_fp_> 54 6F 70 3A 3A 63 5F 65 6E 74 72 79 5F 66 70 > 5F > {162} normal block at 0x00A47A58, 21 bytes long. > Data: <Top::handler_add> 54 6F 70 3A 3A 68 61 6E 64 6C 65 72 5F 61 64 > 64 > {161} normal block at 0x006DB598, 5964 bytes long. > Data: < G( A pG( > 10 47 28 01 00 00 07 00 F8 D8 41 01 70 47 28 > 01 > {160} normal block at 0x00A47A00, 28 bytes long. > Data: <Debug::register_> 44 65 62 75 67 3A 3A 72 65 67 69 73 74 65 72 > 5F > {159} normal block at 0x00A456A0, 28 bytes long. > Data: <Debug::register_> 44 65 62 75 67 3A 3A 72 65 67 69 73 74 65 72 > 5F > {158} normal block at 0x00A45648, 28 bytes long. > Data: <Debug::register_> 44 65 62 75 67 3A 3A 72 65 67 69 73 74 65 72 > 5F > {157} normal block at 0x00A455F0, 28 bytes long. > Data: <Debug::register_> 44 65 62 75 67 3A 3A 72 65 67 69 73 74 65 72 > 5F > {156} normal block at 0x00A45598, 28 bytes long. > Data: <Debug::register_> 44 65 62 75 67 3A 3A 72 65 67 69 73 74 65 72 > 5F > {150} normal block at 0x00A45520, 60 bytes long. > Data: < m > 98 B5 6D 00 F1 01 00 00 EE 01 00 00 1A 00 00 > 00 > {147} normal block at 0x00A45418, 24 bytes long. > Data: <x > { > 78 B9 3E 01 06 00 00 00 00 00 00 00 00 00 7B > 00 > {146} normal block at 0x00A45388, 84 bytes long. > Data: <@ = > 40 CF 3D 01 05 00 00 00 00 00 00 00 00 00 00 > 1F > {145} normal block at 0x006D3500, 32856 bytes long. > Data: < = > B8 CE 3D 01 04 00 00 00 00 00 00 00 00 00 00 > 1F > {144} normal block at 0x006CF670, 15956 bytes long. > Data: < = > F0 CD 3D 01 03 00 00 00 01 00 00 00 00 00 00 > 1F > {143} normal block at 0x00A47FF0, 15956 bytes long. > Data: < = > F0 CD 3D 01 02 00 00 00 00 00 00 00 00 00 00 > 1F > {142} normal block at 0x006C4098, 15956 bytes long. > Data: < = > F0 CD 3D 01 01 00 00 00 00 00 00 00 00 00 00 > 1F > {141} normal block at 0x00A43C28, 2004 bytes long. > Data: < > > 00 00 00 00 00 00 00 00 A0 81 3E 01 00 00 00 > 00 > {140} normal block at 0x00A44B78, 2004 bytes long. > Data: < > > 00 00 00 00 00 00 00 00 94 81 3E 01 00 00 00 > 00 > {139} normal block at 0x00A479B8, 8 bytes long. > Data: < > 00 00 FE 03 00 00 00 02 > {122} normal block at 0x00A43B38, 12 bytes long. > Data: < : > E0 3A A4 00 FF FF FF FF FF FF FF FF > {121} normal block at 0x00A43AE0, 24 bytes long. > Data: <(E> 8; > 28 45 3E 01 01 00 00 00 00 00 CD CD 38 3B A4 > 00 > {115} normal block at 0x00A47FA8, 8 bytes long. > Data: < p> > 20 70 3E 01 B0 00 00 00 > {112} normal block at 0x00A47E88, 28 bytes long. > Data: < p> F > 00 70 3E 01 F0 46 1E 00 FF FF FF FF 00 00 00 > 00 > {111} normal block at 0x00A47E30, 28 bytes long. > Data: < p> F > 00 70 3E 01 B8 46 1E 00 FF FF FF FF 00 00 00 > 00 > {106} normal block at 0x00A478E0, 28 bytes long. > Data: < p> F > 00 70 3E 01 80 46 1E 00 FF FF FF FF 00 00 00 > 00 > {105} normal block at 0x00A47890, 20 bytes long. > Data: < x > FF FF FF FF 00 CD CD CD CD CD CD CD 90 78 A4 > 00 > {104} normal block at 0x00A47840, 20 bytes long. > Data: < �...@x > FF FF FF FF 00 CD CD CD CD CD CD CD 40 78 A4 > 00 > {103} normal block at 0x006B0068, 81904 bytes long. > Data: < @ > 00 00 00 00 15 40 00 04 04 00 00 00 00 00 00 > 00 > {102} normal block at 0x00A41FD8, 16 bytes long. > Data: < *O > 0C 2A 4F 01 00 00 00 00 CD CD CD CD 00 00 00 > 00 > {101} normal block at 0x00A477E8, 28 bytes long. > Data: < p> J > 00 70 3E 01 A8 4A 1C 00 FF FF FF FF 00 00 00 > 00 > Object dump complete. > > Now, I would not be overly concerned with this if we were talking > about 20 bytes here and there. But at 100K and over, in a program that > does essentially nothing, I am starting to get a little nervous. > Desktop applications can live with these kind of leaks, but they do > become a problem on small platforms with limited memory (I work on > various targets, including small ARM devices). > > It is possible that I am completely missing something here... But I > would lke to know if this is something that can be corrected or if I > have to superclass V8's memory requests in order to mark and release > the memory used by V8 -- a prospect which I really do not relish... > > Thnaks in advance, > > Frederic -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users To unsubscribe from this group, send email to v8-users+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
