[v8-dev] SetAlignedPointerInInternalField tagging

Hi I see a tag was added to SetAlignedPointerInInternalField, but is it checked anywhere? There's no tag passed to GetAlignedPointerFromInternalField. -- Erik -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you ar

Re: [v8-dev] V8 seems to assume amd64 pointers have high-16 set to 0, what if they're not?

mp;ss=chromium > . We don't want to do this for chrome, but a compile time option would be > fine. > > On Wed, Aug 6, 2025 at 2:56 PM Erik Corry wrote: > >> I'm running out of virtual memory on hardware that supports 5 level page >> tables, yes. >> >>

Re: [v8-dev] V8 seems to assume amd64 pointers have high-16 set to 0, what if they're not?

I'm running out of virtual memory on hardware that supports 5 level page tables, yes. On Wed, Aug 6, 2025 at 2:53 PM Olivier Flückiger wrote: > Right, if we request heap pages in that area. Are you running into this > issue? > > On Wed, Aug 6, 2025 at 2:26 PM Erik Corry wr

Re: [v8-dev] V8 seems to assume amd64 pointers have high-16 set to 0, what if they're not?

so far. > > That said, I don't think we have to worry about user space pointers in > that range according to > https://www.kernel.org/doc/Documentation/x86/x86_64/mm.txt . > > *oli > > > > On Mon, Aug 4, 2025 at 1:04 PM Erik Corry wrote: > >> Seems like thi

Re: [v8-dev] V8 seems to assume amd64 pointers have high-16 set to 0, what if they're not?

Seems like this will soon be a problem for Linux too. My /proc/cpuinfo says: address sizes : 52 bits physical, 57 bits virtual so it looks like we can't assume the high 16 bits are zero for much longer. On Tuesday, April 22, 2025 at 5:21:16 PM UTC+2 kebesoftwar...@gmail.com wrote: > Per the

Re: [v8-dev] Re: Status of design document "Generalizing V8's heap interface"

. This would also work with the linear handle backings, but it would not work with DirectHandle. > - Leszek > > On Friday, August 1, 2025 at 2:23:40 PM UTC+2 Erik Corry wrote: > > I'm not sure I'll have time to work on faster handles, but essentially the > idea is to use a

Re: [v8-dev] Re: Status of design document "Generalizing V8's heap interface"

nd > Handle allocation methods, without needing to manually pass in which handle > backing they need to go into. > > I'd be interested to hear more about your plans to make HandleScopes more > efficient though, they're still a performance pain point. > > - Leszek &g

[v8-dev] Status of design document "Generalizing V8's heap interface"

https://docs.google.com/document/d/1qVFbzenbzOIGsVC3PSP6fe_RQD0R4YwwQKcZYLyVtQ4/edit This document from 2020 has no comments and no LGTMs, but it was referenced from commits. Were the proposals accepted in this approximate form, or is it a proposal that didn't get implemented in this form? A diff

Re: [v8-dev] Isolate groups without pointer compression?

This isn't really caused by the IsolateGroup feature. The PagePool allows unused pages to be put in a pool so that other isolates can reuse them. This is a new performance feature from V8. It is more efficient to reuse a page than to unmap and then remap it later, which is two syscalls and probabl

Re: [v8-dev] Questions about the state of v8 fast API

Since JS doesn't have 64 ints, what does the pointer turn into on the JS side? On Tue, Apr 29, 2025 at 1:37 PM Aapo Alasuutari wrote: > It's a highly useful feature for doing FFI in JavaScript. Deno's FFI API > relies on it heavily, > as it enabl

[v8-dev] Reducing use of reinterpret_cast

Reinterpret_cast is generally thought to be a code smell. Reinterpret casts can cast absolutely anything to anything, and can introduce undefined behaviour. In addition the intent is not clear. Some uses of reinterpret_cast are for harmless things like signed or unsigned char. Others are very t

Re: [v8-dev] Re: WriteUtf8V2

Utf8Length? > Some sort of streaming output maybe? > > On Monday, February 17, 2025 at 4:10:41 PM UTC+1 Erik Corry wrote: > >> Would you be happy with a change that brings back the read-progress >> argument? >> >> On Monday, February 17, 2025 at 1:24:31 PM UTC+1 Er

[v8-dev] Re: WriteUtf8V2

