Re: [v8-dev] Re: Fix printing of Harmony Set and Map instances. (issue 20705003)

On Thu, Aug 1, 2013 at 10:32 AM, wrote: > (I wish we could automate this somehow) > http://www.haskell.org/haskellwiki/Template_Haskell :-D -- -- 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

Re: [v8-dev] Re: tweak of Math.abs in its x64 stub (issue 22285003)

On Tue, Aug 6, 2013 at 3:05 PM, wrote: > On 2013/08/06 12:56:17, Jakob wrote: > >> Unifying lithium codegen and the stub sounds reasonable. Maybe you can do >> a >> microbenchmark to figure out whether the branchless stub code or the >> > conditional > >> "neg" in lithium is faster in practice. >

Re: [v8-dev] Re: tweak of Math.abs in its x64 stub (issue 22285003)

On Wed, Aug 7, 2013 at 2:50 AM, Weiliang Lin wrote: > Yes, I agree with you, especially on IA32 which does not have much > registers. > That platform is my main concern, too, especially because it is still the most important platform we have. > So could I have a conclusion here. The branchless

[v8-dev] Re: Remove HandleScope default ctor. (issue 23530045)

Another lo-tech solution: Make chromium/src/v8 a link to your bleeding_edge v8 repo, gclient runhooks + ninja will tell you if there will be breakage. -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed

Re: [v8-dev] Re: Enable preaging of code objects for low-memory devices. (issue 23480031)

On Fri, Sep 13, 2013 at 11:30 AM, wrote: > On 2013/09/13 06:24:25, Sven Panne wrote: > >> On 2013/09/12 18:16:24, Hannes Payer wrote: >> > All right, the patch looks fine. But I don't think we should do it for >> > non-memory-constrained devices, at l

Re: [v8-dev] Re: Enable preaging of code objects for low-memory devices. (issue 23480031)

On Fri, Sep 13, 2013 at 11:56 AM, wrote: > It would be funky to overrule Isolate::is_memory_**constrained() to > experiment > with this feature if needed. This would work if our boolean flag handling could actually differentiate between --foo, --no-foo and no foo flag at all. I am not sure if w

[v8-dev] Re: Lower heap space size limits if is_memory_constrained(). (issue 24269003)

On Fri, Sep 20, 2013 at 1:25 PM, wrote: > [...] then I think it would be best to have some clear entry point > to initialize V8 where it's explicit to the embedder that they should be > setting > these constraints. This is difficult right now due to the default isolate, > and I > don't think havi

[v8-dev] Re: Removed normalization in AddFastProperty (issue 8414019)

Ignoring our beloved oscillating benchmarks, the golem run I posted shows some tiny improvements for a few benchmarks, but overall things don't really changed. As I said, in my previous mail, this CL wasn't done to improve performance, just to clear things up a bit while trying to reuse some code.

Re: [v8-dev] Put a slow assert under the enable_slow_asserts flag. (issue 9212040)

On Tue, Jan 24, 2012 at 02:32, wrote: > Reviewers: Kevin Millikin, > > Description: > Put a slow assert under the enable_slow_asserts flag. > > Otherwise really large functions take too long to compile > in debug mode. [...] > IIRC, this is the place where v8 basically "hangs" when it tries to c

[v8-dev] Re: Re-land CL 9466047. (issue 9584003)

There was no issue in the tracker, the previous CL made the browser test mentioned in the CL description fail occasionally. On Mon, Mar 5, 2012 at 08:09, wrote: > I would very much prefer if a CL description included a mention of which > issue > the change fixes. > > https://chromiumcodereview.*

Re: [v8-dev] [v8] r10913 committed - Set x86 FPU precision to 64-bit for MinGW. Original patch by Jonathan ...

I was just about to write the same, but Erik was faster... :-) The point is that the mode is process-global state, and we can't really change that. I think the main point is not about 80 or 64 bit, but being consistent in what we calculate. This issue arose last week, where it became obvious that

Re: [v8-dev] Re: Fix compilation with clang -integrated-as on ARM. (issue 10177004)

