On Tue, Sep 30, 2025 at 1:52 PM Caio Lima <[email protected]> wrote:
> 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. > Yes, the suggestions aren't very smart. Someone from src/heap/OWNERS would be appropriate for this CL. Maybe someone volunteers on this thread. > 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. > Yes, that's expected; the ability to start dry runs is a separate permission that's orthogonal to CLAs. I've clicked the button for you. Looks like there's a bunch of failures; for faster iteration I recommend to reproduce them locally before trying to fix them (so that you can then verify the fix(es) locally too). > 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). > Speedometer and JetStream would be more relevant than those three. > 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/CAKSzg3TZd4004OYDtgz18Sqj%3DCavZNQLP%2Bv8zDHKj0gN8YiZYQ%40mail.gmail.com.