Would you be happy with a change that brings back the read-progress argument? On Monday, February 17, 2025 at 1:24:31 PM UTC+1 Erik Corry wrote: > The new WriteUtf8V2 only writes as many bytes as there is space for, but > I'm not sure how to use this API. > > If not all th

[v8-dev] WriteUtf8V2

moved. Instead, only the number of UTF 8 bytes written is returned. Is the embedder expected to use that number to reverse engineer how many characters were read? It seems like this only works well if the output buffer is big enough to write the string in a single operation. -- Erik Corry -- -- v

Re: [v8-dev] External memory issues with v8 13.2 and 13.3

m >>>> modules to be shared across isolates, and that wasm lazy compilation causes >>>> memory usage of a wasm module -- as accounted by all isolates that have >>>> loaded it -- to change. >>>> >>>> Could it be that there is a memory leak in

Re: [v8-dev] External memory issues with v8 13.2 and 13.3

t;> >> Could it be that there is a memory leak in lazy compilation, such that >> these shared cached modules are gradually growing over time, to the point >> where new isolates that try to load these modules are being hit with >> extremely high "external memory"

Re: [v8-dev] External memory issues with v8 13.2 and 13.3

It looks like it's related to shared objects between isolates. Is there a newer document than https://docs.google.com/document/d/18lYuaEsDSudzl2TDu-nc-0sVXW7WTGAs14k64GEhnFg/edit?usp=drivesdk that describes how this works today? In particular cross-isolate GCs? On Mon, 13 Jan 2025, 15:25 Jakob Kum

Re: [v8-dev] checksum error when loading custom snapshot.

On Tue, Jan 7, 2025 at 6:56 PM Olivier Flückiger wrote: > Hi Ronald, > > first of all, indeed there are many flags around compression and snapshots > and picking random combinations is likely to yield a nonsensical or > unsupported build. Unfortunately there is enough churn that it's hard to > ma

Re: [v8-dev] 8GByte compressed pointer mode

ing considered as an option for the future, so we should keep it around > as well. > > On Mon, Dec 30, 2024 at 2:39 PM Erik Corry wrote: > >> There's an 8GB mode for compressed pointers. Is it in use by anybody? >> >> Another option where the utility is unclear is

[v8-dev] 8GByte compressed pointer mode

le it. -- Erik Corry -- -- 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 e

Re: [v8-dev] Re: What are the rules for destroying v8::Global?

It looks like the content_shell doesn't like that assert. Test failure on the code review. On Fri, Dec 20, 2024 at 12:06 PM Erik Corry wrote: > In that case we could start to enforce it. I had a go here: > https://chromium-review.googlesource.com/c/v8/v8/+/6108854 > > On Fri

Re: [v8-dev] Re: What are the rules for destroying v8::Global?

Isolate::Scopes in tests already. > > Best, > Dominik > > On Thursday, December 19, 2024 at 2:54:55 PM UTC+1 Erik Corry wrote: > >> Do you have to have entered the isolate to call the destructor of >> v8::Global? >> >> Here we have >> https://chromium.googl

[v8-dev] What are the rules for destroying v8::Global?

Do you have to have entered the isolate to call the destructor of v8::Global? Here we have https://chromium.googlesource.com/v8/v8.git/+/da4e529cfddb93e716c447a94d173e1e682f/test/cctest/test-serialize.cc#548 a Global that is above the isolate scope, so it gets destroyed after the isolate scope

[v8-dev] Gerrit trying to force a login

Starting today, if I'm logged into two google accounts, gerrit wants to force me to create an account for the /u/0 account (eg. @example.com) instead of letting me either look at it without login, or letting me switch to the domain that already has an account. Is this just how it's going to be, go

Re: [v8-dev] Sweeping with single-threaded GC

Nov 13, 2024 at 4:56 PM Omer Katz (chromium.org) < >> omerk...@chromium.org> wrote: >> >>> Sweeping happens either concurrently (disabled by --single-threaded-gc) >>> or on allocation if we will otherwise run out of memory. >>> It's possible that

Re: [v8-dev] Sweeping with single-threaded GC

ed-gc) or > on allocation if we will otherwise run out of memory. > It's possible that you don't hit the cases that would require sweeping on > allocation. > > On Wed, Nov 13, 2024 at 4:49 PM Erik Corry wrote: > >> We run with --single-threaded-gc. It looks like no

[v8-dev] Sweeping with single-threaded GC