I don't know the exact story behind this CL, but as a general rule of thumb, one should never commit directly to v8's trunk. Open a new CL against v8's bleeding_edge, so we can land it for you. We push bleeding_edge a few times a week into trunk (when things go well), so there should only be a smal

[v8-dev] Re: Use map transitions when defining accessor properties. (issue 10238005)

Just a short remark here (I'm just doing a quick mail scan from home): I submitted my patch to golem 3 times before I landed it, and apart from our usual heavy flakiness, there were no significant changes in the benchmark numbers, as expected. How did you measure the 25%? Did you measure against di

Re: [v8-dev] Re: Fix for issue 2132. (issue 10411016)

Just a quick remark while skimming through my impressive mail backlog: While splitting this specific phase into 2 parts might solve our problem at hand, I think the overall direction should be even more general, especially in the light of potentially parallel compilation, which would allow more exp

Re: [v8-dev] [v8] r11784 committed - Martyn Capewell ...

Well, I did the usual "git cl patch 314159" plus a "git cl dcommit -c '...'", this should yield the right commit message, I think. But I had to tweak the patch a tiny bit, perhaps the local commit screwed things up... On Tue, Jun 12, 2012 at 7:28 PM, Erik Corry wrote: > Please use commit message

Re: [v8-dev] Re: Workarround for: Chrome dev tools crashes when taking a heap snapshot of Docs offline shared worker. (issue 10543160)

Perhaps this was intentionally done, in anticipation of the "Talk like a Pirate Day"? ;-) A... http://www.talklikeapirate.com/ On Thu, Jun 14, 2012 at 12:43 PM, wrote: > > https://chromiumcodereview.**appspot.com/10543160/diff/** > 2002/src/profile-generator.cc

[v8-dev] Re: Implemented StoreIC for setters. (issue 10534091)

Good point, I've just submitted http://codereview.chromium.org/10735003/ to fix that. The tricky part was getting LookupForWrite right, it won't win a beauty contest in its current form, though... :-P On Sun, Jun 17, 2012 at 12:17 PM, wrote: > [...] Is there any reason why we are not giving bene

Re: [v8-dev] [v8] r12178 committed - Android test runner: Make android-sync.sh work on Mac...

Higher-order shell programming? ;-) -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev

[v8-dev] Re: Introduced TypeFeedbackId and BailoutId types. (issue 10831172)

... and here the upcoming hopefully performance-neutral ;-) golem4 numbers: http://go/darta/Comparison#targetA=v8;machineTypeA=linux-ia32;revisionA=12255;patchA=svenpanne-separate-ids;targetB=v8;machineTypeB=linux-ia32;revisionB=12255 http://go/darta/Comparison#targetA=v8;machineTypeA=linux-x64;re

Re: [v8-dev] Re: Use integer division in a certain case. (issue 10825071)

Personally, I'd like to drop the patch for several reasons: It is adding a considerable amount of complexity for very restricted use cases, and I really don't like having just another "MathFloorOfDiv"-like mess in our code base. Furthermore, the initial problem of undoing alpha pre-multiplication c

Re: [v8-dev] MIPS: port First steps towards better code generation for LBranch. (issue7170006)

Ooops, sorry, I had the very same change in my local copy, but it slipped through my change list... :-/ In general, I try to change the MIPS part accordingly, but I can't even compile it. Cheers, S. -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev

Re: [v8-dev] Fix build on x64 (issue7284011)

Or even simpler: Use the %p conversion specifier, without any need for ugly casting... On Wed, Jun 29, 2011 at 16:27, wrote: > Reviewers: Søren Gjesse, > > Message: > PTAL. > > Description: > Fix build on x64 > > > Please review this at > http://codereview.chromium.**org/7284011/

Re: [v8-dev] Re: Introduce a poor man's version of STL's bitset. (issue7472029)

I've seen BitField, but this is for a slightly different purpose, namely a replacement for C's bit fields. I don't even know why we need BitField, because it's in the language itself, perhaps some strange compiler doesn't handle it? EnumSet OTOH is (not surprisingly ;-) a data type for a set of val

[v8-dev] Re: Implement type recording for ToBoolean on x64. (issue7544012)

