Hi Anton, Good day! comments inline On Wed, Oct 27, 2010 at 12:23 AM, Anton Muhin <[email protected]> wrote:
> 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). > I think thats true if the document has a reference to them. however in the test it overwrites the same reference (ret) and the nodes are not attached to DOM - so they get created and become garbage for ( var i = 0; i < num; i++ ) { ret = document.createTextNode(str); - DOM node/ v8 wrapper created ret = document.createTextNode(str + "2"); - The previous object/wrapper become garbage? .. I also checked JSC, and it does collect the Text nodes during GC and the memory almost remains constant. > > >> 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? > yeah i realize its irrelevant for this case. > > > 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. As mentioned above, even if v8 is fast, there is garbage created [i can see GC being invoked but no garbage collected]. > 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. no. > 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. > Thanks Zaheer > > >> > >> 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 > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