We run with --single-threaded-gc. It looks like no sweeping of old space takes place until the next old-space GC starts up. Does this sound likely? I'm putting a breakpoint in Sweeper::RawSweep, and it's not hit between old-space-GCs, even though the GC state is SWEEPING. Is there a different p

[v8-dev] Patches for V8 branches

will be security updates on V8 version 12.9 in the intervening period? -- Erik Corry -- -- 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

[v8-dev] Does v8_enable_fast_mksnapshot affect the output?

;, which I don't think changes the generated code. -- Erik Corry -- -- 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 gro

Re: [v8-dev] Distcc

compile times from 1-2 hours to 10-15 minutes > from clean. > > Let me know if you need some help with this. > > Kind regards, > > Graeme > > On 19 Sep 2024, at 18:02, Erik Corry wrote: > > Hi > > The compile times are killing me. > > Does anyone have g

[v8-dev] Distcc

edit a .h file. -- Erik Corry -- -- 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,

[v8-dev] Workflow for working on a gerrit cl from more than one machine

Hi Do people work on the same gerrit cl from multiple machines? I tried git cl checkout but it doesn't work. eg. for https://chromium-review.googlesource.com/c/v8/v8/+/5797602 $ cat ../.gclient solutions = [ { "name": "v8", "url": "https://chromium.googlesource.com/v8/v8.git";, "d

Re: [v8-dev] Re: An update on bit_cast

Yes. We plan to put in asserts to prevent it being used for pointer types. On 4 December 2015 at 15:30, Jochen Eisinger wrote: > thanks for the heads-up. > > Did you keep the bit_casts in fletch for non-pointer types? > > On Thu, Dec 3, 2015 at 2:34 PM 'Erik Corry&#x

[v8-dev] Re: An update on bit_cast

Slava points out that I am writing about use of bit_cast for pointer types (eg casting an Object** to a Class**), but ignoring the other use of bit_cast (eg casting a float to a uint32_t). It's only the pointer types that are problematic, I think. On 3 December 2015 at 13:37, Erik Corry

[v8-dev] An update on bit_cast

e regression on Linux, but not on Mac and Windows where I think it already is the default. -- Erik Corry Google Denmark ApS Frederiksborggade 20B, 1 sal 1360 København K Denmark CVR nr. 28 86 69 84 -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You

[v8-dev] MIPS regexp code

ts is LoadCurrentCharacterUnchecked, which generates: addiu t7, t2, cp_offset addut5, t6, t7 lbu t3, 0(t5) This should just be addu t5, t6, t2 lbu t3, cp_offset(t5) Probably fixing this won't be enough to let MIPS pass the test though. There's other stuff going on there that I haven't

[v8-dev] Reland II of 'Optimize trivial regexp disjunctions' CL 1176453002 (issue 1180433003 by erikco...@chromium.org)

Reviewers: Yang, Description: Reland II of 'Optimize trivial regexp disjunctions' CL 1176453002 R=yang...@chromium.org BUG= Please review this at https://codereview.chromium.org/1180433003/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+251, -8 lines): M src/a

[v8-dev] Reland of 'Optimize trivial regexp disjunctions' CL 1176453002 (issue 1174713002 by erikco...@chromium.org)

Reviewers: Yang, Description: Reland of 'Optimize trivial regexp disjunctions' CL 1176453002 Original code review: https://codereview.chromium.org/1176453002/ TBR=yang...@chromium.org BUG=chromium:482998 LOG=n Please review this at https://codereview.chromium.org/1174713002/ Base URL: https:/

[v8-dev] Optimize trivial regexp disjunctions (issue 1176453002 by erikco...@chromium.org)

Reviewers: Yang, Description: Optimize trivial regexp disjunctions R=yang...@chromium.org BUG=chromium:482998 LOG=n Please review this at https://codereview.chromium.org/1176453002/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+235, -4 lines): M src/ast.h M

[v8-dev] Re: MIPS64: Improve long branches utilizing code range. (issue 1147503002 by dusan.milosavlje...@imgtec.com)

LGTM https://codereview.chromium.org/1147503002/ -- -- 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 i

[v8-dev] Re: MIPS64: Improve long branches utilizing code range. (issue 1147503002 by dusan.milosavlje...@imgtec.com)