CheckOddball is indeed a very specific function, so what I'm currently trying to do is adding a CompareRoot method to the IA32 macro assembler (x64 and ARM have this already). The only downside is that the method is a bit ugly and contains some code duplication from the ROOT_ACCESSOR macro in facto

Re: [v8-dev] Re: Merge r8833 "Minimize malloc heap allocation on process startup" to 3.2. (issue7575013)

I am currently trying to fix an issue where I need the most recent Chrome 12 (12.0.747.0) combined with a recent version of v8's 3.2 branch. I've just noticed that revision 3.2.10.34 (the "minimize malloc" patch above) broke Chrome 12, resulting in an immediate "Aw snap" tab after startup due to a

Re: [v8-dev] Re: Merge r8833 "Minimize malloc heap allocation on process startup" to 3.2. (issue7575013)

S. On Thu, Aug 18, 2011 at 17:41, Vitaly Repeshko wrote: > Sven, can you change the GetEntered implementation to lazily initialize the > isolate like it's done in some other API functions? > > -- Vitaly > On Aug 18, 2011 6:53 PM, "Sven Panne" wrote: > > I am cur

Re: [v8-dev] Re: Unify UpdateSlotsOnPage and SweepPrecisely. (issue7706004)

http://restuta.net/clean-code/making-boolean-parameters-readable/ :-D On Tue, Aug 23, 2011 at 09:48, wrote: > Added new patch set. > > > > http://codereview.chromium.**org/7706004/diff/1/src/mark-**compact.cc > File src/mark-comp

Re: [v8-dev] Re: Deprecate profiler methods that accept security origin (issue 16114002)

On Tue, May 28, 2013 at 8:14 AM, wrote: > That would break compilation because of V8_DEPRECATED markers on the > methods being invoked from the tests. I didn't follow all the details of this CL, but if it is only about temporarily using deprecated stuff in our cctests, just #define V8_DISABLE_D

Re: [v8-dev] Re: Reorder switch clauses using newly-introduced execution counters in (issue 16128004)

On Mon, Jun 3, 2013 at 1:28 PM, Florian Schneider wrote: > I disagree here: I think in a JS world, the "standard" optimizations are > the big hammer. They also only work really well for C-like switches. > But I think we *do* actually have C-like switches in real-world code like CPU emulators etc.

Re: [v8-dev] Re: Reorder switch clauses using newly-introduced execution counters in (issue 16128004)

On Mon, Jun 3, 2013 at 4:25 PM, Florian Schneider wrote: > I'm not saying that other techniques are worse or better by any means. I > think they are complementary to using frequency counts. Ideally, for > instance, the optimal binary decision tree will be built using the measured > probabilities o

Re: [v8-dev] Re: Reorder switch clauses using newly-introduced execution counters in (issue 16128004)

On Tue, Jun 4, 2013 at 8:53 AM, Fedor Indutny wrote: > Sorry, I know that's the normal way of doing things, but I was just > spending my free time at weekend to spend on programming and decided to do > some experiments with v8. I'll be glad to contribute some of the mentioned > stuff if you see n

Re: [v8-dev] Re: Reorder switch clauses using newly-introduced execution counters in (issue 16128004)

On Tue, Jun 4, 2013 at 6:02 PM, Fedor Indutny wrote: > As a start for all this stuff that I'm probably going to (but after > discussion this time!) I've opened this CL: > https://codereview.chromium.org/15993014 . > I'll take a look. > Sven, I'd like to try implementing binary search tree, jus

Re: [v8-dev] Re: Reorder switch clauses using newly-introduced execution counters in (issue 16128004)

On Wed, Jun 5, 2013 at 8:47 AM, Sven Panne wrote: > On Tue, Jun 4, 2013 at 6:02 PM, Fedor Indutny wrote: > >> As a start for all this stuff that I'm probably going to (but after >> discussion this time!) I've opened this CL: >> https://codereview.chromium.org/

[v8-dev] Re: Notify CPU profiler when calling native getters (issue 16286016)

