Good day, Zaheer, On Tue, Oct 26, 2010 at 10:44 PM, Zaheer Ahmad <[email protected]> wrote: > hi Anton, > Iam running the standard > test view-source:http://dromaeo.com/tests/dom-modify.html so i assume the > test itself does not have any leaks.
Please, see below. > On Tue, Oct 26, 2010 at 11:13 PM, Anton Muhin <[email protected]> wrote: >> >> Good day, Zaheer. >> >> Thanks a lot for looking into it. >> >> However, I cannot immediately see how taking this path can make things >> leak. And what exactly do you mean by leak here? > > The webcore strings allocated in ret = document.createTextNode(str); call > are not being collected in the GC They should be, but it might happen later that you expect that. Please note, that JS node wrappers (and hence objects they reference) should survive as long as their owner document survives which means (at least in this test, if I remember it right), the whole time while page is loaded (unless I forgot some crazy frame stuff). >> Newly allocated >> stringResource would be only deallocated when V8 JS String object >> (referenced by v8String handle here) would go away, but that >> eventually should happen for most of the objects, and if it won't >> happen, typically v8 or script have good reasons to keep this object >> for a long enough time. > > The webcore string allocated for the argument str > in document.createTextNode(str); is not going through this patch (ie. it > doesnt create a string resource). Do you see any reason why it would be not > marked as external from v8 engine? There are reasons for it: those strings are roughly too new and it was decided that such strings should not be externalized. Do you think it's a problem? > I think an easier think to check at your side would be run this > test http://dromaeo.com/?dom and verify if there is no memory bloat. It's not a problem on desktop boxes as far as I know. I talked with Android folks and they can repro it on some devices after several runs. I won't be surprised if v8's DOM bindings are fast enough to eat the whole memory out of your device. Do you have any other browsers installed? If yes, it might be interesting to run this benchmark in them as well and see how they behave. The problem might be that in this benchmark out of desktop browsers only Safari is close to v8-backed one, so it might be a matter of sheer speed. yours, anton. >> >> yours, >> anton. >> >> On Tue, Oct 26, 2010 at 9:08 PM, Zaheer Ahmad <[email protected]> >> wrote: >> > hi Anton, >> > Started to look at this furthur.. I can confirm GC gets triggered >> > between >> > the tests..I suspect leak happens in the else part - could you check my >> > comments. >> > Thanks, >> > Zaheer >> > WebCore/bindings/v8/V8Binding.cpp >> > template <typename StringType> >> > StringType v8StringToWebCoreString(v8::Handle<v8::String> v8String, >> > ExternalMode external) >> > { >> > WebCoreStringResource* stringResource = >> > WebCoreStringResource::toStringResource(v8String); >> > if (stringResource) >> > return >> > StringTraits<StringType>::fromStringResource(stringResource); >> > int length = v8String->Length(); >> > if (!length) { >> > // Avoid trying to morph empty strings, as they do not have >> > enough >> > room to contain the external reference. >> > return StringImpl::empty(); >> > } >> > StringType result(StringTraits<StringType>::fromV8String(v8String, >> > length)); >> string allocated here >> > if (external == Externalize && v8String->CanMakeExternal()) { >> > stringResource = new WebCoreStringResource(result); >> > if (!v8String->MakeExternal(stringResource)) { >> resource >> > tracked >> > by the v8 heap >> > // In case of a failure delete the external resource as it >> > was >> > not used. >> > delete stringResource; >> > } >> > }else { >> > __android_log_print(ANDROID_LOG_DEBUG, "hmm", >> > "hmmmmmmmmmmmmmmmmmmmm"); >> leak happens if it goes here, I guess at >> > this >> > point its not tracked by the heap, >> > } >> > return result; >> > } >> > >> > >> > On Thu, Oct 7, 2010 at 8:29 PM, Zaheer Ahmad <[email protected]> >> > wrote: >> >> >> >> On Thu, Oct 7, 2010 at 8:19 PM, Anton Muhin <[email protected]> >> >> wrote: >> >>> >> >>> And what is amount of available RAM? >> >> >> >> 256M and the froyo is the initial version released in July i guess. >> >>> >> >>> yours, >> >>> anton. >> >>> >> >>> On Thu, Oct 7, 2010 at 6:49 PM, Anton Muhin <[email protected]> >> >>> wrote: >> >>> > On Thu, Oct 7, 2010 at 6:42 PM, Zaheer Ahmad <[email protected]> >> >>> > wrote: >> >>> >> On Thu, Oct 7, 2010 at 6:20 PM, Anton Muhin <[email protected]> >> >>> >> wrote: >> >>> >>> >> >>> >>> On Thu, Oct 7, 2010 at 9:29 AM, Zaheer Ahmad >> >>> >>> <[email protected]> >> >>> >>> wrote: >> >>> >>> > On Wed, Oct 6, 2010 at 7:50 PM, Anton Muhin >> >>> >>> > <[email protected]> >> >>> >>> > wrote: >> >>> >>> >> >> >>> >>> >> That sounds bad. How do you run dromaeo? >> >>> >>> > >> >>> >>> > go to http://dromaeo.com/ and select DOM core tests >> >>> >>> > (modification >> >>> >>> > and >> >>> >>> > query >> >>> >>> > test show the problem) >> >>> >>> >> >>> >>> Zaheer, I am curious what is HW you're using and what is the >> >>> >>> browser. >> >>> >>> In any event, that shouldn't be a problem with v8 per se, but >> >>> >>> rather >> >>> >>> with the way v8 is used in that browser. I'll try to sync up with >> >>> >>> Android folks. >> >>> >> >> >>> >> Iam using android on a variant of bravo device with froyo. >> >>> > >> >>> > Thanks a lot. What is the exact version of Froyo? >> >>> > >> >>> >>> >> >>> >>> > >> >>> >>> >> >> >>> >>> >> And what do you mean by 'to >> >>> >>> >> track the caller on andriod'? >> >>> >>> > >> >>> >>> > I mean the call trace which is leaking. >> >>> >>> >> >>> >>> What do you mean by call trace which is leaking? Note that it's >> >>> >>> not >> >>> >>> like C++, leak means that GC for some reason failed to collect >> >>> >>> already >> >>> >>> unused objects. There are some tools which allow you to trace >> >>> >>> leaks, >> >>> >>> but they are usually not exposed to the user. >> >>> >> >> >>> >> Actually andriod does have pretty good call tracing capability :) >> >>> >> here's the >> >>> >> trace..as you can see its 43Meg [And btw i see this in a older >> >>> >> version >> >>> >> of v8 >> >>> >> too - the one in the froyo initial baseline] >> >>> >> Allocations: 20886 >> >>> >> Size: 2088 >> >>> >> Total Size: 43609968 >> >>> >> 8000b4c4 /system/lib/libc_malloc_debug_leak.so --- >> >>> >> leak_malloc >> >>> >> --- >> >>> >> >> >>> >> /local/mnt/workspace/froyo/bionic/libc/bionic/malloc_debug_leak.c:514 >> >>> >> afd0cd40 /system/lib/libc.so --- afd0cd40 --- >> >>> >> a836ce92 /system/lib/libwebcore.so --- >> >>> >> WTF::fastMalloc(unsigned >> >>> >> int) >> >>> >> --- >> >>> >> >> >>> >> >> >>> >> /local/mnt/workspace/froyo/external/webkit/JavaScriptCore/wtf/FastMalloc.cpp:239 >> >>> >> a840d9de /system/lib/libwebcore.so --- >> >>> >> WebCore::StringImpl::createUninitialized(unsigned int, unsigned >> >>> >> short*&) --- >> >>> >> >> >>> >> >> >>> >> /local/mnt/workspace/froyo/external/webkit/WebCore/platform/text/StringImpl.cpp:938 >> >>> >> a8484f42 /system/lib/libwebcore.so --- >> >>> >> WTF::PassRefPtr<WebCore::StringImpl>::releaseRef() const --- >> >>> >> >> >>> >> >> >>> >> /local/mnt/workspace/froyo/external/webkit/JavaScriptCore/wtf/PassRefPtr.h:75 >> >>> >> a84850a4 /system/lib/libwebcore.so --- >> >>> >> >> >>> >> >> >>> >> WebCore::StringTraits<WebCore::String>::fromV8String(v8::Handle<v8::String>, >> >>> >> int) --- >> >>> >> >> >>> >> >> >>> >> /local/mnt/workspace/froyo/external/webkit/WebCore/bindings/v8/V8Binding.cp >> >>> >> a84858d2 /system/lib/libwebcore.so --- >> >>> >> WebCore::v8ValueToWebCoreString(v8::Handle<v8::Value>) --- >> >>> >> >> >>> >> >> >>> >> /local/mnt/workspace/froyo/external/webkit/WebCore/bindings/v8/V8Binding.cpp:133 >> >>> >> a85822a2 /system/lib/libwebcore.so --- >> >>> >> WebCore::V8Parameter<(WebCore::V8ParameterMode)0>::operator >> >>> >> WebCore::String() --- >> >>> >> >> >>> >> >> >>> >> /local/mnt/workspace/froyo/external/webkit/WebCore/bindings/v8/V8Binding.h:199 >> >>> >> a8595c8a /system/lib/libwebcore.so --- >> >>> >> WebCore::DocumentInternal::createTextNodeCallback(v8::Arguments >> >>> >> const&) --- >> >>> >> >> >>> >> >> >>> >> /local/mnt/workspace/froyo/out/target/product/qsd8250_ffa/obj/STATIC_LIBRARIES/libweb >> >>> >> a8609bee /system/lib/libwebcore.so --- v8::internal::Object* >> >>> >> v8::internal::HandleApiCallHelper<false>(v8::internal::(anonymous >> >>> >> >> >>> >> namespace)::BuiltinArguments<(v8::internal::BuiltinExtraArguments)1>) >> >>> >> --- >> >>> >> a8609c48 /system/lib/libwebcore.so --- >> >>> >> v8::internal::Builtin_HandleApiCall(v8::internal::(anonymous >> >>> >> >> >>> >> namespace)::BuiltinArguments<(v8::internal::BuiltinExtraArguments)1>) >> >>> >> --- >> >>> >> /local/mnt/workspace/froyo >> >>> >> Regards, >> >>> >> Zaheer >> >>> > >> >>> > In many cases OOMs are due to v8 exhausting its heap which v8 >> >>> > manages >> >>> > not via malloc. Even for WebCore data structures, they are often >> >>> > retained from JS wrappers. So, even though malloc tracing is quite >> >>> > helpful in many cases, esp. when the whole memory is managed via >> >>> > C/C++ >> >>> > memory management system, it won't give you the whole picture, esp. >> >>> > in >> >>> > the case when v8 is involved. >> >> >> >> Yes, i was not sure if its a leak or a behavior that happens by design >> >> [the tests are crazy in that they do things in tight loops so it >> >> usually >> >> doesnt represent a problem in a normal case]. Its quite strange that >> >> JSC >> >> doesnt have this problem though [since they should also be creating >> >> text >> >> nodes as in the trace] >> >>> >> >>> > >> >>> > yours, >> >>> > anton. >> >>> > >> >>> >> >> >>> >>> >> >>> >>> yours, >> >>> >>> anton. >> >>> >>> >> >>> >>> > Thanks, >> >>> >>> > Zaheer >> >>> >>> >> >> >>> >>> >> On Wed, Oct 6, 2010 at 6:03 PM, Zaheer Ahmad >> >>> >>> >> <[email protected]> >> >>> >>> >> wrote: >> >>> >>> >> > dromaeo usally runs on android the last time i checked with >> >>> >>> >> > v8 >> >>> >>> >> > and >> >>> >>> >> > currently >> >>> >>> >> > the OOM gets invoked and browser is killed (i presume a GC >> >>> >>> >> > would >> >>> >>> >> > interfere >> >>> >>> >> > before that). i just checked JSC works fine. so most probably >> >>> >>> >> > its an >> >>> >>> >> > issue. >> >>> >>> >> > is there a easy way to track the caller on android? >> >>> >>> >> > Thanks, >> >>> >>> >> > Zaheer >> >>> >>> >> > >> >>> >>> >> > On Wed, Oct 6, 2010 at 7:08 PM, Anton Muhin >> >>> >>> >> > <[email protected]> >> >>> >>> >> > wrote: >> >>> >>> >> >> >> >>> >>> >> >> Are you sure it's a leak? v8 uses GC and time when it >> >>> >>> >> >> collects >> >>> >>> >> >> garbage is roughly unpredictable. >> >>> >>> >> >> >> >>> >>> >> >> yours, >> >>> >>> >> >> anton. >> >>> >>> >> >> >> >>> >>> >> >> On Wed, Oct 6, 2010 at 5:07 PM, Zaheer Ahmad >> >>> >>> >> >> <[email protected]> >> >>> >>> >> >> wrote: >> >>> >>> >> >> > hi, >> >>> >>> >> >> > Iam running dromaeo tests with latest BE (oct-1) and DOM >> >>> >>> >> >> > modification >> >>> >>> >> >> > tests >> >>> >>> >> >> > seem to leak a lot (40M in 5s). Is this a known issue? >> >>> >>> >> >> > thanks, >> >>> >>> >> >> > Zaheer >> >>> >>> >> >> > >> >>> >>> >> >> > -- >> >>> >>> >> >> > v8-users mailing list >> >>> >>> >> >> > [email protected] >> >>> >>> >> >> > http://groups.google.com/group/v8-users >> >>> >>> >> >> >> >>> >>> >> >> -- >> >>> >>> >> >> v8-users mailing list >> >>> >>> >> >> [email protected] >> >>> >>> >> >> http://groups.google.com/group/v8-users >> >>> >>> >> > >> >>> >>> >> > -- >> >>> >>> >> > v8-users mailing list >> >>> >>> >> > [email protected] >> >>> >>> >> > http://groups.google.com/group/v8-users >> >>> >>> >> >> >>> >>> >> -- >> >>> >>> >> v8-users mailing list >> >>> >>> >> [email protected] >> >>> >>> >> http://groups.google.com/group/v8-users >> >>> >>> > >> >>> >>> > -- >> >>> >>> > v8-users mailing list >> >>> >>> > [email protected] >> >>> >>> > http://groups.google.com/group/v8-users >> >>> >>> >> >>> >>> -- >> >>> >>> v8-users mailing list >> >>> >>> [email protected] >> >>> >>> http://groups.google.com/group/v8-users >> >>> >> >> >>> >> -- >> >>> >> v8-users mailing list >> >>> >> [email protected] >> >>> >> http://groups.google.com/group/v8-users >> >>> > >> >>> >> >>> -- >> >>> v8-users mailing list >> >>> [email protected] >> >>> http://groups.google.com/group/v8-users >> > >> > > > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