https://codereview.chromium.org/1147503002/diff/11/src/heap/spaces.cc File src/heap/spaces.cc (right): https://codereview.chromium.org/1147503002/diff/11/src/heap/spaces.cc#newcode659 src/heap/spaces.cc:659: commit_size > CodePageAreaSize()) { The commit_size includes the CodePageGuardSt

[v8-dev] Re: Cosmetic changes to tests to make it easier to concatenate them. (issue 1163803002 by erikco...@chromium.org)

On 2015/06/01 15:52:40, ulan wrote: wow, lgtm. After you removed the wrapping of tests and undefs, does this CL still help with concatenation? For now I will just not concatenate the affected files. It's quite hard to automate namespace stuff. One unexpected thing I found was that this

[v8-dev] Re: Cosmetic changes to tests to make it easier to concatenate them. (issue 1163803002 by erikco...@chromium.org)

https://codereview.chromium.org/1163803002/diff/1/src/background-parsing-task.cc File src/background-parsing-task.cc (right): https://codereview.chromium.org/1163803002/diff/1/src/background-parsing-task.cc#newcode75 src/background-parsing-task.cc:75: } // namespace v8 On 2015/06/01 13:08:24, u

[v8-dev] Tiny fix to grokdump heap stats printer (issue 1164693002 by erikco...@chromium.org)

Reviewers: Hannes Payer, Description: Tiny fix to grokdump heap stats printer R=hpa...@chromium.org BUG= Please review this at https://codereview.chromium.org/1164693002/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+1, -1 lines): M tools/grokdump.py Index:

[v8-dev] Re: MIPS64: Improve long branches utilizing code range. (issue 1147503002 by dusan.milosavlje...@imgtec.com)

One solution would be to get large objects from the reserved code area, but continue to get normal code pages from unreserved memory. Then you are not imposing a 256Mbyte code limit on the platform, but only a 256Mbyte limit on large code objects (> 1Mbyte). https://codereview.chromium.org/11475

[v8-dev] Cosmetic changes to tests to make it easier to concatenate them. (issue 1163803002 by erikco...@chromium.org)

Reviewers: ulan, Description: Cosmetic changes to tests to make it easier to concatenate them. When compiling on a laptop I like to concatenate the small test files. This makes a big difference to compile times. These changes make that easier. R=u...@chromium.org BUG= Please review this at htt

[v8-dev] Remove spurious prints from GC logging (issue 1149413003 by erikco...@chromium.org)

Reviewers: Hannes Payer, szager1, Description: Remove spurious prints from GC logging R=hpa...@chromium.org, sza...@chromium.org BUG= Please review this at https://codereview.chromium.org/1149413003/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+1, -1 lines):

[v8-dev] Re: MIPS64: Improve long branches utilizing code range. (issue 1147503002 by dusan.milosavlje...@imgtec.com)

Only large objects can span a 256Mbyte boundary, so an alternative implementation would fix large-object allocation to reject allocations that span such a boundary. In this scenario you would not need to reserve code space up front and there would be n 256Mbyte limit on code size? https://co

[v8-dev] Even without --trace-gc dump the last few GC messages on OOM (issue 1159513003 by erikco...@chromium.org)

Reviewers: Hannes Payer, Description: Even without --trace-gc dump the last few GC messages on OOM If we crash V8 due to out-of-memory then we print the last 3 GCs on stdout as we crash. Also records the last 3 GCs on the stack so that it will be part of the minidump. R=hpa...@chromium.org BUG=

[v8-dev] grokdump.py - some support for on-stack HeapStats (issue 1142343009 by erikco...@chromium.org)

Reviewers: ulan, Description: grokdump.py - some support for on-stack HeapStats R=u...@chromium.org BUG= Please review this at https://codereview.chromium.org/1142343009/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+22, -4 lines): M tools/grokdump.py Index

[v8-dev] Re: Version 4.3.61.27 (cherry-pick) (issue 1163563002 by erikco...@chromium.org)

Committed patchset #1 (id:1) manually as 85e92361bb42b9076ebdcb1c005fce9242bc5fe6. https://codereview.chromium.org/1163563002/ -- -- 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 "v

[v8-dev] Version 4.3.61.27 (cherry-pick) (issue 1163563002 by erikco...@chromium.org)

Reviewers: Hannes Payer, Description: Version 4.3.61.27 (cherry-pick) Merged 49fdc5323 Be sure to abort incremental GC when trying to reserve space R=hpa...@chromium.org BUG= Please review this at https://codereview.chromium.org/1163563002/ Base URL: https://chromium.googlesource.com/v8/v8.g

