Thanks for the help, btw =) I ran your splay test and it crashes as well. here is the trace: Scavenge 34.5 -> 34.2 MB, 43 ms. Mark-sweep 39.2 -> 38.9 MB, 199 ms. Scavenge 45.0 -> 44.7 MB, 41 ms. Mark-sweep 50.7 -> 50.4 MB, 243 ms. Scavenge 56.4 -> 56.1 MB, 41 ms. Scavenge 62.1 -> 61.9 MB, 42 ms. Mark-sweep 67.9 -> 67.6 MB, 316 ms. Scavenge 73.6 -> 73.3 MB, 43 ms. Scavenge 79.3 -> 79.1 MB, 42 ms. Scavenge 85.1 -> 84.8 MB, 42 ms. Mark-sweep 90.8 -> 90.5 MB, 409 ms. Scavenge 96.5 -> 96.2 MB, 44 ms. Scavenge 102.2 -> 102.0 MB, 43 ms. Scavenge 108.0 -> 107.7 MB, 44 ms. Scavenge 113.7 -> 113.4 MB, 46 ms. Mark-sweep 119.4 -> 119.1 MB, 519 ms. Scavenge 125.2 -> 124.9 MB, 44 ms. Scavenge 130.9 -> 130.6 MB, 45 ms. Scavenge 136.6 -> 134.5 MB, 35 ms. Scavenge 140.5 -> 134.5 MB, 18 ms. Scavenge 142.5 -> 134.5 MB, 6 ms. Scavenge 142.5 -> 134.5 MB, 6 ms. Scavenge 142.5 -> 134.5 MB, 7 ms. Scavenge 142.5 -> 134.5 MB, 6 ms. Scavenge 142.5 -> 134.5 MB, 7 ms. crash...
I could post the code, however I'm not just using the vanilla v8 engine. I've wrapped pdcurses functions and created my own. So my code won't work in plain v8. However since even the splay test is crashing, we already have a common code we can work from to try and figure this out. On Nov 20, 1:58 pm, Erik Corry <[email protected]> wrote: > I attached the file. I am running with the command line > > ./v8 public-splay.txt --trace-gc > > I am using the Linux build. > > 2009/11/20 dracflamloc <[email protected]>: > > > > > Perhaps I'm missing something here. Could you post the flags you're > > passing in, if any? > > I assume the 140 you're getting is from the gc trace output? > > Are there any special build parameters you're using? > > > I don't get why its happening, but it is. Is there anything I could do > > to investigate this better? > > If the JS file is something you can share then sending it to us would > help us find out what is going on. > > > > > > > On Nov 20, 1:12 pm, Erik Corry <[email protected]> wrote: > >> It seems to work for me. I quadrupled the size of the splay benchmark > >> and I can run that without problems. It tops out at over 250Mbytes in > >> the 64 bit version, around 140Mbytes in the 32 bit version (those fat > >> pointers take up space!). > > >> 2009/11/20 dracflamloc <[email protected]>: > > >> > trace shows it gets to about 125MB and then can no longer free memory > >> > so it throws OOM. > >> > I've attempted to use --max-old-space-size but always get the same > >> > result > > >> > I have tried this with 3339 and still it caps out at 125 in the trace. > > >> > The thing is, I know where the memory is going (Lots of arrays), > >> > however I don't know why its capping out at such a small RAM usage. > > >> > On Nov 20, 4:20 am, Erik Corry <[email protected]> wrote: > >> >> 2009/11/20 dracflamloc <[email protected]>: > > >> >> > # > >> >> > # Fatal error in (null) > >> >> > # Allocation failed - process out of memory > >> >> > # > > >> >> > Hello, I have v8 running in a VC++ 2005 console application. I'm > >> >> > running a script thats pretty simple, but is memory intensive. However > >> >> > the script always crashes after a few seconds while its creating > >> >> > arrays/objects with an out of memory error. > > >> >> > This computer has 3GB of RAM. How can I enable a script to access all > >> >> > available memory before throwing the OOM error, if it is indeed > >> >> > cutting off at 150MB? > > >> >> We had a bug until recently where you could get out of memory errors > >> >> without actually having run out of memory. make sure you have a > >> >> version at least as recent as 3285 on the bleeding edge or 3333 on the > >> >> trunk. > > >> >> You can run the VM with --trace-gc to see how much memory it is > >> >> actually using. > > >> >> There is an option --max-old-space-size for increasing the amount of > >> >> memory available to V8. > > >> >> I think the developer tools have some functions for tracing where > >> >> memory is going, but I am not personally familiar with them. > > >> >> -- > >> >> Erik Corry > > > > public-splay.txt > 14KViewDownload --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
