Hi all, I’ve started the design doc for such change (link: https://docs.google.com/document/d/1O4JPsoaxTQsX_7T5Fz4rsGeHMiM16jUrvDuq9FrtbNM/edit?pli=1&tab=t.0) and I also uploaded the CL we worked so far (link: https://chromium-review.googlesource.com/c/v8/v8/+/6996467). Reviews and comments are welcome.
I still have some questions regarding the review process: 1. Wile clicking in “Suggest owners", I see a list of 5 people for each file I’ve changed. I’m not quite confident who I should ping here and getting directions here to avoid pinging wrong people will be very welcome. 2. I tried to run tests, but I got a reply from CQ that I’m not a Dry Runner. Is it expected that I don’t have such permissions? (I’m under Igalia’s CCLA).it would be nice test it in architectures other than mine. 3. I’ve run Performance benchmarks (Octane, Kraken, and Sunspider) and results looks neutral, but I’m not sure how could I share this with you (sorry, but I’m kinda new to Gerrit in general). Thanks, Caio. > Em 25 de set. de 2025, à(s) 14:52, Caio Lima <[email protected]> escreveu: > > Hi Jakob, > > Thank you very much for the time to answer this email. I’m answering it below. > >> Em 25 de set. de 2025, à(s) 06:34, Jakob Kummerow <[email protected]> >> escreveu: >> >> I don't have an opinion on the API itself. >> >> I do have a concern about the motivating use case: the number of allocated >> bytes for a given workload/testcase is not fixed, so I suspect your >> experience with future regression tests based on such infrastructure might >> be disappointing. In particular, the sizes of objects can grow or shrink >> over time when we add or remove internal fields (or change the sizes of all >> fields, such as by turning pointer compression on or off). Also, when >> functions get optimized, allocations might be optimized out, e.g. by using >> unboxed ints/floats instead of HeapNumbers, or by constant-folding >> operations, or by escape-analyzing entire objects; and various >> optimization/inlining heuristics that affect this keep changing over time. >> Since optimization happens as async background tasks, even between two runs >> of the same V8 binary you may see different behavior when the optimized code >> is available a little earlier or a little later. With that in mind, would >> such a new API actually satisfy your needs? > > Yes, such variation is an expected behavior right now. We are aware of them, > and during our tests we observed them even in simple toy examples. Some of > the regression tests I’ve seen already take this into account by running the > same test case multiple times and using the minimum or average value observed > (similar to some performance tests). While this approach is still not fully > deterministic, it enables the creation of tests where exceeding a certain > total allocation threshold consistently results in failure. > > Thanks, > Caio. > >> >> >> On Thu, Sep 25, 2025 at 9:00 AM Caio Lima <[email protected]> wrote: >> Hi everyone, >> >> The goal of this thread is to start a discussion about an extension on >> HeapStatistics API to allow us to get a counter for the total allocation >> that has happened in an Isolate since its creation, avoiding double counting >> allocation for objects that get promoted from young to old generations. >> >> The motivation here is to allow a more reliable way to create regression >> tests for compilers targeting WASM/JS, where it will be possible to properly >> calculate how much memory was allocated until a point in time. IIUC, the >> current API provides a HeapProfiler that would do some sort of this >> counting, however it isn’t the best fit to the kind of regressions tests, >> because we want as minimal overhead as possible, and the Allocation Observer >> used by HeapProfiler imposes some overhead. Given that, we have a proposal >> on how we could get a minimal overhead to count total allocation below. >> >> Proposal: >> • Add a new uint64_t field to HeapStatistics (tentatively named >> total_allocated_bytes_). >> • Expose this via uint64_t total_allocated_bytes() in the public API. >> • When Isolate::GetHeapStatistics is called, it would return the total >> number of bytes allocated since isolate creation. >> • Counting would be implemented with minimal overhead by: >> • Incrementing the global counter by the number of bytes allocated in >> a LinearAllocationArea (LAA) when a mutator releases the LAA back to the >> collector. >> • For spaces without LAA, such as Large Object Space, incrementing >> the counter when allocation occurs. >> >> We’d like to hear your thoughts on this proposal: >> >> • Does this approach make sense from a design perspective? >> • Are there concerns about overhead, naming, or API surface? >> • What would be required to get such an extension accepted upstream? >> >> Thanks in advance, >> Caio Lima. >> >> -- >> -- >> v8-dev mailing list >> [email protected] >> 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 [email protected]. >> To view this discussion visit >> https://groups.google.com/d/msgid/v8-dev/62c62b4a-3918-4215-994d-daa3089c1f80n%40googlegroups.com. >> >> -- >> -- >> v8-dev mailing list >> [email protected] >> http://groups.google.com/group/v8-dev >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "v8-dev" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/v8-dev/Avq3wgLmu68/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To view this discussion visit >> https://groups.google.com/d/msgid/v8-dev/CAKSzg3QEcGFjZJzofJu0%3Dkh9z0o5dzTj8%3DH8RsupKhNHuiyxWA%40mail.gmail.com. > > > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to a topic in the Google > Groups "v8-dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/v8-dev/Avq3wgLmu68/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/v8-dev/8300D20B-F525-4E12-A6AD-962D27FE17E8%40igalia.com. -- -- v8-dev mailing list [email protected] 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/v8-dev/80618F2B-7049-43DD-905C-2863F2ACC41C%40igalia.com.