[v8-dev] Re: Version 4.3.61.26 (cherry-pick) (issue 1157393002 by erikco...@chromium.org)

Committed patchset #1 (id:1) manually as 17db4ce193547f334c6cc63e27e1f9a0b434fcb7. https://codereview.chromium.org/1157393002/ -- -- 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 "v

[v8-dev] Version 4.3.61.26 (cherry-pick) (issue 1157393002 by erikco...@chromium.org)

Reviewers: Yang, Description: Version 4.3.61.26 (cherry-pick) Merged 5a93a3304 Reland: Fix JSON parser Handle leak (previous CL 1041483004) BUG=472504,v8:3976 LOG=N R=yang...@chromium.org Please review this at https://codereview.chromium.org/1157393002/ Base URL: https://chromium.googlesourc

[v8-dev] Version 4.3.61.26 (cherry-pick) (issue 1159063003 by erikco...@chromium.org)

Reviewers: Yang, Description: Version 4.3.61.26 (cherry-pick) Merged 5a93a3304 Reland: Fix JSON parser Handle leak (previous CL 1041483004) BUG=472504,v8:3976 LOG=N R=yang...@chromium.org Please review this at https://codereview.chromium.org/1159063003/ Base URL: https://chromium.googlesourc

[v8-dev] grokdump.py: work around int size limits on xrange (issue 1158933007 by erikco...@chromium.org)

Reviewers: Hannes Payer, Description: grokdump.py: work around int size limits on xrange R=hpa...@chromium.org BUG= Please review this at https://codereview.chromium.org/1158933007/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+23, -15 lines): M tools/grokdum

[v8-dev] Random hashes with a more cache-friendly distribution (issue 1158083002 by erikco...@chromium.org)

Reviewers: adamk, Toon Verwaest, Description: Random hashes with a more cache-friendly distribution R=ad...@chromium.org, verwa...@chromium.org BUG= Please review this at https://codereview.chromium.org/1158083002/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+

[v8-dev] Speed up object-keyed Map and Set by giving out sequential hash codes (issue 1157073002 by erikco...@chromium.org)

Reviewers: adamk, Toon Verwaest, Description: Speed up object-keyed Map and Set by giving out sequential hash codes R=ad...@chromium.org, verwa...@chromium.org BUG= Please review this at https://codereview.chromium.org/1157073002/ Base URL: https://chromium.googlesource.com/v8/v8.git@master A

[v8-dev] Re: Move hash code from hidden string to a private symbol (issue 1149863005 by erikco...@chromium.org)

https://codereview.chromium.org/1149863005/ -- -- 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, sen

[v8-dev] Re: Hook up more import/exports in natives. (issue 1154483002 by yang...@chromium.org)

This changes global variables into variables in functions. I know we have some optimization for functions in globals that don't change. Do we lose some optimizations by making them into outer-scope variables? https://codereview.chromium.org/1154483002/ -- -- v8-dev mailing list v8-dev@google

[v8-dev] Re: Move hash code from hidden string to a private symbol (issue 1149863005 by erikco...@chromium.org)

object-observe.js (right): https://codereview.chromium.org/1149863005/diff/40001/src/object-observe.js#newcode210 src/object-observe.js:210: return %WeakCollectionGet(GetObservationStateJS().objectInfoMap, object, $gethash(object)); On 2015/05/21 20:19:02, Erik Corry wrote: On 2015/05/21 19:11:32, adamk wrote: >

[v8-dev] Re: Move hash code from hidden string to a private symbol (issue 1149863005 by erikco...@chromium.org)

https://codereview.chromium.org/1149863005/diff/40001/src/collection.js File src/collection.js (left): https://codereview.chromium.org/1149863005/diff/40001/src/collection.js#oldcode26 src/collection.js:26: for (var entry = HashToEntry(table, hash, numBuckets); On 2015/05/21 19:11:32, adamk wrot

[v8-dev] Move hash code from hidden string to a private symbol (issue 1149863005 by erikco...@chromium.org)

Reviewers: adamk, toon_chromium.org, Description: Move hash code from hidden string to a private symbol R=ad...@chromium.org, t...@chromium.org BUG= Please review this at https://codereview.chromium.org/1149863005/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+