On Thu, Jun 6, 2013 at 11:30 AM, wrote: > Then is this not a more fundamental problem with how PropertyCallbackInfo > and > AccessorInfo are declared. Wouldn't adding internal versions of them be > more > consistent with the way other types are declared? > > https://codereview.chromium.**org/1628

[v8-dev] Re: Notify CPU profiler when calling native getters (issue 16286016)

I don't have a good solution, but always paying a penalty for a very, very rare case (profiler is on) seems to be the wrong approach. We desperately try to make transitioning between JS and C as cheap as possible, so several writes plus an additional frame/jump/return per transition is heading into

Re: [v8-dev] Re: Test expectations file with additional expectations for blink tests (issue 16634005)

On Fri, Jun 7, 2013 at 3:41 PM, wrote: > [...] Ideally, we'd understand why these tests are failing and how we can > make them > pass (given that they apparently pass on upstream Blink bots), but I'm not > sure > that's worth the time investment. > Most of them look like a problem with a missing

Re: [v8-dev] Re: Issue 2730 in v8: The default setting of type_info_threshold is too low

On Mon, Jun 17, 2013 at 9:12 PM, wrote: > > Comment #6 on issue 2730 by vego...@chromium.org: The default setting of > type_info_threshold is too low > http://code.google.com/p/v8/**issues/detail?id=2730 > > One thing to notice is that asm.js-sty

Re: [v8-dev] Re: Support higher CPU profiler sampling rate on posix systems (issue 21101002)

On Tue, Jul 30, 2013 at 2:33 PM, wrote: > [...] Our assumption is that with a high sampling rate we can afford > allocating one > CPU core to the profile event processor and the sampling rate would be > limited > by the performance of that thread. So we intentionally want to have the > core be >

Re: [v8-dev] [v8] r12756 committed - Kill off the SCons based build....

FYI: This changes has killed the collection of v8 statistics on http://arewefastyet.com/... On Thu, Oct 18, 2012 at 3:08 PM, wrote: > Revision: 12756 > Author: jkumme...@chromium.org > Date: Thu Oct 18 06:07:41 2012 > Log: Kill off the SCons based build. > > Review URL: > https://cod

Re: [v8-dev] Re: Always invoke the default Array.sort functions from builtin functions. (issue 10559005)

Read more about this and other fun stuff in B.E.'s upcoming bestseller: "Mutable Prototypes: Your Road to Madness" :-) On Fri, Oct 19, 2012 at 2:22 PM, wrote: > On 2012/10/19 12:11:50, Vyacheslav Egorov (Google) wrote: > >> DBC :-) >> > > > https://chromiumcodereview.**appspot.com/10559005/dif

Re: [v8-dev] Re: build: make python executable configurable (issue 11418101)

Probably something like update-alternatives is the cleaner way than doing any symlinking by hand, but the question is: Does the platform in question have something like that? Anyway I think that providing the ability to specify all build tools explicitly if needed without any platform tweaks or PAT

Re: [v8-dev] Re: build: make python executable configurable (issue 11418101)

being flexible is a worthwhile goal IMHO, especially if it's only such a comparatively trivial change, which doesn't really introduce any real complexity. On Wed, Nov 21, 2012 at 1:17 PM, Jakob Kummerow wrote: > > On Wed, Nov 21, 2012 at 11:15 AM, Sven Panne wrote: > >> Pro

Re: [v8-dev] [v8] r13025 committed - Use the property load IC for accessing the array length....

This commit has tanked Octane's crypto benchmark, so this needs investigation: http://70.32.156.88:8080/Benchmark?benchmark=Crypto-octane#targets%3Dv8%3BmachineTypes%3Dlinux-x64%2Clinux-ia32%2Clinux-armv7%2Candroid-armv7%3Bcpus%3DIntel%20Core%202%2CARMv7%20Mako%2CARMv7%20Nakasi%2CARMv7%2CARMv7%20Pr

[v8-dev] Re: Always inline GetAlignedPointerFromInternalField (issue 11434021)

On Thu, Nov 29, 2012 at 7:41 PM, wrote: > In fact, I verified that *all* functions marked "inline" are > > actually inlined. >> > > All the functions in the V8 header, or all function in the entire product? > [...] > I checked that there are no undefined references for all functions marked as "I

