Re: Integrating ICU into Mozilla build
Robert O'Callahan a écrit : Often, the OS support for a particular language is really terrible and we can and should do better even if it means being inconsistent with the OS. This is certainly true for the case of font shaping, for example. I've seen the references to font shaping in the start of the discussion, but didn't follow what's happening on that front. Very probably should. Which OS are that weak on this point ? Initially Arabic shaping under Windows was very weak in Firefox until the rewrite that made it properly use Uniscribe. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: Not shipping prefixed APIs on the release channel
On 11/12/12 06:40, Henri Sivonen wrote: > On Sat, Dec 8, 2012 at 5:24 PM, Randell Jesup wrote: >> tl;dr - prefixing is bad. It's not good even before Release. API >> version suffixing may be better. > > Are you OK with the latest policy proposal I made or do you intend to > make a counter-proposal with suffixing? > > Latest for reference: > 1) Excluding WebGL and WebRTC APIs, new APIs that are shipped on the > release channel shall be shipped without a prefix. > 2) If APIs that don’t already have specs are shipped, we’ll get specs > written. Name mangling is a poor solution. Perhaps we could come up with an API for exposing experimental features? enableExperimentalFeature(feature, version) Anthony ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: sr flag question
On 12/12/12 19:06, Justin Lebar wrote: Recently I read Dave Townsend's thread about "Super-review, what shall we do with you?" and realized there wasn't any conclusion to that. As a relative new dev, I think it is vital to have a clear distinction as to when a sr is required. I think the conclusion to draw from that thread is that there is no One True Policy about when SR is required. We tried to make one in that thread, but it was hard to reach consensus, as you observed. Reviewers should point out when a patch needs sr. Or you can flag patches which you think might contain API changes for sr?someone and then let the reviewer or superreviewer clear the request. Yeah this is right. Reviewers should be the ones saying if they think a patch requires SR. They have the experience to understand that decision which is difficult to put hard criteria against. The words in the SR policy page can give you a general idea but circumstances differ. If you are concerned about whether something will need SR then the things to do is reach out to a potential reviewer and ask them. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
C++11 atomics in Mozilla
As you may or may not be aware, one of the goodies that comes in C++11 is the introduction of an explicit memory model as well as proper support for multithreaded code. One important piece of this is std::atomic, which provides an interoperable way to do (potentially lockless) atomic operations and, under the new memory model, is the only safe way to handle multithreaded accesses when not protected by locks (if you use volatile to do this right now, your code is broken and you don't know it yet). In bug 732043, I want to add a mozilla::Atomic class that lets us use C++11 atomics where available and fallback to compiler intrinsics where C++11 atomics are not implemented (which amounts to gcc 4.4 and Visual Studio 2010 or earlier). What would this give us? 1. Atomic operations on non-32-bit types. Well, not all platforms support all atomic read-modify-write operations on all word sizes (ARM doesn't have 64-bit atomic primitives; Windows only provides a subset of operations on 8-bit/16-bit words), but we'd have more coverage than just atomic increment/decrement/store on 32-bit words. 2. Compare-and-swap, particularly on pointer variables. An atomic compare-and-swap primitive is probably the most important in terms of practically implementing high-throughput lock-free concurrent data structures. 3. Weaker memory ordering. Current compiler intrinsics--as used in PR_ATOMIC_INCREMENT and friends--require full memory barriers around every access. For things like reference counters, we can get away with not needing memory barriers if the architecture (e.g., ARM) supports it. Note that this does require as a prerequisite compilers that speak newer atomic intrinsics (Clang 3.1, MSVC 2012, and gcc 4.6 are the min versions here). The problems are the following: 1. Not all architectures support all lock-free atomic operations on all sizes of integers; in particular, ARM cannot do atomic operations on 64-bit variables. A compiler that supports C++11 atomics would fallback to locking-based algorithms here, but as I want to put this in MFBT, I don't have usable lock dependencies. And I'm not keen on hand-writing locking algorithms based on primitives either. :-) My proposed solution to this dilemma is to forbid use of mozilla::Atomic if sizeof(T) > sizeof(uintptr_t) [rationale being that all architectures should be able to support at least lock-free atomic operations on pointers]. 2. The API I'm proposing in this instance would not allow you to use an atomic operation on a "regular" variable, which is a big difference from the current APIs provided by pratom.h. The rationale here is that this is much less prone to danger (all accesses to a variable are atomic), as well as simplifying APIs. The biggest user of PR_ATOMIC_INCREMENT right now is for threadsafe XPCOM refcounting; to move to the new API, we would have to restructure the nsISupports helper macros by providing an NS_DECL_ISUPPORTS_THREADSAFE macro, although we would be able to lose all the NS_IMPL_THREADSAFE_* variants. 3. Similar to #2, the ideal version of a reference counter would be mozilla::Atomic (which would make threadsafe refcounting cheaper on our ARM platforms if we compiled with gcc 4.6 or clang 3.1 or newer). However, I'm not sure that no one has written code that relies on atomic operations having memory ordering properties, and I don't want to go through and audit every thread-safe XPCOM class. 4. Also, in a similar problem to the above, what should the default consistence be for mozilla::Atomic? C++11 opts to default to sequentially-consistent, but right now, most of our uses of atomic macros are for counter variables, which tend to want to be unordered. 5. A last technical point: there is one case in which a C++11 atomics class can have a non-atomic access to a variable. The value-initialization constructor of std::atomic does not store the value atomically. This may seem crazy, but I believe that the primary purpose is to be able to declare static-storage variables with initial values and not require adding a global initializer. Since I think this is a useful feature, I've been considering copying these semantics over, although I do admit that it does appear arbitrary and incongruous. What are your opinions? Or other thoughts/questions/flames/comments/concerns? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++11 atomics in Mozilla
On Fri, Dec 14, 2012 at 12:33 PM, Joshua Cranmer wrote: > 3. Similar to #2, the ideal version of a reference counter would be > mozilla::Atomic (which would make threadsafe > refcounting cheaper on our ARM platforms if we compiled with gcc 4.6 or > clang 3.1 or newer). However, I'm not sure that no one has written code > that relies on atomic operations having memory ordering properties, and I > don't want to go through and audit every thread-safe XPCOM class. > Is code like this safe in the C++1 Unordered model? Thread 1: int x = obj->v; obj->Release(); Thread 2: obj->Release(); where obj's destructor trashes obj->v. The potential hazard is if thread 1's obj->Release() atomic decrement is reordered to run before the obj->v load has completed, then Thread 2's obj->Release() runs and trashes obj->v, and thread 1 reads the trashed value. For what it's worth, I think asking programmers to even think about such question is insane, so I'd go for full memory barriers and sequential consistency until we have benchmark numbers showing big wins from other choices. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Synchronous loading of data: URLs
Henri Sivonen wrote: > > Fonts are loaded when used so font loading won't start until the > > contents using a particular font are laid out. > > That seems like a problem for JS-driven display. A big problem in > the canvas case and at least an annoyance when a JS program drives > the input to CSS layout. > > > This optimization simply eliminates the extra reflow required by > > spinning the event loop. > > That makes sense. However, it’s still not nice for data: to be magic > for the JS-driven case. For JS-driven cases, I think the platform > really needs an async API that lets a JS program say “start loading > this font now” and then some callback for getting notified > asynchronously (regardless of URL scheme) when the font has been > loaded so that it is ready for use with canvas or ready for use with > CSS without a flash of unfontified content. These are precisely the problems that the loadFonts method of the FontLoader object are meant to address: http://dev.w3.org/csswg/css3-fonts/#fontloader-loadfont As Jonathan mentioned, the exact details of this API are still under discussion but I think the basic set of features is there. John ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++11 atomics in Mozilla
> Is code like this safe in the C++1 Unordered model? > Thread 1: > int x = obj->v; > obj->Release(); > Thread 2: > obj->Release(); > where obj's destructor trashes obj->v. > The potential hazard is if thread 1's obj->Release() atomic decrement is > reordered to run before the obj->v load has completed, then Thread 2's > obj->Release() runs and trashes obj->v, and thread 1 reads the trashed > value. Indeed, but note that you don't need a full barrier on release; a barrier which prevents instructions from being moved down below the release is sufficient. (The general rule is that you can move an instruction into a critical section, but not out of one.) > For what it's worth, I think asking programmers to even think about such > question is insane, so I'd go for full memory barriers and sequential > consistency until we have benchmark numbers showing big wins from other > choices. I totally agree, but I think it /might/ be sane to make addref unordered and release a partial barrier as described above. FWIW, I once tried changing all of our atomic string refcounting to non-atomic operations and could not eke out a performance (or stability) difference on x64. This was despite the fact that I was able to generate profiles where the atomic string refcounting showed up as taking a few percentage points. I think bz reproduced this somewhat surprising result more recently. Of course that says nothing about ARM, or about our other atomic addrefs. And really, I still don't entirely believe the correctness of my result in those tests. -Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++11 atomics in Mozilla
On 12/14/12 1:48 AM, Justin Lebar wrote: FWIW, I once tried changing all of our atomic string refcounting to non-atomic operations and could not eke out a performance (or stability) difference on x64. This was despite the fact that I was able to generate profiles where the atomic string refcounting showed up as taking a few percentage points. I think bz reproduced this somewhat surprising result more recently. What I found was that changing the refcounting on nsStringBuffer to not be atomic didn't obviously help. Neither did inlining those addref/release calls (they're out-of-line right now). But doing both together _did_ help a good bit, for my microbenchmark. Also x64 for that test. And _very_ microbenchmarky... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