[v8-dev] Regularize namespace closing curlies (issue 1143133002 by erikco...@chromium.org)

Reviewers: Toon Verwaest, Description: Regularize namespace closing curlies R=verwa...@chromium.org BUG= Please review this at https://codereview.chromium.org/1143133002/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+67, -67 lines): M src/compiler/ast-loop-as

[v8-dev] Re: Remove 64-bit unclean line from heap size estimation (issue 1133243006 by erikco...@chromium.org)

On 2015/05/15 16:13:34, Jakob wrote: I don't remember the specifics; this is the CL that introduced that line: https://codereview.chromium.org/70233010 This just happens to be the boundary between intptr_t and int64_t worlds. On 32-bit platforms, we need to guard against overflow there. Why d

[v8-dev] Adjust benchmark framework to avoid spending 50% of time on 'new Date' (issue 1133843007 by erikco...@chromium.org)

Reviewers: Dmitry Lomov (chromium), Description: Adjust benchmark framework to avoid spending 50% of time on 'new Date' R=dslo...@chromium.org BUG= Please review this at https://codereview.chromium.org/1133843007/ Base URL: https://chromium.googlesource.com/v8/v8.git@master Affected files (+6

[v8-dev] Re: Shrink active semi-space and uncommit other semi-space only in idle memory mode. (issue 1140693003 by hpa...@chromium.org)

lgtm https://codereview.chromium.org/1140693003/ -- -- 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

[v8-dev] Re: Make sure that idle scavenges are just performed when enough objects are allocated in new space. (issue 1138643003 by hpa...@chromium.org)

https://codereview.chromium.org/1138643003/diff/1/src/heap/gc-idle-time-handler.cc File src/heap/gc-idle-time-handler.cc (right): https://codereview.chromium.org/1138643003/diff/1/src/heap/gc-idle-time-handler.cc#newcode141 src/heap/gc-idle-time-handler.cc:141: // The allocated new space limit t

[v8-dev] Re: Make sure that idle scavenges are just performed when enough objects are allocated in new space. (issue 1138643003 by hpa...@chromium.org)

lgtm https://codereview.chromium.org/1138643003/ -- -- 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

[v8-dev] Re: Use a private own symbol instead of a hidden property for hash codes (issue 1142493002 by erikco...@chromium.org)

https://codereview.chromium.org/1142493002/diff/1/src/collection.js File src/collection.js (right): https://codereview.chromium.org/1142493002/diff/1/src/collection.js#newcode85 src/collection.js:85: if (IS_SPEC_OBJECT(key)) { On 2015/05/14 15:01:27, adamk wrote: You might need a TODO here for

[v8-dev] Re: Use a private own symbol instead of a hidden property for hash codes (issue 1142493002 by erikco...@chromium.org)

Surely it always caused a map transition. How else can you add the hidden property? The change was to make an already existing test pass, but I can add another. https://codereview.chromium.org/1142493002/ -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --

[v8-dev] Re: Use a private own symbol instead of a hidden property for hash codes (issue 1142493002 by erikco...@chromium.org)

On my microbenchmark this doubles the speed of common operations on ES6 Map. I think it's a simplification too. Before (times in ms): Read 514 Update 1083 Set/delete 2075 After: Read 231 Update 484 Set/delete 1619 The microbenchmark: function MyKey() { this.x = "foo"; } function setu

[v8-dev] Re: Never uncommit the whole marking deque in case we can't get it back (issue 1133153003 by erikco...@chromium.org)

Previous version at https://codereview.chromium.org/1134743002/ would: * Reserve and commit 256k at start. * Try to increase reservation and commit to up to 4MBytes when GCing. * Uncommit and unreserve everything after GC <-- this was dumb New tactic. * Reserve 4Mbytes from start and never chan

[v8-dev] Re: If marking deque allocation fails, try to make do with a smaller one (issue 1134743002 by erikco...@chromium.org)

New attempt at https://codereview.chromium.org/1133153003 https://codereview.chromium.org/1134743002/ -- -- 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 unsubsc

[v8-dev] Re: Only record one in n line endings to save space. (issue 1137683003 by erikco...@chromium.org)

Moving everything to C++ would be one option, but not something I am planning to work on. https://codereview.chromium.org/1137683003/ -- -- 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

[v8-dev] Re: Postpone counters triggered during GC, and use a HandleScope when calling back. (issue 1125383007 by erikco...@chromium.org)

