Re: [webkit-dev] Hash tables and unique string identifiers in JavaScriptCore
> Thanks! So is PropertyMapHashTable for properties that have been defined by > the user, or is it not that simple? Yes. > Apologies. Basically, does the implementation of object property access in > the JIT codebase also use strings which have been made unique identifiers in > the same way as in the runtime stack? (i.e. can they be assumed equal iff > they have the same address). Yes -- typically, though, if the JIT needs to do a hash lookup, it will pass an Identifier to a C++ helper function. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Hash tables and unique string identifiers in JavaScriptCore
On Wed, Sep 19, 2012 at 1:12 AM, Geoffrey Garen wrote: > Hi Stephen. > > > 1. I notice there are at least two implementations of hash tables in > JavaScriptCore/runtime, in Lookup.h and PropertyMapHashTable.h. Which, if > either, is used in, say, the normal case of accessing the properties of a > DOM element, like "window.location", etc.? And assuming it's one or the > other, what's the main use case of the other one? > > window.location uses Lookup.h. Lookup.h contains hash table logic for > static properties compiled into the binary. > Thanks! So is PropertyMapHashTable for properties that have been defined by the user, or is it not that simple? > > > 2. Also, it looks like string keys in Lookup.h are always "Identifier"s, > meaning (I think) that they are guaranteed to be single unique entries in > the "identifierTable" of a JSGlobalData object. Because of this > preprocessing, string equality in the hash table implementation can be > tested just by comparing addresses. Is there any reason why > PropertyMapHashTable.h does not (as far as I can tell) do the same thing? > > It does. > > inline PropertyTable::find_iterator PropertyTable::find(const KeyType& key) > { > ASSERT(key); > ASSERT(key->isIdentifier() || key->isEmptyUnique()); > unsigned hash = key->existingHash(); > My mistake: the second assert seems to not be there in QtWebKit-2.2.0, the version I'm looking through, but I reading further I realized that keys are also assumed to be unique identifiers with the comparison below. if (key == table()[entryIndex - 1].key) return std::make_pair(&table()[entryIndex - 1], hash & m_indexMask); (The way the types resolve, the key comparison is done on address rather than value, as I assumed the first time I read it) > > 3. Does the JIT side of the codebase use unique string identifiers like > Lookup.h does, or is that a whole different ballgame? > > Can you be more specific? > Apologies. Basically, does the implementation of object property access in the JIT codebase also use strings which have been made unique identifiers in the same way as in the runtime stack? (i.e. can they be assumed equal iff they have the same address). I can't seem to find any code that does it, but I am new to the whole tree. > Geoff > Thanks! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Hash tables and unique string identifiers in JavaScriptCore
Hi Stephen. > 1. I notice there are at least two implementations of hash tables in > JavaScriptCore/runtime, in Lookup.h and PropertyMapHashTable.h. Which, if > either, is used in, say, the normal case of accessing the properties of a DOM > element, like "window.location", etc.? And assuming it's one or the other, > what's the main use case of the other one? window.location uses Lookup.h. Lookup.h contains hash table logic for static properties compiled into the binary. > 2. Also, it looks like string keys in Lookup.h are always "Identifier"s, > meaning (I think) that they are guaranteed to be single unique entries in the > "identifierTable" of a JSGlobalData object. Because of this preprocessing, > string equality in the hash table implementation can be tested just by > comparing addresses. Is there any reason why PropertyMapHashTable.h does not > (as far as I can tell) do the same thing? It does. inline PropertyTable::find_iterator PropertyTable::find(const KeyType& key) { ASSERT(key); ASSERT(key->isIdentifier() || key->isEmptyUnique()); unsigned hash = key->existingHash(); > 3. Does the JIT side of the codebase use unique string identifiers like > Lookup.h does, or is that a whole different ballgame? Can you be more specific? Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Hash tables and unique string identifiers in JavaScriptCore
Hi, I just started working with webkit (specificially JSC) and am trying to learn the codebase. I hope someone can bear with me enough to help me with some questions: 1. I notice there are at least two implementations of hash tables in JavaScriptCore/runtime, in Lookup.h and PropertyMapHashTable.h. Which, if either, is used in, say, the normal case of accessing the properties of a DOM element, like "window.location", etc.? And assuming it's one or the other, what's the main use case of the other one? 2. Also, it looks like string keys in Lookup.h are always "Identifier"s, meaning (I think) that they are guaranteed to be single unique entries in the "identifierTable" of a JSGlobalData object. Because of this preprocessing, string equality in the hash table implementation can be tested just by comparing addresses. Is there any reason why PropertyMapHashTable.h does not (as far as I can tell) do the same thing? 3. Does the JIT side of the codebase use unique string identifiers like Lookup.h does, or is that a whole different ballgame? Thanks very much in advance for help! Stephen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Enable encoding detector on layout(regression) test
Hi, I am working on a bad case that encoding detector doesn't recognize it. So I created a bug, https://bugs.webkit.org/show_bug.cgi?id=97054, then try to make a layout(regression) test case. However, enabling encoding detector by javaScript manipulation seems not feasible since encoding detector works on reading input stream level. Therefore, I am asking here if any of WebKittens would give some advices/opinions including good precedent to resolve this case. - Kangil Han ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] platform-specific differences in test case inputs
Sorry I totally left out the "I expose this through Internals" - and adam has explained the rationale On Tue, Sep 18, 2012 at 12:46 PM, Oliver Hunt wrote: > What exactly are you trying to test here? The internal serialisation > format isn't exposed anywhere (nor should it be). > > By definition newer formats won't be backwards compatible, or are you > trying to ensure that newer deserialisers will be able to continue to > deserialise old content? > exactly. Where does JSC test this? I'm happy to follow whatever pattern is already established. Alec ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] platform-specific differences in test case inputs
Where do you test that property? Adam On Tue, Sep 18, 2012 at 12:43 PM, Oliver Hunt wrote: > JSC's SerializedScriptValue has always been versioned (having learned the > horror of no versioning with localStorage :( ) > > Newer formats (obviously) can't be read by older clients, but the > serialisation is intentionally forwards compatible. > > --Oliver > > On Sep 18, 2012, at 12:36 PM, Adam Barth wrote: > >> This is an interesting case because it's important for the >> serialization format to be consistent across time (so that an >> IndexedDB created at one point in time can work at another point in >> time), but it's not important to be consistent across embedders >> (because IndexedDB created by Safari don't need to be readable by >> Chrome and vice versa). >> >> Perhaps we shouldn't use LayoutTests to test this functionality. >> Instead, it might make more sense to use API-level tests that check >> that a particular embedder API is stable and working as expected. >> >> Adam >> >> >> On Tue, Sep 18, 2012 at 12:19 PM, Alec Flett wrote: >>> Background: some of the storage systems use SerializedScriptValue to persist >>> structured-clonable objects >>> (http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data) >>> - most of this is implemented in a V8 or JSC-specific implementation of >>> SerializedScriptValue. >>> >>> I'm adding tests for the actual values stored with SerializedScriptValue so >>> that we can move forward with serialization changes without breaking >>> backwards compatibility. >>> >>> So many of my js tests boil down to: >>> >>> testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x]); >>> >>> Which makes sure that these two representations are equivalent by going in >>> both directions. >>> >>> The issue I'm hitting is that JSC has a different implementation with a >>> different storage format, and the serialization/deserialization between the >>> two storage formats is not compatible - the above code works great on V8 but >>> JSC uses different bytes. >>> >>> I can't address this with just expectations files (i.e. only check that {} >>> serializes to some byte array, and have different expectations depending on >>> the port) because I need to check that specific inputs (such as old V8-based >>> formats) can also deserialize back into the right native objects. >>> >>> What I kind of want is something like: >>> >>> #ifdef JSC >>> >>> #endif >>> >>> #ifdef V8 >>> >>> #endif >>> >>> Thoughts? >>> >>> ___ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo/webkit-dev >>> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] platform-specific differences in test case inputs
What exactly are you trying to test here? The internal serialisation format isn't exposed anywhere (nor should it be). By definition newer formats won't be backwards compatible, or are you trying to ensure that newer deserialisers will be able to continue to deserialise old content? --Oliver On Sep 18, 2012, at 12:19 PM, Alec Flett wrote: > Background: some of the storage systems use SerializedScriptValue to persist > structured-clonable objects > (http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data) > - most of this is implemented in a V8 or JSC-specific implementation of > SerializedScriptValue. > > I'm adding tests for the actual values stored with SerializedScriptValue so > that we can move forward with serialization changes without breaking > backwards compatibility. > > So many of my js tests boil down to: > > testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x]); > > Which makes sure that these two representations are equivalent by going in > both directions. > > The issue I'm hitting is that JSC has a different implementation with a > different storage format, and the serialization/deserialization between the > two storage formats is not compatible - the above code works great on V8 but > JSC uses different bytes. > > I can't address this with just expectations files (i.e. only check that {} > serializes to some byte array, and have different expectations depending on > the port) because I need to check that specific inputs (such as old V8-based > formats) can also deserialize back into the right native objects. > > What I kind of want is something like: > > #ifdef JSC > > #endif > > #ifdef V8 > > #endif > > Thoughts? > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] platform-specific differences in test case inputs
JSC's SerializedScriptValue has always been versioned (having learned the horror of no versioning with localStorage :( ) Newer formats (obviously) can't be read by older clients, but the serialisation is intentionally forwards compatible. --Oliver On Sep 18, 2012, at 12:36 PM, Adam Barth wrote: > This is an interesting case because it's important for the > serialization format to be consistent across time (so that an > IndexedDB created at one point in time can work at another point in > time), but it's not important to be consistent across embedders > (because IndexedDB created by Safari don't need to be readable by > Chrome and vice versa). > > Perhaps we shouldn't use LayoutTests to test this functionality. > Instead, it might make more sense to use API-level tests that check > that a particular embedder API is stable and working as expected. > > Adam > > > On Tue, Sep 18, 2012 at 12:19 PM, Alec Flett wrote: >> Background: some of the storage systems use SerializedScriptValue to persist >> structured-clonable objects >> (http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data) >> - most of this is implemented in a V8 or JSC-specific implementation of >> SerializedScriptValue. >> >> I'm adding tests for the actual values stored with SerializedScriptValue so >> that we can move forward with serialization changes without breaking >> backwards compatibility. >> >> So many of my js tests boil down to: >> >> testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x]); >> >> Which makes sure that these two representations are equivalent by going in >> both directions. >> >> The issue I'm hitting is that JSC has a different implementation with a >> different storage format, and the serialization/deserialization between the >> two storage formats is not compatible - the above code works great on V8 but >> JSC uses different bytes. >> >> I can't address this with just expectations files (i.e. only check that {} >> serializes to some byte array, and have different expectations depending on >> the port) because I need to check that specific inputs (such as old V8-based >> formats) can also deserialize back into the right native objects. >> >> What I kind of want is something like: >> >> #ifdef JSC >> >> #endif >> >> #ifdef V8 >> >> #endif >> >> Thoughts? >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo/webkit-dev >> > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] platform-specific differences in test case inputs
This is an interesting case because it's important for the serialization format to be consistent across time (so that an IndexedDB created at one point in time can work at another point in time), but it's not important to be consistent across embedders (because IndexedDB created by Safari don't need to be readable by Chrome and vice versa). Perhaps we shouldn't use LayoutTests to test this functionality. Instead, it might make more sense to use API-level tests that check that a particular embedder API is stable and working as expected. Adam On Tue, Sep 18, 2012 at 12:19 PM, Alec Flett wrote: > Background: some of the storage systems use SerializedScriptValue to persist > structured-clonable objects > (http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data) > - most of this is implemented in a V8 or JSC-specific implementation of > SerializedScriptValue. > > I'm adding tests for the actual values stored with SerializedScriptValue so > that we can move forward with serialization changes without breaking > backwards compatibility. > > So many of my js tests boil down to: > > testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x]); > > Which makes sure that these two representations are equivalent by going in > both directions. > > The issue I'm hitting is that JSC has a different implementation with a > different storage format, and the serialization/deserialization between the > two storage formats is not compatible - the above code works great on V8 but > JSC uses different bytes. > > I can't address this with just expectations files (i.e. only check that {} > serializes to some byte array, and have different expectations depending on > the port) because I need to check that specific inputs (such as old V8-based > formats) can also deserialize back into the right native objects. > > What I kind of want is something like: > > #ifdef JSC > > #endif > > #ifdef V8 > > #endif > > Thoughts? > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] platform-specific differences in test case inputs
Background: some of the storage systems use SerializedScriptValue to persist structured-clonable objects ( http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data) - most of this is implemented in a V8 or JSC-specific implementation of SerializedScriptValue. I'm adding tests for the actual values stored with SerializedScriptValue so that we can move forward with serialization changes without breaking backwards compatibility. So many of my js tests boil down to: testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x]); Which makes sure that these two representations are equivalent by going in both directions. The issue I'm hitting is that JSC has a different implementation with a different storage format, and the serialization/deserialization between the two storage formats is not compatible - the above code works great on V8 but JSC uses different bytes. I can't address this with just expectations files (i.e. only check that {} serializes to some byte array, and have different expectations depending on the port) because I need to check that specific inputs (such as old V8-based formats) can also deserialize back into the right native objects. What I kind of want is something like: #ifdef JSC #endif #ifdef V8 #endif Thoughts? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Pre-proposal: Adding a Coverity instance for WebKIt
My preference would simply be to improve the Clang static analyser - it's free, open source, etc. I periodically run that analyzer on JSC, but apparently their ToT code has many improvements over stable. --Oliver On Sep 17, 2012, at 9:20 PM, Brent Fulgham wrote: > Hi Gang, > > On Sep 17, 2012, at 4:11 PM, James Hawkins wrote: > >> TL;DR - If you have opinions one way or another about having a Coverity >> instance available for WebKit developers, please respond to this message. > > I have used Coverity at on a couple of occasions, without modifying source > code to help the static analyzer. While its rather high cost has prevented me > from using it recently, I did think that it provided enough signal-to-noise > that I really wish I still had it. > > I think one of its main advantages is the ability to have it run over the > entire source tree periodically to do larger-scale analysis than we can do > looking at individual changesets. > > Many of the bugs it found were of the 'uninitialized variable' type, but I > did find that it could dredge up some very clever edge cases that were > definitely worth fixing. > > Since the cost to the project is effectively zero, I think we would be very > foolish not to take advantage of this very generous offer. > > Thanks, > > -Brent > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Anyone willing to update webkit.org?
On Sep 18, 2012, at 7:04 PM, Eric Seidel wrote: > I was noticing today that http://www.webkit.org/ is quite old and out > of date. What xenon built 6 years ago, has stood up remarkably well, > but it may be time for a refresh. > (It also has no high-dpi support.) > > I'm aware that I have the ability to change it. But I'm also inviting > others to do so: > http://trac.webkit.org/browser/trunk/Websites/webkit.org > > In particular: > - It mentions nothing of Safari on iOS or Chrome (which must be some > huge fraction of our userbase by now) > - Could link to numerous other sites showing information about WebKit > (cia, ohloh, svnsearch) > - Projects like "SVG" really aren't the current focus. :) They are not? Maybe not for you :) Dirk > > I'm sure this list is full of individuals with infinitely more visual > design sense than I. So I invite your patches, my reviewing and > committing fingers stand ready. :) > > -eric > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Anyone willing to update webkit.org?
I was noticing today that http://www.webkit.org/ is quite old and out of date. What xenon built 6 years ago, has stood up remarkably well, but it may be time for a refresh. (It also has no high-dpi support.) I'm aware that I have the ability to change it. But I'm also inviting others to do so: http://trac.webkit.org/browser/trunk/Websites/webkit.org In particular: - It mentions nothing of Safari on iOS or Chrome (which must be some huge fraction of our userbase by now) - Could link to numerous other sites showing information about WebKit (cia, ohloh, svnsearch) - Projects like "SVG" really aren't the current focus. :) I'm sure this list is full of individuals with infinitely more visual design sense than I. So I invite your patches, my reviewing and committing fingers stand ready. :) -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] wiki spammers
The spam filter plugin had not been installed on the new hardware, but I just installed it, so the spamming should be better now. You can add new addresses or patterns to the BadContent wiki page for any new spam. Previously I had kept all of the Mac OS Forge BadContent lists in sync, but with the new hardware the project can manage its own BadContent page now. https://trac.webkit.org/wiki/BadContent -Bill On Sep 18, 2012, at 4:52 AM, Andras Becsi wrote: > Hi, > > On 18 September 2012 13:47, Osztrogonac Csaba wrote: >> Hi, >> >> Can't we add a captcha to the registration >> form of the trac to block SPAM bots? > > Would be good because spamming seems to escalate lately. > Some more addresses that regularly submitted spam links in recent months: > > sussane_...@hotmail.com > toybaby...@gmail.com > janeparker...@gmail.com > ra...@mailinator.com > dasta...@o2.pl > doris.gr...@gmail.com > w...@marrant.org > dietas...@hotmail.com > cont...@freemobileactu.com > uuo...@gmail.com > > > /Andras > > >> >> br, >> Ossy >> >> Andras Becsi írta: >> >>> Hi, >>> >>> Could someone who has the needed credentials ban >>> >>> willetta...@yahoo.com >>> carstrow...@yahoo.com >>> tonygua...@gmail.com >>> mtjohnwo...@gmail.com >>> lindahom...@gmail.com >>> >>> from trac because the wiki receives regular spam updates from these >>> addresses. >>> >>> /Andras >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo/webkit-dev > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] wiki spammers
Hi, On 18 September 2012 13:47, Osztrogonac Csaba wrote: > Hi, > > Can't we add a captcha to the registration > form of the trac to block SPAM bots? Would be good because spamming seems to escalate lately. Some more addresses that regularly submitted spam links in recent months: sussane_...@hotmail.com toybaby...@gmail.com janeparker...@gmail.com ra...@mailinator.com dasta...@o2.pl doris.gr...@gmail.com w...@marrant.org dietas...@hotmail.com cont...@freemobileactu.com uuo...@gmail.com /Andras > > br, > Ossy > > Andras Becsi írta: > >> Hi, >> >> Could someone who has the needed credentials ban >> >> willetta...@yahoo.com >> carstrow...@yahoo.com >> tonygua...@gmail.com >> mtjohnwo...@gmail.com >> lindahom...@gmail.com >> >> from trac because the wiki receives regular spam updates from these >> addresses. >> >> /Andras > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] wiki spammers
Hi, Can't we add a captcha to the registration form of the trac to block SPAM bots? br, Ossy Andras Becsi írta: Hi, Could someone who has the needed credentials ban willetta...@yahoo.com carstrow...@yahoo.com tonygua...@gmail.com mtjohnwo...@gmail.com lindahom...@gmail.com from trac because the wiki receives regular spam updates from these addresses. /Andras ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] wiki spammers
Hi, Could someone who has the needed credentials ban willetta...@yahoo.com carstrow...@yahoo.com tonygua...@gmail.com mtjohnwo...@gmail.com lindahom...@gmail.com from trac because the wiki receives regular spam updates from these addresses. /Andras ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev