Hi Igor, >Could you please open an issue here: https://bugs.chromium.org/p/v8/issues/
Sure thing; we were just hoping to collect some useful diagnostic info, since we don't have simple repro code. >Could you please try it again on today's tip of tree V8 (say 96f6ac9bc6646ae12acad43a1f9ebdaaf7ceea0a)? We're currently working with 8.0, as our releases are paired with stable V8. We haven't yet ported to 8.1, much less 8.2. An initial test build with 8.1 fails immediately due to breaking API changes (e.g., unlike earlier versions, 8.1 demands non-nestable task support). >Does your memory leak tool give any hints about the source of the memory leak? No, our tool shows managed and native heap sizes that don't change much after a few iterations, but the process keeps growing in private memory size. >How much memory is leaked after 1 iteration? There's a lot of variance, presumably due to the large components involved (V8, .NET Core, our library, SunSpider, etc.). Each test iteration consists of the following: * Isolate and context creation. * SunSpider warmup run and 10 benchmark runs. * Orderly context and Isolate teardown. * Redundant, forced, synchronous managed GC. * Private memory size sample. The memory size samples don't always increase from iteration to iteration, but here's the bottom line: Pointer Compression OFF, 31-bit Smis OFF -> ~40MB after 2000 iterations Pointer Compression OFF, 31-bit Smis ON -> ~40MB after 2000 iterations Pointer Compression ON, 31-bit Smis ON -> ~75MB after 2000 iterations This is 100% repeatable, and the V8 build flags and their associated #defines are the only moving parts. What additional info can we can dig up for our report? Thanks! On Friday, February 14, 2020 at 5:23:28 AM UTC-5, Igor Sheludko wrote: > > Could you please open an issue here: > https://bugs.chromium.org/p/v8/issues/ > > And yet another suggestion. Could you please try it again on today's tip > of tree V8 (say 96f6ac9bc6646ae12acad43a1f9ebdaaf7ceea0a)? > > Does your memory leak tool give any hints about the source of the memory > leak? > How much memory is leaked after 1 iteration? > > On Fri, Feb 14, 2020 at 11:13 AM Santiago Aboy Solanes <sol...@google.com > <javascript:>> wrote: > >> Quick question: Have you tried with v8_enable_pointer_compression = false >> and v8_enable_31bit_smis_on_64bit_arch = true? >> >> On Fri, Feb 14, 2020 at 7:54 AM Yang Guo <yan...@chromium.org >> <javascript:>> wrote: >> >>> +Ulan Degenbaev <javascript:> +Igor Sheludko <javascript:> >>> >>> On Thu, Feb 13, 2020 at 8:36 PM <clearsc...@gmail.com <javascript:>> >>> wrote: >>> >>>> Greetings! >>>> >>>> Our project is a V8 embedding library for .NET on Windows. We have a >>>> test that spins up a context, runs SunSpider, and destroys the isolate. We >>>> run it in a loop to check for memory leaks. >>>> >>>> This test showed a dramatic leak with V8 8.0 that wasn't there with >>>> 7.9. Our tools found nothing suspicious in the managed and native heaps, >>>> but the process's private memory size kept increasing. >>>> >>>> Based on some quick research and a little guesswork, we rebuilt with >>>> v8_enable_pointer_compression and v8_enable_31bit_smis_on_64bit_arch both >>>> set to false. To our surprise this completely eliminated the leak! >>>> >>>> We'd like to report this issue to the V8 team, but we have no simple >>>> native repro code. Can someone suggest a way to gather some useful >>>> diagnostics? >>>> >>>> Thanks! >>>> >>>> -- >>>> -- >>>> v8-dev mailing list >>>> v8-...@googlegroups.com <javascript:> >>>> http://groups.google.com/group/v8-dev >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "v8-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to v8-...@googlegroups.com <javascript:>. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/v8-dev/6325eb1a-2a8e-431d-a7ee-5e7f0a41f046%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/v8-dev/6325eb1a-2a8e-431d-a7ee-5e7f0a41f046%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> -- >>> v8-dev mailing list >>> v8-...@googlegroups.com <javascript:> >>> http://groups.google.com/group/v8-dev >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "v8-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to v8-...@googlegroups.com <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/v8-dev/CAFSTc_iWyBOpP5xEEM6EZk_pLZhyeGoK0WrgM-L8M9%3D6xenyUQ%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/v8-dev/CAFSTc_iWyBOpP5xEEM6EZk_pLZhyeGoK0WrgM-L8M9%3D6xenyUQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> > > -- > > Igor Sheludko > > Software Engineer > > ish...@google.com <javascript:> > > > > Google Germany GmbH > > Erika-Mann-Str. 33 > > 80636 München > > > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado > > Registergericht und -nummer: Hamburg, HRB 86891 > > Sitz der Gesellschaft: Hamburg > > > Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten > haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, > löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, > dass die E-Mail an die falsche Person gesendet wurde. > > > > This e-mail is confidential. If you received this communication by > mistake, please don't forward it to anyone else, please erase all copies > and attachments, and please let me know that it has gone to the wrong > person. > > -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/4ccfe630-ec00-46b0-a2e7-d89e0afb311d%40googlegroups.com.