I promise that nothing in Blink will depend on the new value. V8 already has some values here (3, 4, 5 and 6) that Blink knows nothing about, and that works now. It used to be the case that Blink was anal about it, but not recently. https://codereview.chromium.org/1125383007/diff/1/src/hea

[v8-dev] Re: If marking deque allocation fails, try to make do with a smaller one (issue 1134743002 by erikco...@chromium.org)

Unfortunately the crashes are still there and I can see why. This patch does not go far enough. Although we reserve some space already at startup we unreserve it after each GC (in UncommitMarkingDeque) and then it can potentially fail at the next GC. https://codereview.chromium.org/1134743

[v8-dev] Re: Add mode to reduce memory usage in idle notification. (issue 1105293004 by u...@chromium.org)

This is in Canary 2396 It is referenced from https://code.google.com/p/chromium/issues/detail?id=486005 https://codereview.chromium.org/1105293004/ -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed

[v8-dev] Re: If marking deque allocation fails, try to make do with a smaller one (issue 1134743002 by erikco...@chromium.org)

This is part of canary 2397 https://codereview.chromium.org/1134743002/ -- -- 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

[v8-dev] Re: Be sure to abort incremental GC when trying to reserve space (issue 1124553007 by erikco...@chromium.org)

This is part of canary 2395 https://codereview.chromium.org/1124553007/ -- -- 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

[v8-dev] Re: If marking deque allocation fails, try to make do with a smaller one (issue 1131893002 by erik.co...@gmail.com)

Argh! Wrong user. Moved to https://codereview.chromium.org/1134743002 https://codereview.chromium.org/1131893002/ -- -- 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" grou

[v8-dev] Re: Add mode to reduce memory usage in idle notification. (issue 1105293004 by u...@chromium.org)

lgtm https://codereview.chromium.org/1105293004/ -- -- 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

[v8-dev] Re: Add another test for accessing IdentityMap with SMI keys when it is _not_ empty. (issue 1127113002 by tit...@chromium.org)

Shouldn't you also fix the assert so it is before checking for emptiness? https://codereview.chromium.org/1127113002/ -- -- 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" gr

[v8-dev] Re: Add mode to reduce memory usage in idle notification. (issue 1105293004 by u...@chromium.org)

can_start_incremental_marking is false. On 2015/05/06 09:47:19, ulan wrote: On 2015/05/05 21:38:52, Erik Corry wrote: > This contradiction indicates to me that can_start_incremental_marking is > misnamed. Is should_start_incremental_marking better? I can rename it in a separate CL. Yes, we can do i

[v8-dev] Re: Implement IdentityMap, a robust, GC-safe object-identity HashMap. (issue 1105693002 by tit...@chromium.org)

LGTM, if you have considered the things in comment 25 and a few missed comments futher up. https://codereview.chromium.org/1105693002/ -- -- 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

[v8-dev] Re: Add mode to reduce memory usage in idle notification. (issue 1105293004 by u...@chromium.org)

https://codereview.chromium.org/1105293004/diff/11/src/heap/gc-idle-time-handler.cc File src/heap/gc-idle-time-handler.cc (right): https://codereview.chromium.org/1105293004/diff/11/src/heap/gc-idle-time-handler.cc#newcode198 src/heap/gc-idle-time-handler.cc:198: // In kReduceLatency mod

Re: [v8-dev] Re: Issue 3880 in v8: Linking binaries takes ages

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...@googlegr

[v8-dev] Re: Implement IdentityMap, a robust, GC-safe object-identity HashMap. (issue 1105693002 by tit...@chromium.org)

On 2015/04/29 03:43:10, Benedikt Meurer wrote: On 2015/04/27 07:57:51, titzer wrote: > https://codereview.chromium.org/1105693002/diff/1/src/heap/identity-map.h > File src/heap/identity-map.h (right): > > https://codereview.chromium.org/1105693002/diff/1/src/heap/identity-map.h#newcode68 > s

[v8-dev] Re: Implement IdentityMap, a robust, GC-safe object-identity HashMap. (issue 1105693002 by tit...@chromium.org)

I'm warming to this change/coming to terms with its inevitability. Some non-blocking comments to consider. * Please reconsider the 4x growth factor. It's caused by the resizing heuristic which is an unusual feature. * Currently you can have a resize during a rehash. You should either be s