[v8-dev] Re: Always inline GetAlignedPointerFromInternalField (issue 11434021)

sed s/Huhu/Huh/ ;-) -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev

Re: [v8-dev] Re: Revert r13218 due to windows test failures. (issue 11568014)

One small request: I would very much prefer a description like Revert 'Improved blablah by doing foobar' (r12345) because of hurz instead of simply Revert r12345 because of hurz It takes you at least 3 clicks (if you are lucky and in a browser) or some git trickery to find out what the or

[v8-dev] Re: Add methods to allow resuming execution after calling TerminateExecution(). (issue 11142013)

On Thu, Dec 13, 2012 at 10:57 PM, Andrew Paprocki wrote: > Is there any way I can see the log of the failure? I'll boot up a vm and > see if I can track it down in the meantime. Looking at out build bots, firing up a VM is not even necessary, v8's own test suite fails in debug mode on Linux with

Re: [v8-dev] Re: Issue 2478 in v8: Compiling with clang fails with a warning about an unused private field

On Thu, Jan 10, 2013 at 6:55 PM, wrote: > > Comment #2 on issue 2478 by bordju...@gmail.com: Compiling with clang > fails with a warning about an unused private field > http://code.google.com/p/v8/**issues/detail?id=2478 > > Adding USE(ok_); avoi

[v8-dev] Re: Don't use TLS for space iterators. (issue 12217106)

On Mon, Feb 11, 2013 at 2:07 PM, wrote: > DBC > > What happens if I try to iterate spaces while the isolate is being > destroyed? > > (e.g. from another thread without holding an Isolate lock?) > Probably chaos, but this would be the same chaos as before. :) I think the whole notion of Islolate

Re: [v8-dev] Remove boilerplate code from HydrogenCodeStubs (issue 12704010)

On Tue, Mar 19, 2013 at 6:58 PM, wrote: > Reviewers: danno, > > Message: > Scrap your boilerplate! :) > https://memegen.googleplex.com/17080802 -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to

Re: [v8-dev] Re: Remove SCons related files (issue 14348002)

On Thu, Apr 18, 2013 at 1:41 PM, wrote: > It only took two years to get from the decision to kill off the SCons > build to > this CL. Of these two years, only about one and a half year has been invested to persuade *me* to use GYP... :-D -- -- v8-dev mailing list v8-dev@googlegroups.com http

[v8-dev] Re: Various improvements regarding the way we print code code comments. (issue 14371005)

Tiny update for the Emacs aficionadosamong us: The snippet below highlights the v8 code output nicely, at least if you don't hate the default colors... ;-) ;; (defva

Re: [v8-dev] very basic question.

Just like a C++ local variable, a Local dies when the HandleScope in which it was created dies. So probably the answer to your question is "no", but that is hard to say without further details. You probably want Persistent handles. -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.

[v8-dev] Re: Don't double unlink in DCE. (issue 14914004)

Just as a reminder: I think this should be merged back after some canary coverage, the only problem is that I lost track to what branch exactly... :-} trunk (and therefore the upcoming 3.18 branch) definitely, but do we still merge back to 3.17? On Fri, May 3, 2013 at 3:39 PM, wrote: > Committe

Re: [v8-dev] Do not change environment between simulate and scope with no observable side-effects in HandlePrope… (issue 14793009)

On Tue, May 7, 2013 at 6:02 PM, wrote: > [...] Do not change environment between simulate and scope with no > observable > side-effects in HandlePropertyAssignment. > A minor request, not only for this CL, but for all CLs (so nothing personal here, Ulan ;-): Please describe *why* we do the chang

Re: [v8-dev] V8 stack shape documentation

Nice summary, just one additional remark: One optimized JavaScript frame can actually correspond to several frames in unoptimized code due to inlining, the deoptimizer takes care of the mapping when needed. -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev -

Re: [v8-dev] Re: Rollback of r14587 in trunk branch. (issue 14680011)

Even if I run into the danger of repeating myself: ;-) It would be nice if the reason for the rollback is included in the description, this would really help understanding the history later... -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You receiv