[v8-dev] Re: Implement IdentityMap, a robust, GC-safe object-identity HashMap. (issue 1105693002 by tit...@chromium.org)

My mistake. I had missed that the Rehash takes place on the compiler thread after a failed lookup. Tricky! https://codereview.chromium.org/1105693002/diff/60001/src/heap/heap.cc File src/heap/heap.cc (right): https://codereview.chromium.org/1105693002/diff/60001/src/heap/heap.cc#newcode5034 s

[v8-dev] Re: Print PID and isolate address in gc traces. (issue 1109133002 by hpa...@chromium.org)

lgtm https://codereview.chromium.org/1109133002/ -- -- 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

[v8-dev] Re: Implement IdentityMap, a robust, GC-safe object-identity HashMap. (issue 1105693002 by tit...@chromium.org)

https://codereview.chromium.org/1105693002/diff/60001/src/heap/identity-map.h File src/heap/identity-map.h (right): https://codereview.chromium.org/1105693002/diff/60001/src/heap/identity-map.h#newcode88 src/heap/identity-map.h:88: *(reinterpret_cast(GetEntry(key))) = value; This assignment take

[v8-dev] Re: Shrink new space and uncommit from space in idle notification during long idle times. (issue 1108133003 by hpa...@chromium.org)

lgtm https://codereview.chromium.org/1108133003/ -- -- 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

[v8-dev] Re: Implement IdentityMap, a robust, GC-safe object-identity HashMap. (issue 1105693002 by tit...@chromium.org)

right): https://codereview.chromium.org/1105693002/diff/20001/src/heap/identity-map.cc#newcode72 src/heap/identity-map.cc:72: Resize(); // Should only have to resize once, since we grow 4x. On 2015/04/27 16:32:50, titzer wrote: On 2015/04/27 15:39:13, Erik Corry wrote: > That's very agg

[v8-dev] Re: Implement IdentityMap, a robust, GC-safe object-identity HashMap. (issue 1105693002 by tit...@chromium.org)

I'm going to stop here and ask a more fundamental question: We already have HashTable from objects.h. Can't we add rehashing-on-GC to that instead of adding code to the code base? This implementation increases the number of roots, potentially quite a lot, thus making our atomic pauses at the s

[v8-dev] Re: Version 4.3.61.13 (cherry-pick) (issue 1107483003 by rmcil...@chromium.org)

lgtm https://codereview.chromium.org/1107483003/ -- -- 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

[v8-dev] Re: Use smaller heap growing factor in idle notification to start incremental marking when there is idl... (issue 1090963002 by hpa...@chromium.org)

LGTM https://codereview.chromium.org/1090963002/diff/20001/src/heap/gc-idle-time-handler.h File src/heap/gc-idle-time-handler.h (right): https://codereview.chromium.org/1090963002/diff/20001/src/heap/gc-idle-time-handler.h#newcode126 src/heap/gc-idle-time-handler.h:126: static const size_t kMax

[v8-dev] Re: Mark faster. Preperation for new insertion barrier. (issue 1081253005 by hpa...@chromium.org)

https://codereview.chromium.org/1081253005/diff/1/src/heap/incremental-marking.h File src/heap/incremental-marking.h (right): https://codereview.chromium.org/1081253005/diff/1/src/heap/incremental-marking.h#newcode106 src/heap/incremental-marking.h:106: static const intptr_t kMarkingSpeedAccelle

[v8-dev] Mark objects black. (issue 996983003 by hpa...@chromium.org)

https://codereview.chromium.org/996983003/diff/120001/src/heap/incremental-marking.h File src/heap/incremental-marking.h (right): https://codereview.chromium.org/996983003/diff/120001/src/heap/incremental-marking.h#newcode98 src/heap/incremental-marking.h:98: static const intptr_t kAllocatedThre

[v8-dev] Re: v8:3539 - hold constructor feedback in weak cells (issue 1029093002 by mvstan...@chromium.org)

I'm a bit late here, but: https://codereview.chromium.org/1029093002/diff/140001/src/arm/code-stubs-arm.cc File src/arm/code-stubs-arm.cc (right): https://codereview.chromium.org/1029093002/diff/140001/src/arm/code-stubs-arm.cc#newcode2377 src/arm/code-stubs-arm.cc:2377: // Arguments register m

  1   2   3   4   5   6   7   8   9   10   >