[webkit-dev] The WebKit tree is OPEN!

[Gavin Barraclough]

Hi folks,

We’re back in action! – we should have enough of our infrastructure up to keep 
the build green & guard against regressions, so the repository is open again to 
commits.

We’d really like to minimize broken builds over the next day as any backlog of 
patches is being landed. We can all do our part to help with this. It would be 
greatly appreciated if everyone could update their patches to ToT and give them 
a fresh run through EWS before committing, to make make sure they’re still 
passing EWS.

Thanks all for your understanding & apologies again for the inconvenience,
Gavin



> On Nov 8, 2016, at 8:07 PM, Ryosuke Niwa  wrote:
> 
> Hi all,
> 
> We're in the final process of verifying that our infrastructure is up & 
> running again.  I've landed two patches manually to go through our buildbot 
> pipeline to make sure everything is working again.
> 
> We're sorry for the inconvenience and we appreciate your cooperation & 
> patience.
> 
> - R. Niwa
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

[Gavin Barraclough]

> On Nov 1, 2015, at 7:40 PM, Darin Adler  wrote:
> 
> 3) Can you help me come up with a super-efficient algorithm to do this 
> serialization?

Table lookup? FP conversion code is hard, and this is a relatively small number 
of strings.

You could also flatten all the strings into one big string, and take out a 
pointer indirection (below).

Data would add 1.5k to binary size, which is probably competitive to 
instruction space for an optimized implementation.

cheers,
G.


const char* unsignedCharToFloatString(unsigned char x)
{
return unsignedCharToFloatStrings[x];
}

static const char* unsignedCharToFloatStrings[256] = {
"0",
"0.003",
"0.007",
"0.01",
"0.015",
"0.019",
"0.023",
"0.027",
"0.03",
"0.035",
"0.039",
"0.043",
"0.047",
"0.05",
"0.054",
"0.058",
"0.062",
"0.066",
"0.07",
"0.074",
"0.078",
"0.082",
"0.086",
"0.09",
"0.094",
"0.098",
"0.1",
"0.105",
"0.109",
"0.113",
"0.117",
"0.12",
"0.125",
"0.129",
"0.133",
"0.137",
"0.14",
"0.145",
"0.149",
"0.152",
"0.156",
"0.16",
"0.164",
"0.168",
"0.172",
"0.176",
"0.18",
"0.184",
"0.188",
"0.192",
"0.196",
"0.2",
"0.203",
"0.207",
"0.21",
"0.215",
"0.219",
"0.223",
"0.227",
"0.23",
"0.235",
"0.239",
"0.243",
"0.247",
"0.25",
"0.254",
"0.258",
"0.262",
"0.266",
"0.27",
"0.274",
"0.278",
"0.282",
"0.286",
"0.29",
"0.294",
"0.298",
"0.3",
"0.305",
"0.309",
"0.313",
"0.317",
"0.32",
"0.325",
"0.329",
"0.333",
"0.337",
"0.34",
"0.345",
"0.349",
"0.352",
"0.356",
"0.36",
"0.364",
"0.368",
"0.372",
"0.376",
"0.38",
"0.384",
"0.388",
"0.392",
"0.396",
"0.4",
"0.403",
"0.407",
"0.41",
"0.415",
"0.419",
"0.423",
"0.427",
"0.43",
"0.435",
"0.439",
"0.443",
"0.447",
"0.45",
"0.454",
"0.458",
"0.462",
"0.466",
"0.47",
"0.474",
"0.478",
"0.482",
"0.486",
"0.49",
"0.494",
"0.498",
"0.5",
"0.505",
"0.509",
"0.513",
"0.517",
"0.52",
"0.525",
"0.529",
"0.533",
"0.537",
"0.54",
"0.545",
"0.549",
"0.552",
"0.556",
"0.56",
"0.564",
"0.568",
"0.572",
"0.576",
"0.58",
"0.584",
"0.588",
"0.592",
"0.596",
"0.6",
"0.603",
"0.607",
"0.61",
"0.615",
"0.619",
"0.623",
"0.627",
"0.63",
"0.635",
"0.639",
"0.643",
"0.647",
"0.65",
"0.654",
"0.658",
"0.662",
"0.666",
"0.67",
"0.674",
"0.678",
"0.682",
"0.686",
"0.69",
"0.694",
"0.698",
"0.7",
"0.705",
"0.709",
"0.713",
"0.717",
"0.72",
"0.725",
"0.729",
"0.733",
"0.737",
"0.74",
"0.745",
"0.749",
"0.752",
"0.756",
"0.76",
"0.764",
"0.768",
"0.772",
"0.776",
"0.78",
"0.784",
"0.788",
"0.792",
"0.796",
"0.8",
"0.803",
"0.807",
"0.81",
"0.815",
"0.819",
"0.823",
"0.827",
"0.83",
"0.835",
"0.839",
"0.843",
"0.847",
"0.85",
"0.854",
"0.858",
"0.862",
"0.866",
"0.87",
"0.874",
"0.878",
"0.882",
"0.886",
"0.89",
"0.894",
"0.898",
"0.9",
"0.905",
"0.909",
"0.913",
"0.917",
"0.92",
"0.925",
"0.929",
"0.933",
"0.937",
"0.94",
"0.945",
"0.949",
"0.952",
"0.956",
"0.96",
"0.964",
"0.968",
"0.972",
"0.976",
"0.98",
"0.984",
"0.988",
"0.992",
"0.996",
"1",
};

const char* unsignedCharToFloatStringSingleIndirection(unsigned char x)
{
return 

Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

[Gavin Barraclough]

> On Nov 1, 2015, at 7:40 PM, Darin Adler  wrote:
> 
> 3) Can you help me come up with a super-efficient algorithm to do this 
> serialization?

Oh – I guess if you just store the fractions as BCD & unpack you can get the 
table size down to 512 bytes.

If you decide against truncating the values & still want to store 6 digits of 
precision you could do so in a 1K table (and should be faster serialization 
than normal float to ASCII conversion).

cheers,
G.

void unsignedCharToFloatString(unsigned char x, char* out)
{
unsigned short data = unsignedCharToFloatData[x];

if (data > 1) {
*out++ = '0';
*out++ = '.';
for (unsigned i = 0; i < 4; ++i) {
unsigned value = (data >> 12) & 0xf;
if (value != 0xf)
*out++ = '0' + value;
data <<= 4;
}
} else
*out++ = '0' + data;

*out = '\0';
return;
}

static const unsigned short unsignedCharToFloatData[256] = {
0,
0xf003,
0xf007,
0xff01,
0xf015,
0xf019,
0xf023,
0xf027,
0xff03,
0xf035,
0xf039,
0xf043,
0xf047,
0xff05,
0xf054,
0xf058,
0xf062,
0xf066,
0xff07,
0xf074,
0xf078,
0xf082,
0xf086,
0xff09,
0xf094,
0xf098,
0xfff1,
0xf105,
0xf109,
0xf113,
0xf117,
0xff12,
0xf125,
0xf129,
0xf133,
0xf137,
0xff14,
0xf145,
0xf149,
0xf152,
0xf156,
0xff16,
0xf164,
0xf168,
0xf172,
0xf176,
0xff18,
0xf184,
0xf188,
0xf192,
0xf196,
0xfff2,
0xf203,
0xf207,
0xff21,
0xf215,
0xf219,
0xf223,
0xf227,
0xff23,
0xf235,
0xf239,
0xf243,
0xf247,
0xff25,
0xf254,
0xf258,
0xf262,
0xf266,
0xff27,
0xf274,
0xf278,
0xf282,
0xf286,
0xff29,
0xf294,
0xf298,
0xfff3,
0xf305,
0xf309,
0xf313,
0xf317,
0xff32,
0xf325,
0xf329,
0xf333,
0xf337,
0xff34,
0xf345,
0xf349,
0xf352,
0xf356,
0xff36,
0xf364,
0xf368,
0xf372,
0xf376,
0xff38,
0xf384,
0xf388,
0xf392,
0xf396,
0xfff4,
0xf403,
0xf407,
0xff41,
0xf415,
0xf419,
0xf423,
0xf427,
0xff43,
0xf435,
0xf439,
0xf443,
0xf447,
0xff45,
0xf454,
0xf458,
0xf462,
0xf466,
0xff47,
0xf474,
0xf478,
0xf482,
0xf486,
0xff49,
0xf494,
0xf498,
0xfff5,
0xf505,
0xf509,
0xf513,
0xf517,
0xff52,
0xf525,
0xf529,
0xf533,
0xf537,
0xff54,
0xf545,
0xf549,
0xf552,
0xf556,
0xff56,
0xf564,
0xf568,
0xf572,
0xf576,
0xff58,
0xf584,
0xf588,
0xf592,
0xf596,
0xfff6,
0xf603,
0xf607,
0xff61,
0xf615,
0xf619,
0xf623,
0xf627,
0xff63,
0xf635,
0xf639,
0xf643,
0xf647,
0xff65,
0xf654,
0xf658,
0xf662,
0xf666,
0xff67,
0xf674,
0xf678,
0xf682,
0xf686,
0xff69,
0xf694,
0xf698,
0xfff7,
0xf705,
0xf709,
0xf713,
0xf717,
0xff72,
0xf725,
0xf729,
0xf733,
0xf737,
0xff74,
0xf745,
0xf749,
0xf752,
0xf756,
0xff76,
0xf764,
0xf768,
0xf772,
0xf776,
0xff78,
0xf784,
0xf788,
0xf792,
0xf796,
0xfff8,
0xf803,
0xf807,
0xff81,
0xf815,
0xf819,
0xf823,
0xf827,
0xff83,
0xf835,
0xf839,
0xf843,
0xf847,
0xff85,
0xf854,
0xf858,
0xf862,
0xf866,
0xff87,
0xf874,
0xf878,
0xf882,
0xf886,
0xff89,
0xf894,
0xf898,
0xfff9,
0xf905,
0xf909,
0xf913,
0xf917,
0xff92,
0xf925,
0xf929,
0xf933,
0xf937,
0xff94,
0xf945,
0xf949,
0xf952,
0xf956,
0xff96,
0xf964,
0xf968,
0xf972,
0xf976,
0xff98,
0xf984,
0xf988,
0xf992,
0xf996,
1
};

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Gavin Barraclough]

 On Mar 22, 2015, at 4:35 AM, Maciej Stachowiak m...@apple.com wrote:
 
 Web Abstraction Toolbox (it’s hard to tell the difference between wat and WTF 
 sometimes…)

+1


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Pattern for singleton classes instance getters

[Gavin Barraclough]

Gotta say, ‘singleton’ seems like a really good name for singletons.

G.

 On Jan 28, 2015, at 7:06 PM, Filip Pizlo fpi...@apple.com wrote:
 
 This is shorter: Class::singleton()
 
 It's also more consistent with the rest of our style (we usually don't put 
 get in getter names). 
 
 -Filip
 
 On Jan 28, 2015, at 6:11 PM, Maciej Stachowiak m...@apple.com wrote:
 
 
 On Jan 28, 2015, at 4:28 PM, Darin Adler da...@apple.com wrote:
 
 I like the economy of the smaller non-member function name; it seems overly 
 wordy to be constantly stating the class name as well as the nearly 
 meaningless word “shared”. I think the word “shared” is what I like least 
 about the member function approach.
 
 It had always thought that we used static member functions for this to 
 replicate the pattern from Objective-C, and it seems more idiomatic modern 
 C++ to use a free function for this kind of thing.
 
 Maciej’s point about Class::create() might be enough to convince me to 
 change my view, though; it’s hard to see any reason the same logic wouldn’t 
 apply in that case.
 
 I would also find it acceptable to use free functions for all these cases. 
 Mostly it bugs me for them to be different - the singleton case is rarer, so 
 it seems odd to treat it as especially conciseness-worthy.
 
 Yet another possibility is finding a better name than ‘shared’ for the 
 singleton pattern function, but I don’t have any better ideas. 
 Class::getSingleton() is more explicit but the extra verbosity doesn’t seem 
 helpful to me.
 
 Regards,
 Maciej
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Swift in WebKit

[Gavin Barraclough]

On Jul 28, 2014, at 12:47 PM, David Farler dfar...@apple.com wrote:

 - Swift is a fully supported, albeit new, language starting in Xcode 6.

I think you missed a word off the end of this sentence – Swift support is 
available in Xcode 6 beta. ;-)

Too soon.
G.


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Removing PAGE_VISIBILITY_API compile guard

[Gavin Barraclough]

Thanks for getting this done!

cheers,
G.

On Jun 20, 2014, at 7:39 AM, Eva Balazsfalvi 
evab.u-sze...@partner.samsung.com wrote:

 Hi,
 
 This is a really good suggestion.
 I've already made a patch for it, which you can find here: 
 https://bugs.webkit.org/show_bug.cgi?id=133844
 
 Regards,
 Eva Balazsfalvi
 
 
 Gavin Barraclough wrote:
 Hi,
 
 This feature is now stable  I think this is enabled on all ports, I plan to 
 remove the #ifdefs.
 
 cheers,
 G.
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] EFL EWS Bot output

[Gavin Barraclough]

Yay! – that was annoying, thank you for the fix Ossy!

On Feb 5, 2014, at 12:29 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:

 Hi,
 
 Fix already landed in http://trac.webkit.org/changeset/163167 ;)
 
 Ossy
 
 Gyuyoung Kim írta:
 Hello Oliver,
 I'm really sorry about the inconvenience to you. Let me try to fix it within 
 a few days. Gyuyoung.
 On Wed, Jan 29, 2014 at 8:09 AM, Alexey Proskuryakov a...@webkit.org 
 mailto:a...@webkit.org wrote:
28 ???. 2014 ?., ? 14:59, Oliver Hunt oli...@apple.com
mailto:oli...@apple.com ???(?):
  Could whoever is responsible for the EFL EWS bot please make the
bot set the correct mimetype on the build output.
 
  I've requested this before, but i'm trying again.  It is really
annoying that it triggers a download rather than just opening in the
browser like the output from every other bot.
What needs to be fixed is that the output shouldn't have escape
sequences. The MIME type of text/plain is set by webkit-queues
server, but then networking code in the browser sees a resource
without an extension and that has binary data in it, so it overrides
the type.
Another solution would be for webkitpy or webkit-queues to
automagically strip escape sequences from the output.
- WBR, Alexey Proskuryakov
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [JavaScriptCore] Is property attribute ReadOnly working as intended here?

[Gavin Barraclough]

On Dec 2, 2013, at 10:53 AM, Geoffrey Garen gga...@apple.com wrote:

 Hi Alexei.
 
 To my knowledge, an object's prototype is consulted when a property is not 
 found on the object itself. Any new property is written to the object, never 
 its prototype.
 
 That’s not quite right. The prototype chain is consulted when assigning a new 
 property, if the prototype has a property of that name.

Actually that statement is true – any newly created property will only ever be 
on the object, never its prototype.

 So I was expecting to add the ctor property on newClassObj directly and 
 shadow the prototype's read-only ctor, but it seems that either the 
 property is set on the object's prototype (and the ReadOnly attribute makes 
 it a no-op) or the ReadOnly attribute contaminates the object itself.

The prototype chain is consulted, and presence of a read only property will 
cause assignment to fail.  Default is to fail silently, but if you use strict 
mode you’ll get an exception.

If you want to create a shadowing property on the object you can do so via 
Object.defineProperty.

cheers,
G.


 Geoff
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] ChangeLog format

[Gavin Barraclough]

I’m a bit of a luddite and edit my change log entries by hand.
The old format is more amenable to this, the new format is a regression.

cheers,
G.

On Aug 21, 2013, at 2:25 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Wed, Aug 21, 2013 at 2:04 PM, Ryosuke Niwa rn...@webkit.org wrote:
 Hi,
 
 I have noticed that the change log format has recently been changed.  
 Unfortunately, this didn't work well with all webkitpy tools we have, and has 
 been rolled out in http://trac.webkit.org/changeset/154406.
 
 I kindly ask you to manually edit your patch to use the old format before 
 landing your patch for now.
 
 To clarify, the old multi-line format looks like:
 
 2013-08-13  Ryosuke Niwa  rn...@webkit.org
 
 REGRESSION(r150187): Safari fails to render allrecipe.com comment 
 popups
 https://bugs.webkit.org/show_bug.cgi?id=119780
 
 Reviewed by Benjamin Poulain.
 
 while new single-line format looked like:
 
 2013-08-18  Ryosuke Niwa  rn...@webkit.org
 
 https://webkit.org/b/119917 Pasting multiple lines into a textarea 
 can introduce extra new lines
 
 Reviewed by Darin Adler.
 
 Separately, I'd like to know whether people liked the new format and it's 
 worth my time making webkitpy adopt the new format.
 
 I personally didn't like the new single-line format because it made the first 
 line of each change log too long.  I'm also not a big fun of wrapping URLs in 
 angle brackets.  It's also unclear to me what should happen when there are 
 multiple Bugzilla URLs to list.
 
 But I hear the new format made git log --oneline much more readable so I can 
 be convinced although I don't intend to use git for WebKit development in the 
 foreseeable future myself.
 
 - R. Niwa
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Uint8ClampedArray: subtype of Uint8Array or not? (Was: Heads up: large typed array rewrite)

[Gavin Barraclough]

The spec (http://www.khronos.org/registry/typedarray/specs/latest/) says 
Constructors: None”, looks like FireFox is right, we should probably just 
remove this.

G.

On Aug 14, 2013, at 12:34 AM, Filip Pizlo fpi...@apple.com wrote:

 And on a similar note: ArrayBufferView.  What's that all about?
 
 Previously, WebKit had ArrayBufferView as a prototype and constructor that 
 wasn't instantiable, allowing for things like:
 
 (new Int8Array() instanceof ArrayBufferView) === true
 
 but not:
 
 new ArrayBufferView()  // error!
 
 Firefox has no notion of ArrayBufferView.  I.e. you get a reference error if 
 you mention it.  I tend to think that having ArrayBufferView as a JS-visible 
 concept is strange.
 
 -Filip
 
 
 On Aug 14, 2013, at 12:31 AM, Jochen Eisinger joc...@chromium.org wrote:
 
 Adding Dmitry who recently updated the V8/blink implementation.
 
 -jochen
 
 
 On Wed, Aug 14, 2013 at 9:19 AM, Filip Pizlo fpi...@apple.com wrote:
 What WebKit previously did: Uint8ClampedArray is a subtype of Uint8Array, 
 i.e. Uint8ClampedArray.prototype.__proto__ === Uint8Array.prototype.
 
 I believe that Chrome still does what WebKit does.
 
 What Firefox does: Uint8ClampedArray is not a subtype of Uint8Array, i.e. 
 Uint8ClampedArray.prototype.__proto__ === Object.prototype.
 
 What http://www.khronos.org/registry/typedarray/specs/latest/ says: 
 Uint8ClampedArray implements ArrayBufferView; but that says nothing about 
 its subtype relationship, or lack thereof, with Uint8Array.
 
 I prefer the Firefox semantics.  Any objections?
 
 -Filip
 
 
 On Aug 13, 2013, at 11:19 AM, Filip Pizlo fpi...@apple.com wrote:
 
 Hi everyone!
 
 For the past week or so I've been working on making typed arrays faster, 
 use less memory, and GC better.  It involves moving typed arrays entirely 
 into JSC, and rewriting them so that they benefit from JSC object model 
 optimizations.
 
 Link: https://bugs.webkit.org/show_bug.cgi?id=119064
 
 The short story is, if you're not on the Mac port, then I'll try to do my 
 best to make things work but I'm probably going to make some mistakes.  I'm 
 probably about 48 hours away from landing this and I'll try to make myself 
 available to fix any fall-out.  The things I'm most likely to get wrong 
 are: ensuring that the various code generators work on all build systems; 
 ensuring that the ~20-some files I've added and the ~20-sime files I've 
 deleted, are actually added/deleted correctly on all builds; and making 
 sure that some of the crazy template hacks that I've used work on all 
 compilers.
 
 Why this is all worth it:
 
 It makes typed arrays faster: you can now allocate typed arrays up to 8x 
 faster if they're small, and up to 6x faster if they're big.  Neutering no 
 longer requires walking all worlds. Wrapping and unwrapping an array buffer 
 no longer requires hash look-ups for the normal world.  And some other 
 stuff, too.
 
 It makes typed arrays use less memory: previously a typed array could use 
 as many as 7 objects for each allocation; at best you'd get 5 (JS array 
 buffer view wrapper, native array buffer view wrapper, weak handle to link 
 the two, native array buffer, native array buffer contents).  Now, it takes 
 just 2 objects in the common case (JS array buffer view and a copy-space 
 backing store) and 3 in the case of large ones (JS array buffer view, weak 
 handle for a finalizer, and a malloc'd backing store).  You'll still get 
 all of the crazy objects - at most 6 of them - if you use the full power of 
 typed array APIs.  With all of this in place, a typed array carries only 32 
 bytes of overhead on 64-bit systems and 20 bytes of overhead on 32-bit 
 systems.  It was *a lot* more than that before.
 
 It makes typed arrays manage memory properly: previously the GC didn't know 
 that typed arrays use memory.  So, although the GC could free the memory 
 that typed arrays used, it wouldn't kick in properly in some cases.  See 
 https://bugs.webkit.org/show_bug.cgi?id=119049 and 
 https://bugs.webkit.org/show_bug.cgi?id=114824.  This patch fixes these 
 issues comprehensively.
 
 It makes the code more hackable: previously any attempt to optimize any 
 typed array hack required grappling with binding code generation, layering 
 violations that exposed the typed arrays to JSC JITs despite not being 
 defined in JSC, and a grab-back of helper code that the bindings magically 
 invoked.  There was a lot of duplicated code to deal with the various types 
 of typed arrays.  Now, typed arrays are all templatized; you usually only 
 write a piece of code once thanks to the wonders of template polymorphism.
 
 This also fixes a bunch of semantics issues, with how typed array fields 
 work in JS and when/where exceptions ought to be thrown.  In this regard, 
 I'm basically attempting to match Firefox behavior since that's where the 
 standards appear to be going.
 
 I hope that I get all of this to work on all platforms on the first try.  
 If I don't, I 

Re: [webkit-dev] Pepper and NaCl supporting (prototype)

[Gavin Barraclough]

On Jul 12, 2013, at 9:59 PM, Jake j...@jakeonthenet.com wrote:

 getting on your standards soapbox

OOI standards conformance is a WebKit project goal.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFooclearStyleResolver

[Gavin Barraclough]

On Jun 18, 2013, at 10:16 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Tue, Jun 18, 2013 at 7:20 PM, Simon Fraser simon.fra...@apple.com wrote:
 On Jun 18, 2013, at 7:11 PM, Darin Adler da...@apple.com wrote:
 
 On Jun 18, 2013, at 7:05 PM, Ryosuke Niwa rn...@webkit.org wrote:
 
 Why don't we call it requireStyleResolver() instead?
 
 I’m warming to this idea. Maybe we can use “require” as a term of art, 
 analogous to the way we use “create”, to mean “create if not already 
 created”.
 
 Since the fact that it returns a reference implies that it must create 
 something if necessary, the “required” part of the name seems redundant. Why 
 not just
   StyleResolver styleResolver()
 
 requireStyleResolver() sounds like it would return a bool.
 
 True. But it's important to differentiate a simple inline accessor and a 
 lazily-create function because it's very easy to write code like:
 
 if (styleResolver().x())
 styleResolver().y();
 
 and incur two function calls when we could have done

OOI Is the lazily-create function not inlined? – I wouldn’t expect to pay two 
function calls here, since the method is in the header  looks simple enough:

StyleResolver* ensureStyleResolver()
{ 
if (!m_styleResolver)
createStyleResolver();
return m_styleResolver.get();
}

I imaging we may perform the branch twice, since it may not be apparent to the 
compiler that m_styleResolver is non-null after the first call – though I guess 
this is necessary since theoretically x() could clearStyleResolver.

 StyleResolver resolver = styleResolver();
 if (resolver.x())
 resolver.y();
 
 instead.
 
 On the other hand, I've started to think that maybe we can simply forbid the 
 former style altogether in the style guide so that we'll never have to think 
 about whether a given function is inline or not.
 
 - R. Niwa
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo

[Gavin Barraclough]

I find ‘requireStyleResolver()’ a little confusing.  My first expectation is 
often that a method is an imperative command on the receiver, so I first read 
'requireStyleResolver()’ as mandating that the document now requires a 
StyleResolver, rather than referring to the need of the caller.

In a previous codebase I’ve worked on we used ‘acquire’ as a term of art for 
lazy creation (as a synonym for get, with an inherent connotation that doing so 
may nontrivial).

StyleResolver acquireStyleResolver();

cheers,
G.

On Jun 18, 2013, at 7:11 PM, Darin Adler da...@apple.com wrote:

 On Jun 18, 2013, at 7:05 PM, Ryosuke Niwa rn...@webkit.org wrote:
 
 Why don't we call it requireStyleResolver() instead?
 
 I’m warming to this idea. Maybe we can use “require” as a term of art, 
 analogous to the way we use “create”, to mean “create if not already created”.
 
 -- Darin
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Feature announcement: Web VHS API

[Gavin Barraclough]

On Apr 1, 2013, at 12:36 PM, Glenn Adams wrote:

 correction... NTSC = Never The Same Color (twice)

How do we intend to implement this? – any pseudo random behaviour needs to be 
cryptographically secure to avoid risking an information leak here.

G.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] …Inlines.h vs …InlineMethods.h

[Gavin Barraclough]

These rules generally look great.  One suggestion:

On Nov 5, 2012, at 8:47 AM, Geoffrey Garen wrote:
 (5) Adopt the convention that any function that is not as trivial as int x() 
 { return m_x; } moves out of the class declaration.

How about we simplify this slightly to:

(5) Adopt the convention that any function that is nontrivial should be moved 
out of the class declaration.

We can give an example as to what might constitute trivial if we wish (e.g. is 
a one liner), but I think leaving a little wiggle room to allow developers to 
apply common sense would be a good thing.  While moving all complex functions 
out of class definitions sounds good, for some small classes being able to 
leave some very simple functions in the class declaration might not hurt, and 
might make the code easier to work with.  E.g.:

int y()
{
ASSERT(m_y != BAD_VALUE);
return m_y;
}

cheers,
G.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] MIPS port status update

[Gavin Barraclough]

On Oct 15, 2012, at 7:13 AM, Gergely Kis wrote:
 Should we CC someone directly on these bugs to make the reviews easier?

Likely reviewers would be me, Oliver, Filip or Geoff, feel free to cc.

cheers,
G.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Breaking cycles in mutation observers in JSC

[Gavin Barraclough]

JSC already supports private named properties – you just need allocate a 
'PrivateName' object  use this as a property name.

cheers,
G.


On Aug 23, 2012, at 1:04 PM, Adam Barth aba...@webkit.org wrote:

 Another approach might be to implement hidden properties in
 JavaScriptCore, but I don't know what would be involved in doing that.
 
 Adam
 
 
 On Thu, Aug 23, 2012 at 12:39 PM, Elliott Sprehn espr...@chromium.org wrote:
 I'm trying to fix the memory leaks in MutationObservers
 (http://www.w3.org/TR/dom/#mutation-observers),
 https://bugs.webkit.org/show_bug.cgi?id=93661
 
 This is easy in V8 where I've put a hidden property on the MutationObserver
 wrapper, and the V8MutationCallback object accesses this hidden property.
 The MutationObserver is then an ActiveDOMObject which keeps the wrapper
 alive as long as the observer has DOM nodes it's listening on, even if it's
 unreachable from JS.
 
 In the JSC side I'm not sure how to handle the cycle problem. Do I need to
 use a JSC::Weak in JSMutationCallback and then use visitChildren on the
 JSMutationObserver to call
 addOpaqueRoot(thisObject-impl()-callback-jsValue) ?
 
 In general if someone could explain visitChildren and
 isReachableFromOpaqueRoots and when I want slotVistor.append or
 addOpaqueRoot etc. it would be very helpful.
 
 - E
 
 ___
 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] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore

[Gavin Barraclough]

On the topic of JIT support, the baseline JIT's role is increasingly only to 
serve only to gather profiling data for the DFG JIT, and if you want high 
performance JavaScript on your platform you need to have the DFG JIT enabled.

As the purpose of the two JITs becomes increasingly coupled it may grow 
difficult to support the baseline JIT alone without the DFG JIT (we already 
have a maze of ifdefs for the two JITs, two interpreters, assembler support, 
value profiling support, etc), so any platforms that want to continue to keep a 
JIT enabled should probably look into supporting the DFG JIT sooner rather than 
later.

cheers,
G.


On Jun 23, 2012, at 7:12 AM, Zoltan Herczeg wrote:

 Good for me. Thanks for helping us. This will help to the buildbot
 maintainers as well, since if a patch cause a break where all of our names
 are CC'ed, they can just disable the JIT until the fix is landed. I think
 the several ports of JSC is something we should be proud of and I hope we
 can keep them in the future.
 
 Regards,
 Zoltan
 
 Ah, sorry, I misunderstood!
 
 What about having a convention that assembly port maintainers are CC'd on
 bugs that require new assembler support?
 
 This will give you probably 10 hours heads up before the patch lands.
 
 -F
 
 
 On Jun 22, 2012, at 9:29 PM, Zoltan Herczeg zherc...@webkit.org wrote:
 
 I don't want adding instructions to SH4, MIPS, and legacy ARM to be a
 blocker for JSC work.
 
 I didn't say you have to wait. I just said you should notify us that
 something is coming which will break the build.
 
 Regards,
 Zoltan
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Moving to Git?

[Gavin Barraclough]

On Mar 9, 2012, at 12:30 PM, Mark Rowe wrote:

 What you'll find is that the vast majority of SVN users are simply not 
 participating in this email thread. You'll also find that many people that 
 use git-svn are happy enough with the status quo since it gives those who 
 chose to use it most of the benefits of a pure Git setup without forcing it 
 on others.
 
 In my opinion a substantial benefit needs to be demonstrated in order to 
 convince the existing SVN users, many of which are substantial long-term 
 contributors to the project, that it's worth it to them to relearn how to 
 contribute to WebKit. And I do feel that SVN users need to want to switch to 
 Git in order for it to be worth pursuing such a switch. As a heavy Git user 
 myself I've not seen any arguments in this thread that would be convincing to 
 someone not already familiar with Git.

I think Mark makes a couple of very good points here.

As an svn user, I'm under no illusion about the fact that git is clearly a more 
powerful tool, and that it's important that we support git access for 
contributors who need it.  However I find that personally I work much more 
efficiently in svn – my needs are modest and I find git overly complex for my 
very simple requirements.  I would be happy to give greater consideration to 
moving to git if it would significantly benefit either me or the project as a 
whole for me to do so.

Reading through this thread, it's not obvious to me that accommodating both svn 
and git users is a huge burden on the project.  I hope this is the case, 
because I have to say, the status quo seems pretty good (which isn't to say 
there aren't ways we could improve our processes – there are a few good 
suggestions in this thread).  It seems beneficial to the project to accommodate 
the needs of a wide range of contributors as well as we reasonable can, and it 
seems that we are in a fortunate position with regard to version control where 
we are already doing so very well.  I would hope this would only change if 
there were good reason to do so.

cheers,
G.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] new shell for JavaScriptCore?

[Gavin Barraclough]

On Jan 10, 2012, at 7:33 AM, Andy Wingo wrote:
 Hello JSC hackers,
 
 I've been thinking for some time now that there is room for another
 command-line shell for JSC.

Hi Andy,

Yes!

Some more things to add to the wish list:
* tab completion (e.g. Math.si -tab- Math.sin)
* persistant command history over invocations
* binding results of prior commands to variables in global scope.
(I believe that the readline library has some useful hooks we're not currently 
using to help with the first two of these).

 Specific things that one might want to support in the new shell would be
 meta-commands:
 
 ,profile f(1)
 ,disassemble f
 
 Meta-commands are commands for the shell, not expressions to be
 evaluated.  As expressions can't begin with a comma, we would abuse the
 comma to introduce those meta-commands.

I'd suggest that it might be better to expose new commands through JavaScript 
where possible, rather than using a new syntax.  One key advantage is that if 
these commands are exposed through JavaScript then you can easily script use of 
the shell commands in JS, e.g. to disassemble all the functions on object foo's 
prototype:

for (var func in foo.prototype) disassemble(foo.prototype[func]);

 There would also be a meta-command to inspect and modify the current
 heuristics, to turn the JIT on and off, etc.  These options could also
 be turned on and off from the command line.

It would be a really great if any new shell were not just be limited to being 
useful to WebKit developers, but was also suitable for use by programmers 
wanting to script in JavaScript.  Some of the tools you have listed should be 
extremely useful to us in developing JSC, but would probably be inappropriate 
to ship to customers, so we might want the option to be able to compile these 
out in some builds.  But I don't think that this should be a constraint in any 
way – we might just want to wrap some of the tools in #ifdefs, or maybe guard 
them on an environment variable being set.

 So, I wanted to solicit some thoughts on this idea before going to
 implement it.  I really think that the right place for a project like
 this is in WebKit proper, rather than in some external tree, as that way
 it will always be in sync with JSC.

Yes! - we'd definitely love to have a better shell in the project.

One other random thought, it might be desirable if the shell were written to 
the JSC API, rather than being written directly against JSC's internal headers. 
 If the current API is insufficient we can expose some additional functionality 
through private headers.  This is certainly not a requirement, but it would be 
a cleaner way to do things, and would serve as a really great test for the 
utility  design of our API (and may be helpful in informing future 
improvements).

cheers,
G.


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] JavaScriptCore and ES6

[Gavin Barraclough]

Hi Andy,

 As you probably know, the ECMA TC39 committee is slowly approaching
 consensus on a new revision of the ECMAScript language.  The interim
 results of this process have gone under various names: Harmony, ES.next,
 and ES6.  They are the same thing.  This mail is intended to open the
 discussion on what to do now regarding ES6 in JSC.

Let's stick with using the name ES6.  Per Brendan's comments I guess ES.next is 
probably more correct right now, but the meaning of ES.next is presumably 
liable to change once ES6 is released!

 ES6 does not yet define how extended mode is entered, however.  Some ES6
 functionality is incompatible both with classic mode and with strict
 mode, so it has to be an opt-in thing, perhaps via script
 type=application/ecmascript;version=6.
 
 However, there is a subset of ES6 that is compatible with strict-mode.
 I am interested in implementing parts of this set.  Specifically, I am
 interested in implementing block-scoped `let' and `const'.
 
 I think it would be fine to enable the compatible subset of ES6 within
 all strict-mode code.  It would not be incompatible with existing code
 on the web.  V8 seems likely to go in this direction as well, and
 SpiderMonkey already has done so.  Effectively, strict mode could become
 compatible extended mode, globally.

As it stands, ES6 introduces a mix of new features (new syntax, which would 
have been syntax errors in ES5), and changes to the semantics of existing ES5 
syntax (typeof null, resolving to global object).

So far as the new features are concerned, I don't think we want to make them 
opt-in and artificially tie them to ES5 strict mode – these features have 
nothing to do with ES5 strict.  If we do want these features to require an 
explicit opt-in, then they should be restricted to ES6 (extended mode).  
However I think it is probably unnecessary and undesirable to restrict them at 
all – instead we should just make them available to all scripts.  In practice I 
don't think there will be any syntax extensions that would be backwards 
compatible from ES6 to ES5-strict, but not compatible with ES5.  We have an 
existing extension to provide limited support for 'const' in classic mode for 
web compatibility reasons, but provided that it does not break the web to do so 
it would be better to replace this with ES6 compatible const semantics, rather 
than unnecessarily maintaining two separate and incompatible behaviours.  
Technically 'let' is not a reserved word outside of strict mode in ES5 which 
could be an issue, but I think even this can probably be support well in 
classic mode by handling it as a contextual keyword (compatible modulo a minor 
auto semicolon insertion quirk, I think).  Similar for 'yield', and this is 
likely to be even less of an issue given the restricted context in which it can 
be used.

So far as changes to the semantics of existing syntax are concerned, it is 
certainly possible that we will need to add support for the script tag to 
specifying a language version (likely passed into JSC as a property of the 
SourceCode object).  In addition we may want to consider whether it makes sense 
to imply extended mode within ES6 language features – e.g. if we permit module 
syntax as an extension in ES5, we may want to enable full ES6 semantics for all 
code within the body of a module.  If we do, this may mean propagating state 
that enables extended mode when parsing, and tracking this for functions (much 
as we do already for strict).

 Compatible extended mode is not a point we need to decide now,
 however.  Implementation work towards agreed-upon parts of ES6 is useful
 in any eventuality.
 
 Now, it is fine enough to have an implementation of parts of ES6 behind
 an #ifdef.  I think though that we should get to the point that the
 #ifdef is on by default, then removed entirely.  We still need a bit to
 indicate at parse-time whether a piece of code is extended-mode or
 strict-mode.  It does not seem that we need a runtime extended-mode bit,
 though, as we do with strict-mode vs classic-mode.
 
 My current approach to this, given that the ES6 draft doesn't specify
 how to enter extended mode, is to provide a global flag that turns
 strict mode into compatible extended mode.

We may not want to enable ES6 support by default until the spec is stable and 
we have a relatively complete implementation, but this shouldn't block 
development or prevent features from being compiled in at an earlier stage.  In 
fact, we really need to build in all features from the point they are added, so 
that regression tests can be committed along with the implementation.  As such 
enabling ES6 support should be a runtime setting rather than at compile time 
one.  This should be done via a page setting (WebCore/pages/Settings.h), since 
this will make it easy for us to enable ES6 support via the WebKit interface, 
from DRT or a browser (JSC should be able to query this setting via 
JSGlobalObject).

Hope this 

Re: [webkit-dev] multithreading in JSC

[Gavin Barraclough]

On Dec 2, 2011, at 12:10 PM, venkeng koon wrote:

 Hi! 
 I have started to invistigate SFX  and now have some information about it.
 But I have still had some quetions and will be very gratefull if you could 
 help me.
 First. Does SFX support multithreading? Can he compile several funcotion at 
 once?

JSC supports the web workers API, which allows for concurrent execution but 
only over separate heaps of JavaScript objects (communication between threads 
limited to message passing).

A number of additional threads also exist within the engine for internal usage, 
but no execution of JS code takes place on these threads (e.g. parallel GC, 
reaping unused memory pages from by the C heap).

Compilation is currently synchronous on the thread that will be executing the 
code.

On Dec 2, 2011, at 2:05 PM, vahagvahag wrote:

 
 Hi.
 How can I get native code of function cause I wanna disassemble it to see
 generated assebler.
 I know that machine code goes trough AssemblerBuffer::executableCopy


On Dec 2, 2011, at 12:10 PM, venkeng koon wrote:

 Second. Now I'm working to dump assembler from native code. I have found the 
 executableCopy function and think that  can dump native code from this 
 function and disassemble it, though working on this for several days I still 
 have no result.

JSC does not currently have a built in disassembler (though this is not 
necessarily a bad idea).  You may be able to dump the code in a debugger.  
'executableCopy' is basically just a memcpy of the code (moving generated code 
from a temporary non-executable buffer into an executable region of memory).

G.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] squirrefish extreme on Arm.

[Gavin Barraclough]

-d should work fine on ARM - check your build settings, is any #ifndef NDEBUG 
code getting built?
In addition there are a set of switches in dfg/DFGCommon.h that include ones to 
enable further dumping of the intermediate representation.

G.


On Nov 29, 2011, at 2:51 AM, vahagvahag wrote:

 
 Hi all. I have been studing about squirrefish extreme for last several days
 but can't find answers to several quations I need.
 1. How can I dump compiling process? For instanance in GCC I can compile
 with -da -fdump_tree_all and then get all passes up to assembler generation.
 So is there any way to do the same on squirrefish extreme ?  I wanna to see
 which optimizations are works in each state. 
 And  finaly how can I get bytecode from my source. I built webkitv with
 --debug option and tried to run  ./jsc-3 sunspider -d, but it didn't give
 bytecode
 
 
 
 
 -- 
 View this message in context: 
 http://old.nabble.com/squirrefish-extreme-on-Arm.-tp32876913p32880353.html
 Sent from the Webkit mailing list archive at Nabble.com.
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] old-run-webkit-tests is officially deprecated.

[Gavin Barraclough]

On Oct 27, 2011, at 3:00 PM, Eric Seidel wrote:

 If you're still using old-run-webkit-tests for your work, I would
 *love* to know and fix any issues you may have with NRWT.

Hi Eric,

Unless there is a trick to this that I am unaware of, I think NRWT doesn't 
support running 32-bit tests on a 64-bit platform?
ORWT has a --32-bit switch to do so (albeit requiring some kludging these days 
to get it to work correctly).

cheers,
G.

p.s. NRWT is awesome, yay to parallel test running.


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] unsigned versus size_t in WTFString.h

[Gavin Barraclough]

Hi Adam,

Yes, I believe our current thinking is that the external interface to String 
lengths / indices should all be in size_t (though unless we believe we need to 
support strings  4GB we should keep the length stored as a 32 bit value 
internally).  There are a couple of bugzilla bugs relevant, though I don't 
think either currently capture exactly this.

https://bugs.webkit.org/show_bug.cgi?id=49637
https://bugs.webkit.org/show_bug.cgi?id=60279

cheers,
G.


On Sep 6, 2011, at 9:12 PM, Adam Barth wrote:

 I wanted to confirm my understanding before going too far off into the
 woods: Most of the uses of unsigned in WTFString.h should really be
 size_t, right?
 
 http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/text/WTFString.h
 
 For example,
 
 unsigned length() const
 
 should be
 
 size_t length() const
 
 and
 
 size_t find(UChar c, unsigned start = 0) const
 
 should be
 
 size_t find(UChar c, size_t start = 0) const
 
 (Obviously some, like static String number(unsigned), should stay as
 unsigned.)
 
 Thanks,
 Adam
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WTF StackBounds not compatible with Windows fiber threads custom fiber or thread stack size

[Gavin Barraclough]

I had a partially working solution to this using the deallocation stack member 
of the Win32 Thread Information Block, see 
https://bugs.webkit.org/show_bug.cgi?id=26276  
http://en.wikipedia.org/wiki/Win32_Thread_Information_Block – but I didn't 
manage to get this working consistently.  Perhaps a Windows expert may be able 
to build on this.

Bug #26276 would be a great place to be having this discussion, so that 
anything useful is recorded.

cheers,
G.


On Aug 29, 2011, at 9:08 PM, Jacques Quidu wrote:

 Hello,
 
 WTF current implementation of StackBounds is not quite compatible with 
 Windows fiber threads and/or custom stack sizes:
 we have successfully implemented support for Windows fiber threads in 
 StackBounds  fixed some 64 issues but we are still stuck on how to determine 
 thread or fiber allocated stack size...
 
 From the fiber or thread context, i can only get the stack base  stack 
 current pointer but not the allocated stack size: any idea on how to get it 
 assuming that i cannot get stack size from the executable stack size because 
 our main app might use cooperative fiber threads with variable stack size, 
 along with preemptive threads created from WebKit ?
 
 For now the only workaround i think about is to pass the fiber stack size as 
 fiber data while creating the fiber in our main app  get it in StackBounds 
 with GetFiberData() using a custom define to filter with our app impl: but it 
 means adding code specific to our app in JavacriptCore/WTF which i would like 
 to avoid if it is possible.
 
 Kind regards, 
 
 Jacques Quidu
 Graphics Software Engineer
 E-Mail: jqu...@hotmail.fr
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] String::impl() returns NULL causes crash

[Gavin Barraclough]

On Apr 13, 2011, at 5:32 PM, Mo, Zhenyao wrote:

 What value should we return for hash(NULL)?


From the top of the file:

// The hash() functions on StringHash and CaseFoldingHash do not support
// null strings. get(), contains(), and add() on HashMapString,..., 
StringHash
// cause a null-pointer dereference when passed null strings.

In the hash traits for String, we use String() as the empty value for hash 
tables keyed on a string.  Our hash tables will not work correctly if the hash 
trait's empty value is used as a key in the table, so allowing a null string to 
be hashed  used as a key would only result in later errors.  We should 
probably ASSERT in the hash methods that the Strings/StringImpls passed to the 
hash() methods in StringHash are not null.

To fix your problem you will need to find what is using a null string as a key 
in a hashtable, and stop it – making hash() return a value for the null string 
will not fix this bug.

cheers,
G.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Question about StringImpl::create

[Gavin Barraclough]

On Dec 16, 2010, at 9:45 PM, 谢愈挺 wrote:

 I have a question about StringImpl::create(). Is it can only input latin1 
 data?

Yes, this method takes latin1 data all const char* arguments in WTFString are 
handled as latin1.
String::fromUTF8 can be used to create strings with utf8 data.

 If it can only input the latin1 data, the following code maybe incorrect:
 In WTFString.cpp :
 String String::format(const char *format, ...)
 {
  ...
 Vectorchar, 256 buffer;
 ...
   return StringImpl::create(buffer.data(), len);
 }
  
 The buffer.data() maybe utf8 data!

The short answer is that String::format should be considered deprecated - its 
behavior is platform-specific, and we'd like to move away from it.

Since all const char* arguments to the String methods are treated as latin1, 
format is not suitable for use with utf8 data – any code that is calling format 
but that may be working with utf8 data needs to be refactored to stop using 
this method (utf8 should be converted to WebCore Strings first, then use the 
other conversion/concatenation methods available).

cheers,
G.


 Thanks.
  
 pattin
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] [Qt] QTest / tst_QWebFrame::connectAndDisconnect()

[Gavin Barraclough]

Hi,

Apologies, I've introduced some red to the tree, a test on Qt needs some new 
expected results adding, and I can't find where they're kept.

The test is tst_QWebFrame::connectAndDisconnect(), the new output is correct 
(the format for some exception messages has changed slightly), if someone could 
either upload new results or point me in the direction to do so myself that 
would be most appreciated.

cheers,
G.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] [Qt] QTest / tst_QWebFrame::connectAndDisconnect()

[Gavin Barraclough]

Problem solved, thanks to mitzpettel!
cheers, G.


On Nov 15, 2010, at 8:24 PM, Gavin Barraclough wrote:

 Hi,
 
 Apologies, I've introduced some red to the tree, a test on Qt needs some new 
 expected results adding, and I can't find where they're kept.
 
 The test is tst_QWebFrame::connectAndDisconnect(), the new output is correct 
 (the format for some exception messages has changed slightly), if someone 
 could either upload new results or point me in the direction to do so myself 
 that would be most appreciated.
 
 cheers,
 G.
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Tests that separate JS and HTML

[Gavin Barraclough]

On Aug 13, 2010, at 3:17 AM, Alexey Proskuryakov wrote:

 Of course, there is the special case of fast/js tests, which we (I think) 
 still hope to run without a WebView one day. For that, keeping JS separate is 
 obviously desirable.

Absolutely agreed - and these can already be run in a command-line shell, by 
using the LayoutTests/fast/js/resources/standalone-(pre|post).js scripts.  This 
applies to many of the tests in fast/js, as well as the ietestcenter/Javascript 
suite.

Sadly we don't yet have a script to run all these test for you, we should add 
one at some point.  Also, it would also be great to port over the other js-only 
tests in fast/js (and any elsewhere, e.g. fast/regex).

G.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] JSC String re-factorings are hosing the tree.

[Gavin Barraclough]

Hi Eric,

Many apologies for the redness.  These changes are pretty much  
complete now, so hopefully there shouldn't be any more big file moves  
like this too soon.


One thing that was hugely useful in minimizing the breakage as much as  
possible while making these changes was the ews bots – these generally  
helped me to get my patches building cleanly on all platforms bar  
Windows before committing.  It is a real shame that an ews bot isn't  
available for Windows, since this would be particularly useful - JSC  
changes frequently break Windows builds due to the .def files.


I believe a big problem that caused the extended periods of redness  
was the slowness of the Windows test queues.  These can lag badly  
behind the builds, making failures here very are easy to miss - having  
landed a large change, and waited to watch the waterfall stay green  
for an extended period of time, it was easy to be under the  
misapprehension that everything was okay.  Only later would I discover  
windows test had started to fail.  Clearly there is a lesson I've  
learned here, but maybe we can find some more hardware to throw at  
these queues, to help them avoid getting quite so far behind.


cheers,
G.


On Apr 21, 2010, at 1:39 PM, Eric Seidel wrote:


A large portion of the tree redness in the last 3 days is due to JSC
string re-factoring.

We need to build some better tools, or find some better method to land
these changes w/o hosing the tree.  I'm happy to help with building of
said tools if folks have requests/suggestions.

Broken in 58001  Fixes: 58003, 58006, 58007, 58008, 58010
Time: 55m

Broken in 57904   Fixes: 57908, 57911, 57912, 57917
Time 1hr 45m

Broken in 57829   Attempted fix: 57835, Rolled out in:57853
Time: 3h 21m

Re-broke in 57879   Fixes: 57883, 57884
Time: 3h 3m

Getting 57829 landed resulted in nearly a full work-day of tree
redness. :(  Also, even once a change is fixed, it will take 15 mins
or so for all the bots to cycle green.

-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] [webkit-changes] [56825] trunk

[Gavin Barraclough]

On Mar 31, 2010, at 10:08 AM, Alexey Proskuryakov wrote:


On 30.03.2010, at 22:44, barraclo...@apple.com wrote:


+WebCString::operator WTF::CString() const


There probably should be a using CString directive in CString.h -  
we do that for all public symbols in WTF.


There should be ... http://trac.webkit.org/browser/trunk/JavaScriptCore/wtf/text/CString.h?rev=56825#L79 
 ... and there already is!


The idea is that we don't need or want namespaces to avoid name  
conflicts between public WTF symbols and WebCore or WebKit, as we  
control them all.


There are two problems that currently cause name conflicts for the  
name CString in ToT.   One is that JSC currently defines a class  
called CString (when I land https://bugs.webkit.org/show_bug.cgi?id=36871 
 this will go away), so in .cpp files that do a using namespace JSC  
the name CString is ambiguous.  Secondly, Windows has a standard type  
called CString in its libraries, which appears to conflict when  
compiling some files.  Additionally, when changing some files  
exclusively used in ports that I don't build locally I chose to be  
conservative  reduce this risk of setting the tree on fire by just  
replacing WebCore::CString with WTF::CString while landing this patch.


Once JSC::CString has gone away I'll have a look through at some point  
 see if some of the remaining WTF::s are redundant and can be removed.


cheers,
G.


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Proposing style guide change regarding braces on conditional arms

[Gavin Barraclough]

On Dec 2, 2009, at 9:57 PM, Dan Bernstein wrote:


I am satisfied with the existing rule.


+1


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] jit for arm

[Gavin Barraclough]

From http://lists.webkit.org/:
ListDescription
webkit-help [no description available]

Hmmm, yes, there would seem to be some scope to make that a little  
more descriptive!  ;-)


G.


On Nov 17, 2009, at 11:46 PM, Zoltan Herczeg wrote:


Hi,

seems the original mail was sent to both webkit-dev and webkit-help.  
My

reply was on webkit-help, and the discussion continued there.

https://lists.webkit.org/pipermail/webkit-help/2009-November/000380.html

Perhaps we should clarify better the purpose of these mailing lists,  
since

if people can't decide which list is better for them, they do double
posts.

Zoltan


On Nov 4, 2009, at 8:37 AM, ll Jefferry wrote:


Hi,

when i reading the jit for arm source code, i am not very clear the
functionality of the flowing functions:
   ctiTrampoline


This code is used when entering from the C runtime into JIT generated
code.  JIT generated code does not necessarily respect C calling
conventions, so this routine sets up the stack frame, preserves
registers, etc, as necessary to allow the JIT code to be run.


   ctiVMThrowTrampoline


To perform certain operations the JIT will call back into C code.
Usually the C callback can just return in a perfectly normal fashion
and continue execution once it has completed, however in the case  
that

an exception is thrown special handling is required to change the
control flow.  The return address of the C callback is instead  
changed

to point to this, and this piece of code handles looking up the
exception handler at which execution will be resumed.


   ctiOpThrowNotCaught


This is used to from within cti_op_throw, which implements the  
'throw'

keyword in JavaScript.  The cti_op_throw method will attempt to look
up a handler routine that catches the exception.  However if the
exception is not caught it is necessary to force an early termination
of JIT execution.  The cti_op_throw C callback always modifies its
return address, either to point to the code for the appropriate
exception handler to catch the exception, or to ctiOpThrowNotCaught  
if

no handler is found.



could you explain to me?
and another question is that:  in cacheFlush function, why the
system call number is 0xf0002? if it is defined by the toolchain?


Zoltan, Gabor?




thanks!

BR,
Jeff

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev






___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] jit for arm

[Gavin Barraclough]

On Nov 4, 2009, at 8:37 AM, ll Jefferry wrote:


Hi,

when i reading the jit for arm source code, i am not very clear the  
functionality of the flowing functions:

ctiTrampoline


This code is used when entering from the C runtime into JIT generated  
code.  JIT generated code does not necessarily respect C calling  
conventions, so this routine sets up the stack frame, preserves  
registers, etc, as necessary to allow the JIT code to be run.



ctiVMThrowTrampoline


To perform certain operations the JIT will call back into C code.   
Usually the C callback can just return in a perfectly normal fashion  
and continue execution once it has completed, however in the case that  
an exception is thrown special handling is required to change the  
control flow.  The return address of the C callback is instead changed  
to point to this, and this piece of code handles looking up the  
exception handler at which execution will be resumed.



ctiOpThrowNotCaught


This is used to from within cti_op_throw, which implements the 'throw'  
keyword in JavaScript.  The cti_op_throw method will attempt to look  
up a handler routine that catches the exception.  However if the  
exception is not caught it is necessary to force an early termination  
of JIT execution.  The cti_op_throw C callback always modifies its  
return address, either to point to the code for the appropriate  
exception handler to catch the exception, or to ctiOpThrowNotCaught if  
no handler is found.




could you explain to me?
and another question is that:  in cacheFlush function, why the  
system call number is 0xf0002? if it is defined by the toolchain?


Zoltan, Gabor?




thanks!

BR,
Jeff

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] unwritten rules of webkit style

[Gavin Barraclough]

I believe the C spec requires that files end in a newline, though I  
couldn't comment on the c++ spec.  Possibly redundant to list this as  
WebKit style issue, if required by the language?


G.

On Sep 3, 2009, at 10:11 AM, Darin Adler wrote:


On Sep 2, 2009, at 11:18 PM, Brent Fulgham wrote:


On Sep 2, 2009, at 9:46 AM, Peter Kasting wrote:

Misc
Files who should end with newlines.

s/who//.  In fact it might be clearer to say Files should end  
with a trailing newline.


I always follow this rule, but I don't remember why it came to  
exist.  Is this convention needed for source control or something?


It’s not needed for anything. Tools like diff produce slightly  
unpleasant output for files that don’t end in newlines, so we  
include them.


-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Trampoline problem

[Gavin Barraclough]

On Jun 11, 2009, at 10:20 AM, Toshiyasu Morita wrote:

I've tracked down a crash in our JIT port to a problem with the  
trampoline generation.


The symptom of the crash is: the ScopeChain becomes corrupted and  
acquires the value of 1.


void  
JIT::privateCompileCTIMachineTrampolines(RefPtrExecutablePool*  
executablePool, void** ctiArrayLengthTrampoline, void**  
ctiStringLengthTrampoline, void** ctiVirtualCallPreLink, void**  
ctiVirtualCallLink, void** ctiVirtualCall)

{
emitPutJITStubArg(regT3, 2);
...
Call callArityCheck2 = call();
move(regT1, callFrameRegister);
emitGetJITStubArg(1, regT2);  (1)
...
compileOpCallInitializeCallFrame();
...
}

void JIT::compileOpCallInitializeCallFrame()
{
store32(regT1, Address(callFrameRegister,  
RegisterFile::ArgumentCount * static_castint(sizeof(Register;


loadPtr(Address(regT2, FIELD_OFFSET(JSFunction, m_scopeChain) +  
FIELD_OFFSET(ScopeChain, m_node)), regT1); // newScopeChain (2)


storePtr(ImmPtr(JSValuePtr::encode(noValue())),  
Address(callFrameRegister, RegisterFile::OptionalCalleeArguments *  
static_castint(sizeof(Register;
storePtr(regT2, Address(callFrameRegister, RegisterFile::Callee  
* static_castint(sizeof(Register;
storePtr(regT1, Address(callFrameRegister,  
RegisterFile::ScopeChain * static_castint(sizeof(Register; (3)

}

So basically, what happens is:

(1) The trampoline loads args[1] into regT2


This is restoring the pointer to callee JSFunction*.


(2) Loads *(regT2 + offset) into reg T1


This is loading the ScopeChain from the callee function.

(3) Stores regT1 at args[-6] and destroys the value (writes 1 to  
ScopeChain)


This is setting the ScopeChain in the callframe header so it is passed  
to the callee.


I don't understand what this code is trying to do.. Comments  
appreciated.


Toshi


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] arm jit

[Gavin Barraclough]

And here, I have to make a short comment on the non-acceptance of  
our ARM

JIT implementation. In your mail you mention that you would remain
reluctant to accept a duplicate of the JIT into the tree, rather  
than a
port of the existing JIT utilizing the MacroAssembler abstraction.  
Well,

did you check our ARM port? It has been rewritten to conform to the
MacroAssembler interfaces more than a month ago and posted it into the
bugzilla (https://bugs.webkit.org/show_bug.cgi?id=24986).


Hi Zoltan,

I'm sorry if I'm misinterpreting you here, but it sounds like over the  
last month you have been expecting your MacroAssembler based ARM port  
to have been reviewed.  If so -


Then I can quite understand your frustration, and do sympathize  
greatly with you.  There clearly has been a breakdown in  
communication, and I'm sorry about your disappointment.  I'm afraid  
that we had no way of knowing that you considered your port to be  
complete.  Just last week, in an email on this list, I said, when you  
have a patch ready for review, please attach it to the bug and set the  
review flag – I was under the impression that you did not feel your  
changes were yet final (by the sound of it I was mistaken).  I was  
assuming that when a final patch was ready you would attach it to the  
bug, and mark it for review.


We have a procedure for accepting contributions to avoid exactly this  
kind of miscommunication.  The mechanism for communicating to us that  
you believe your patch is ready is very simple, and is absolutely  
critical if you want to get code into WebKit.  Patches ready for  
review must be marked as such in bugzilla.  Without this we cannot  
tell which patches attached to bugs are complete, and which represent  
work in progress.


I urge you to review the instructions on contributing on the website,  
since following these will be the only way to avoid similar  
disappointment in the future.  Perhaps this is an area where we need  
to improve our communication – perhaps we need to make these  
instructions clearer, or more prominent on the website.  The website  
is all stored in svn, so please do file bugs in bugzilla – or patches  
welcome – if you think these can be improved.



Anyway, we have updated the MacroAssembler-based ARM port of ours,
uploaded it to the bugzilla, and set the review flag on the patch.


I've had a brief chance to look at the patch, and it's looking really  
great.  There are some bits to clean up a little to get it through  
review, and we will want to land a change of this magnitude  
incrementally.  I'm afraid that I have a busy day today, I will try to  
comment on the bug tonight but it may have to wait until the morning.   
Hopefully we can get this landed into ToT fairly quickly.


cheers,
G.



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ScopeChainNode leak?

[Gavin Barraclough]

Hi Andrew,

It certainly sounds likely this is a bug, and the best person to  
comment on it is probably Oliver, who is not on this list.


Could you please file a bug at bugs.webkit.org?

Many thanks,
G.

On Jun 10, 2009, at 11:26 AM, Andrew Webster wrote:


I've been tracking down a memory leak I've noticed on pages using
JQuery (and others).  Valgrind pointed out that it is ScopeChainNodes
that are leaking.  I have tracked this down to functions that are not
dereffing their ScopeChainNode when they are deleted.  I notice that
the JSFunction dtor contains code that is supposed to do this, but it
is ifdef'd out for non-JIT platforms (of which I am one of):

#if ENABLE(JIT)
   // JIT code for other functions may have had calls linked directly
to the code for this function; these links
   // are based on a check for the this pointer value for this
JSFunction - which will no longer be valid once
   // this memory is freed and may be reused (potentially for
another, different JSFunction).
   if (!isHostFunction()) {
   if (m_body  m_body-isGenerated())
   m_body-generatedBytecode().unlinkCallers();
   scopeChain().~ScopeChain();
   }

#endif

If I switch this code to:

   if (!isHostFunction()) {
#if ENABLE(JIT)
   // JIT code for other functions may have had calls linked
directly to the code for this function; these links
   // are based on a check for the this pointer value for this
JSFunction - which will no longer be valid once
   // this memory is freed and may be reused (potentially for
another, different JSFunction).
   if (m_body  m_body-isGenerated())
   m_body-generatedBytecode().unlinkCallers();
#endif
   scopeChain().~ScopeChain();
   }

it seems to solve the memory leak.  However, the release build doesn't
work properly unless I remove the #ifndef NDEBUG from ScopeChain.h so
that the pointers and such are cleared on delete.  I also thought that
it might be a good idea to call scopeChain().~ScopeChain() when the
scope is re-assigned in setScopeChain or clearScopeChain, however this
seems to introduce problems.

Can anyone comment on why scopeChain().~ScopeChain() is wrapped in #if
ENABLE(JIT)?  Is there a better solution then what I've done?  Will I
face another leak by not dereffing in setScopeChain/cleanScopeChain?

Thanks,
Andrew
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] arm jit

[Gavin Barraclough]

On Jun 10, 2009, at 1:15 PM, Toshiyasu Morita wrote:


--- On Wed, 6/10/09, Geoffrey Garen gga...@apple.com wrote:

I'm having a hard time understanding from your comment what  
optimization changes you think are appropriate, but if you can  
produce a patch that implements
 your idea, and shows a benefit on a benchmark, I'd be happy to  
review it.


Consider something like op_call.

This expands out to 95 inline instructions on the MIPS for just the  
slow case alone, of which 3 are functions calls to other functions.  
So this probably requires thousands of clock cycles to execute.


IMHO it doesn't make sense to inline op_call because:


[ I'm sorry, I've been away from a net connection, I may be  
replicating a couple of things ggaren  olliej have already said. ]


Okay!  First up, have you tried turning off ENABLE_JIT_OPTIMIZE_CALL?   
If you do so, it should address the majority of your concerns, below  
(specifically, reducing code size, and removing the need for op_call  
to patch generated code).


Of course, we added the call optimizations because we measure them as  
a significant performance improvement, but feel free to test whether  
this is true on your platform, and once the MIPS JIT is in the tree  
we'd be happy to consider changes to the optimized mode that aid MIPS  
performance.


1. It's a huge amount of JIT code just to save three of four  
instructions at runtime (call, return, and maybe some register  
shuffling)


2. The code which is executed is thousands of instructions and  
saving three or four instructions is a microscopic net win.


4. It make the generated machine code MUCH larger because instead of  
having one copy of this function that is written in C/C++ and  
statically compiled, there are multiple copies of this code for  
every instance of op_call, which makes the instruction cache much  
less effective.


I think it's worth making sure you understand the optimization here.   
The majority of calls can be optimized, and having been optimized only  
run the sequence of instructions planted in the main generation pass.   
This code path is only a handful of instructions long, and introducing  
an extra call and return onto this path would almost certainly degrade  
performance (feel free to try doing so, and please so submit any  
patches that provide a memory saving, without significantly degrading  
performance).  For such a short and performance critical fragment of  
code it clearly could make sense to tweak the code for specific  
platforms, and it may well provide a significant performance benefit  
to do so.  We should certainly consider such patches.


The slow case JIT code is much longer, and less frequently executed.   
Introducing a call and return here to share code between calls  
definitely makes sense.  The way you know we think that it, the JIT  
already works this way!  The slow cases call out to a set of shared  
trampolines generated in privateCompileCTIMachineTrampolines.  This is  
however, a work in progress, and we are currently still clearly  
generating far more code than we should be in the slow cases.  More  
work should be done to unify the pre-linked and post-link slow case  
states, and to move work into the trampolines (this is something I may  
be looking at again fairly soon).


It is certainly valid to question whether the work performed by the  
machine trampolines is better in JIT generated code, or in C++ code  
that the compiler can optimize.  In the early stages of its  
development the JIT was more a context threaded interpreter, calling  
out to C++ to perform almost all optimizations.  We have migrated work  
into JIT generated code only where it has been a performance benefit  
to do so.  Of course, that doesn't mean that we always got it right,  
or that the trade-offs haven't changed, or that the policy might not  
need to be tweaked on different platforms.  Please feel free to  
experiment, and if you can produce patches that reduce the amount of  
work done in these JIT generated trampolines while improving  
performance then we'll be hugely appreciative (in fact, it needn't  
even be a performance win here – anything that doesn't degrade  
performance could be a nice simplification).


5. The generated machine code is weakly optimized, so instead of  
having calling code which is well-optimized by the C/C++ compiler  
for MIPS, it is executing weakly optimized dynamically generated  
code. Since the code is weakly optimized, it is also much larger  
than it should be, which also makes the instruction cache much less  
effective.


6. The JIT-generated code resides in the data cache, and must be  
flushed to main memory, then the instruction cache must be  
invalidated so the new code will load into the instruction cache.  
Because the WebKit JIT seems to do lazy compilation of functions at  
call time (instead of compiling all the functions in one pass), this  
requires the data cache to be flushed and the 

Re: [webkit-dev] arm jit

[Gavin Barraclough]

Toshiyasu,

On Jun 10, 2009, at 2:24 PM, Toshiyasu Morita wrote:


Why does the arity check need to be in the caller, and not the callee?


The majority of call sites always call to the same callee, and we can  
optimize these cases for calling that same function repeatedly.   
Within the optimized path of the op_call, where we are linked to a  
specific callee, we can statically determine at compile time that the  
caller and callee have the same arity, and omit the dynamic arity  
check altogether – which is a performance win.  Within the callee  
(where you might have been called from multiple call sites with  
difference numbers of arguments passed) it is not clear how you would  
implement such an optimization.  But patches welcome as ever!


(btw, I was on your side on this one, the arity check in the callee  
seemed more natural to me at first, until the benefits of performing  
the check in the caller became clear.  That said, from a design point  
of view, fixing up arity at the call site can also makes sense in  
matching (or at least being analogous to) calling conventions of other  
languages.  If you consider calling a JS function with too few  
arguments as being akin to invoking a C++ method with some defaulted  
parameters not-provided, then it is also the responsibility of code  
generated for the call to such a method to ensure that values for all  
declared parameters are passed.)



Consider: one function that is called from 10,000 places.

Arity check in the caller: 10,000 copies of the artity check.
Arity check in the callee: one copy of the arity check


You're not taking into account that we don't generate the arity check  
inline, instead it is in a shared trampoline.


Consider: one hundred functions that are called from 10,000 places.

Arity check in the caller: 10,000 copies of the artity check.
Arity check in the callee: one hundred copies of the arity check

Arity check in a set of 3 shared trampolines (which is how the JIT is  
currently implemented): 3 copies.
(3 due to the stages the call linking goes through, go see the code to  
find out why!)


cheers,
G.





___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] arm jit

[Gavin Barraclough]

On Jun 9, 2009, at 2:38 PM, Akos Kiss wrote:


Dear Community,

Today, we realized that there is a new ARM JIT port for WebKit. (http://trac.webkit.org/changeset/44514 
) Congratulations on getting this working!, great job.


Hi Akos,

Thank you!  Just to clarify, we have just landed a ARMv7 architecture  
(thumb2) JIT backend into ToT.  I say ARMv7 to distinguish this port  
from the ARM application instruction set found in the ARMv6  
architecture and earlier (as I believe would be a common understanding  
of the term ARM, and and which I believe your port targets).  Thumb2  
in ARMv7 is, of course, a very different instruction set to the  
traditional 32-bit instructions found in ARM – with completely  
different machine encodings, and significantly different capabilities  
(e.g. two operand versus three operand instructions, sizes of  
immediate operands, and options for instruction predication).  For the  
JIT to be able to run on both ARM and ARMv7 platforms, it needs to be  
ported to both architectures – in much the same way the the JIT is  
ported to both the x86 and x86-64 platforms.


Obviously there is a great deal of similarity on the surface between  
ARM and ARMv7, but in terms of the JIT implementation that may well  
only be true above the level of the MacroAssembler interface.  There  
may be some limited opportunities to share code within the Assembler  
classes (register numbering enums, and possibly types describing  
immediate operands), but since the assembler is primarily concerned  
with formatting machine instructions, and since the instruction  
encodings are different, it seems likely the bulk of the code will  
have to remain separate.  Again, the differences in instruction  
selection options available on the two architectures will likely make  
it hard to share code within the MacroAssember (different numbers of  
operands to many common instructions, and the options when working  
with large immediate values particularly spring to mind).  We would  
certainly want to share code and avoid any duplication where ever it  
makes sense to do so.


I cannot conceal how disappointed I am, as is the whole team at  
Szeged.


I am very sorry to hear this.  If you look at the patches that landed  
into ToT there were very few changes made outside of the new assembler  
classes which, for the reasons described above, I think are highly  
unlikely to have much in common on the two platforms.  The changes  
that have been made to common code outside of the assemblers should  
only help in removing x86 dependencies and assumptions that had  
existed in the code. I strongly urge you to review the changes that  
have been made, as I hope and believe you will find that they will  
assist the team in integrating your ARM port.


Of course, we've felt that you were reluctant to accept our  
implementation.


We were (and remain) reluctant to accept a duplicate of the JIT into  
the tree, rather than a port of the existing JIT utilizing the  
MacroAssembler abstraction.  We are concerned that it would be  
extremely difficult to continue to maintain such a port as we move the  
JIT technology forwards.  Beyond that, they key barrier to the ARM JIT  
being accepted into WebKit is that there simply haven't been any  
patches put forwards for us to review!  (I'm sorry, I'm aware you have  
provided a link to an external git repository, but I'm afraid we  
really can't seek through version control systems to find changes to  
review – we do need contributors to attach patches to bugs, and we  
need a review flag setting to indicate when the contributor believes  
their patch is ready.  If there is any uncertainty as to the  
procedure, please see http://webkit.org/coding/contributing.html .)


- Are you still looking for patches, bug reports, feature requests,  
etc., or is it all in vain - you will get everything done in house?


Yes!   Please do so, this is only way your changes will get into the  
tree.


- Should we ask for credits in the new files, as it was done by you  
when we first published our JIT implementation? I'm quite sure that  
we can state the same argument: a number of the new files appear to  
have taken large chunks of logic from existing jit files.


The new files were derived from their x86 counterparts, with reference  
to the ARMv7 manuals.  As such the existing copyright notifications  
within the files from which they were derived have been retained.


(Apologies for the slow reply, we have a busy week with WWDC on!)

cheers,
G.




Best regards,
Akos


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] stack alignment bug

[Gavin Barraclough]

Hi Zoltan,

I'm a little confused – maybe I'm misunderstanding you, but the JIT  
does just subtract a fixed amount from the stack pointer on entry (28  
on x86, for a total frame size including return address, caller frame  
pointer and callee preserved registers of 48, a multiple of 16 to  
preserve stack alignment).  All JIT code then runs at the same stack  
depth.  The only pops in the JIT are simply removing the the return  
address implicitly pushed on x86, and the only pushes (bar a function  
call in put property access transition realloc) are restoring the  
return address prior to a return (or a tail call).  It is not clear to  
me what you're envisaging 'fake_sp' would be used for.


I've just landed a patch to move the pushes  pops in wrapper  
functions, and to switch put transition realloc to use a regular  
function call, hopefully this tidies things up a little.


cheers,
G.


On Jun 4, 2009, at 1:19 AM, Zoltan Herczeg wrote:


Hi,

actually there was a bug which took me a day to find out what  
happened. It

was somewhere deep in libc, called by a function in DateMath.cpp. It
seemed that the stack was overwritten. By libc??? I can't belive it.
Finally I realized that gcc's alloca realigned the stack (to 8 bytes  
on

ARM), so everything was in a wrong place (looked overwritten at first
sight).

My fake stack pointer idea:
fake_sp: any non-volatile general purpose register

JIT_entry:
 mov fake_sp, sp
 sub sp, sp, 32   ; I belive this is enough for the JIT,
  ; correct me if I am wrong
 ; use fake_sp instead of sp for push/pops

JIT_leava:
 add sp, sp, 32

I hope this even works for PPC (if someone ever wants to port the  
JIT to

old macs).

Zoltan


Zoltan,
I filed a bug here: https://bugs.webkit.org/show_bug.cgi?id=26164
Stack is originally aligned then jit code destroys it; and, some data
structure or point to double is not aligned and I'm still trying to  
find

where they are.
I'm not sure how the fake stack would be, would you mind explains a  
bit

more?
Did you face same problem?
Thanks also for your articles that gives new ideas.
rgds
joe

--- On Wed, 6/3/09, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote:


From: Zoltan Herczeg zherc...@inf.u-szeged.hu
Subject: Re: [webkit-dev] stack alignment bug
To: x yz last...@yahoo.com
Cc: webkit-dev@lists.webkit.org
Date: Wednesday, June 3, 2009, 7:35 PM
Hi,

true, some architectures have strict policies for stack
handling. Perhaps
the worst one is PowerPC with its organized stack frame
(back chains,
pre-defined register save areas, etc). I think a fake stack
pointer for
JIT can solve the x86 compatibility problem.

1) allocate enough aligned stack space for the worst case
when you enter
to JIT
2) the fake stack pointer should use this pre-allocated
stack frame.

Zoltan


I don't know how to file bug so I posted here.
In privateCompileCTIMachineTrampolines() there are

multiple align() to

align code on 16byte margin, yet, the stack can be put

on 32bit margin

that causes crush.
Suppose original stack is aligned to 8/16bytes, the

above function

frequently pop/push regT3 that makes stack

mis-aligned. Then int to double

conversion uses stack that will fail.
rgds
joe



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] cti_op_call_ArityCheck question

[Gavin Barraclough]

We check in JIT code for cases where arity match, and skip the call to  
the stub; this function is only called if there is a mismatch to be  
resolved.  The function would probably be better named something like  
'cti_op_call_handleArityMismatch'.


cheers,
G.

On Jun 4, 2009, at 1:50 PM, Toshiyasu Morita wrote:


I don't understand this code in JITStubs::cti_op_call_arityCheck():

ASSERT(argCount != newCodeBlock-m_numParameters);

It's ensuring that the argument count does not equal the number of  
parameters expected by the newCodeBlock. I could understand if it  
was ensuring the argCount was the same, but why different?


Toshi

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] stack alignment bug

[Gavin Barraclough]

This code is designed to keep the stack correctly aligned, and appears  
to be working correctly.  If you think there is a bug here, please  
report it at bugs.webkit.org.


cheers,
G.


On Jun 2, 2009, at 5:26 PM, x yz wrote:



I don't know how to file bug so I posted here.
In privateCompileCTIMachineTrampolines() there are multiple align()  
to align code on 16byte margin, yet, the stack can be put on 32bit  
margin that causes crush.
Suppose original stack is aligned to 8/16bytes, the above function  
frequently pop/push regT3 that makes stack mis-aligned. Then int to  
double conversion uses stack that will fail.

rgds
joe



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Webkit JavaScript question

[Gavin Barraclough]

Hi Zoltan,


I don't think so. It is not worth to do it on a desktop pc since
interpreter is always slower than JIT. However, the story is  
different for

embedded systems, when they enter low-memory mode.


Whilst it is certainly true that this would likely be of most benefit  
on embedded platforms, we anticipate mixed-mode to be desirable on the  
desktop too.


In addition to having the potential to providing a more memory  
efficient representation than JIT code (assuming a switch to a more  
compact intermediate code representation – our current bytecode is  
more tuned towards performance then size), this could also be  
beneficial for performance.  As JS application size grows, avoiding  
JIT generation for infrequently executed code (e.g. setup/ 
initialization code can often be run only once) may become more  
important (although right now we not seeing code generation as a  
significant overhead).  Additionally, by running the code through the  
interpreter prior to JIT generation this may give us an opportunity to  
gather information to improve the quality of generated code.



We made some
experiments before, and it seems possible to switch between jit and
interpreter, but I am not sure that the community is interested in  
such

features.


Whilst not something we have prioritized yet, it is definitely an area  
of interest.  If you have an implementation, even in a partially  
complete state, it might be worth filing an enhancement request on the  
bug tracker and attaching a patch.


cheers,
G.



Zoltan


The last step depends on the architecture (supported or not) and C++
compiler directives. If JIT is enabled (see wtf/Platform.h), it  
always
generates machine code. Otherwise an interpreter executes the byte  
code.

A
mixed environment (both jit and interpreter) is not yet supported.


Are there plans for that ? Mozilla's TraceMonkey supports triggering
JIT execution at runtine already, iirc.

--
--Antonio Gomes



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] YARR

[Gavin Barraclough]

On May 19, 2009, at 12:55 PM, Kenneth Christiansen wrote:

Great! I notices that RegExp.h still includes WREC, will that be  
changed?


WREC should  be removed completely fairly soon.  We just wanted to  
leave some overlap with YARR and WREC both in ToT, in case we needed  
to revert back to WREC for any reason.  But right now YARR is looking  
stable, so we should probably finish the move fairly soon.  QT  GTK  
switching over is clearly a great step towards us being able to do  
so. :-)


Right now, if it makes life easier, we could probably switch the  
includes in that file to be:


#if ENABLE(YARR)
#include yarr/RegexJIT.h
#include yarr/RegexInterpreter.h
#else
#include WREC.h
#endif

If it requires the JIT why are there both a ENABLE_YARR and an  
ENABLE_YARR_JIT ?


YARR can be used both in JIT mode, or as an interpreter (the latter  
being enabled just with ENABLE_YARR).


Before YARR, platforms either used just pcre (if they did not support  
any JIT generation), or used WREC for simple regexes, and fell back to  
pcre for more complex ones.  Right now platforms that don't support  
JIT generation still just use pcre, but platforms that do JIT have  
switched to using the YARR JIT, falling back to pcre for cases that  
YARR does not handle (which is fewer than for WREC).


YARR is still work in progress, and the two key things left to do are  
to optimize the YARR interpreter (which is missing some key and  
obvious steps in optimization, and as such is still slower that pcre),  
and to complete the YARR JIT, so it can handle all regular expressions  
(YARR interpreter already has full coverage, we're just missing some  
code generation).


Once these tasks are completed we hope to switch platforms that don't  
support JIT generation over to use YARR interpreter, and that  
platforms that do support JIT generation will just be using YARR JIT  
(with no need to fall back to anything else, since it will have  
complete coverage).


cheers,
G.



Cheers,
Kenneth


On Tue, May 19, 2009 at 9:52 PM, Geoffrey Garen gga...@apple.com  
wrote:

If so, does it work on the same platforms at the JSCore JIT?


What problems are those?


Oops!

platforms

Yes, it works on the same platforms as the JSCore JIT.

Geoff


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs

[Gavin Barraclough]

Maciej,

This sounds good, and sounds like it could clean things up a lot.

In the breakdown below you don't explicitly mention what would happen  
to h/w specific macros like PLATFORM_X86, though you do mention 'CPU'  
in your email, OOI are you thinking something like?:


CPU()
Examples:
CPU(X86)
CPU(X86_64)

cheers,
G.


On Apr 30, 2009, at 4:12 PM, Maciej Stachowiak wrote:



I think our set of porting macros has become somewhat confused.

Originally, our idea was that a port represents primarily adaptation  
to a particular platform. However, over time it has become clear  
that most of what is decided by a port is not platform adaptation,  
but rather policy decisions. For example, ports decide to have  
different features enabled, or to use different sets of system  
functionality on the same underlying OS.


In addition, I think the catchall top-level PLATFORM create  
confusion, because it is not totally clear if they are policy  
decisions, platform adaptation decisions, or what.


Third, it seems wrong that the policy choices of every port are  
represented as a bunch of ifdef tomfoolery inside a single  
Platform.h file.


And fourth, many ports often run on the same OS, but with a  
different set of choices - for example on Mac OS X it is possible to  
build the Mac, Chromium, Gtk, Qt and Wx ports (at least).



Therefore, I propose that we change as follows:

1) Strictly separate platform adaptation (mandatory to run on a  
given OS, compiler, or CPU at all) from policy choices (what  
features to enable, what optional libraries to use).


2) Phase out PLATFORM macros completely - each use should be  
converted to a policy choice, or a platform adaptation decision.


3) Instead of ports being defined by a top-level PLATFORM macro, I  
propose that each port should have its own header file to define  
policy decisions. For example, I'd propose that the system Mac OS X  
WebKit should use PortCocoa.h, and the WebKit used by Safari for  
Windows should use PortWinCG.h. There may also be a PortIPhone.h.  
These port definition headers would live in their own top-level  
WebKit module. Each one would be completely owned by whoever is  
generally considered the owner of a given port. Because related  
ports on different platforms may wish to share policy choices, it's  
ok for Port headers to include shared headers for some choices. For  
example, all Apple-maintained ports may include PortApple.h. We  
could go even further and have PortDefault.h to make default choices  
of what features are enabled, that ports would have to explicitly  
override.


4) Platform adaptation macros would still be defined in Platform.h  
based on sniffing the environment, this would include things like  
the compiler, the underlying OS, available libc functions, and so  
forth.



Platform adaptation macros would be:

OS() - underlying operating system; only to be used for mandated low- 
level services like virtual memory, not to choose a GUI toolkit

   Examples:
   OS(UNIX) - Any Unix-like OS
   OS(DARWIN) - Underlying OS is the base OS X environment
   OS(FREEBSD) - FreeBSD
   OS(WIN) - Any version of Windows
   OS(WINCE) - The embedded version of Windows

COMPILER() - the compiler being used to build the project
   Examples:
   COMPILER(GCC) - GNU Compiler Collection
   COMPILER(MSVC) - Microsoft Visual C++
   COMPILER(RVCT) - ARM compiler

HAVE() - specific system features (headers, functions or similar)  
that are present or not

   Examples:
   HAVE(MMAP) - mmap() function is available
   HAVE(ERRNO_H) - errno.h header is available
   HAVE(MADV_FREE) - madvise(MADV_FREE) is available


Policy decision macros would be:

USE() - use a particular third-party library or optional OS service
   Examples:
   USE(SKIA) - Use the Skia graphics library
   USE(CG) - Use CoreGraphics
   USE(V8) - Use the V8 JavaScript implementation
   USE(CFNET) - Use CFNetwork networking
   USE(NSURL_NET) - Use NSURLConnection-based networking
   USE(APPKIT) - Use AppKit views and events
   USE(GTK) - Use Gtk+
   USE(QT) - Use Qt
   USE(QUICKTIME) - Use the QuickTime media engine
   USE(QTKIT) - Use the QuickTime media engine via the Mac QTKit  
API
   USE(QUICKTIME_WIN) - Use the QuickTime media engine via its  
Windows API


ENABLE() - turn on a specific feature of WebKit
   Examples:
  ENABLE(ACCESSIBILITY) - Enable support for assistive  
technologies (currently wrongly a HAVE)

  ENABLE(XSLT) - Include XSLT support
  ENABLE(OBJC_MAC_API) - Include Objective C API based on  
NSViews (current WebKit Mac)
  ENABLE(OBJC_DOM_API) - Include Objective C DOM bindings (may  
apply to other ObjC toolkits than AppKit)
  ENABLE(JSC) - Enable use of the JavaScriptCore implementation  
(inconsistent with V8 because JSC is a WebKit feature but V8 is an  
external dependency, even though they serve similar purposes)

   

Re: [webkit-dev] x86-64 JIT

[Gavin Barraclough]

On Mar 18, 2009, at 11:06 AM, Mike Hommey wrote:

An earlier call to JSC::JITStubs::cti_op_call_NotJSFunction works  
and a lot
of other stub functions are called before the crash, so it means  
most of

the JIT works, but it is failing in a subtle way.


I'd suggest trying to produce a reduction of the test case your  
looking at – JIT crashers can usually be reduced down to a very small  
test case.  You may then want to step though the JIT code to see where  
the bogus value is coming from.  Adding calls to breakpoint() from  
JIT::privateCompile and JIT::privateCompileMainPass can help with  
this, inserting breakpoints into the JIT code that the debugger will  
then hit.


cheers,
G.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] want to port JIT to MIPS - can anybody explain JIT::linkCall?

[Gavin Barraclough]

The hot path for a call performs a check for a specific callee, with a  
fast mechanism for making JS-JS calls.  The code is generated such  
that it will initially always bail out to the slow path, and the  
second time the call is executed it will dynamically linked itself to  
that callee.  There are currently two slow paths generated for each  
callee, the initial one that calls out to relink the code, and a  
second form that does not.  hotPathBegin  hotPathOther are used  
(along with an offset) to find three things to repatch in the hot path:


(1) The JSFunction* value that is checked, to identify the callee
(2) The jump out to the slow path, so this can be relinked to the  
second form (which will not attempt to relink – this is stored in  
coldPathOther).

(3) The call instruction to be linked the callee's code.

The value callReturnLocation points to the call in the cold path to  
the relink mechanisms.  This is used by the dynamic linking mechanisms  
to lookup the CallLinkInfo record describing the call to be linked,  
and is also used in exception handling.


G.

On Mar 6, 2009, at 5:40 PM, x yz wrote:



e.g, emitted asm code before/after patch? what does its four  
pointers do?

MacroAssembler::CodeLocationNearCall callReturnLocation;
MacroAssembler::CodeLocationDataLabelPtr hotPathBegin;
MacroAssembler::CodeLocationNearCall hotPathOther;
MacroAssembler::CodeLocationLabel coldPathOther;
CodeBlock* callee;

anywhere got doc of the JIT implementations?
thanks a lot!
joe


--- On Wed, 3/4/09, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote:


From: Zoltan Herczeg zherc...@inf.u-szeged.hu
Subject: Re: [webkit-dev] want to port JIT to MIPS - how  
patchOffset* constant determined?

To: webkit-dev@lists.webkit.org
Date: Wednesday, March 4, 2009, 3:33 PM
Hi,

they generate instructions, which size is known in advance.

Think about the following sequence:
hotPathBegin:
 mov regX, 32bit_const - 6 bytes (*) (**)
 add regX, regY - 2 bytes
 jo 32bit_addr - 5 bytes (*)

* (Note) : these instructions will be modified during
runtime.

** (Note) : there is a short form for mov regX,
8bit_const, which length
is only 3 bytes, but they force the longer version in such
cases to keep
the size of the instruction.

As you can see, the address of jo is always
(hotPathBegin + 6 + 2). They
simply introduce a new constant: patchOffsetXXX = 8, and
use this constant
to access the jo instruction later.

In ARM we can't rely on such constant, because the
constant pool can be
placed after any instruction.

hotPathBegin:
 ldr rX, [pc + const_pool_addr] ; 32 bit const
 [...] - the const pool can be placed here
 add rX, rX, rY
 [...] - the const pool can be placed here
hotPath2:
 ldr pc, [pc + const_pool_addr] ; 32 bit target address

We need to store both pointers (hotPathBegin and hotPath2).

Zoltan


Zoltan,
Thanks for reply, I'm trying to understand your

example. But,X86

instruction size is from 1 to 17bytes, not constant. I

may misunderstand

your comments?
Many X86 instruction can have imm32 at the end, thus

this pointer can be

used for patch as well as next address after call.

Does Arm have similar

things? or else you still need to figure out why
patchOffsetOpCallCompareToJump = 9;? may

be some instruction lengths

relates to the 9?
rgds
joe


--- On Wed, 3/4/09, Zoltan Herczeg

zherc...@inf.u-szeged.hu wrote:



From: Zoltan Herczeg

zherc...@inf.u-szeged.hu

Subject: Re: [webkit-dev] want to port JIT to MIPS

- how patchOffset*

constant determined?
To: webkit-dev@lists.webkit.org
Date: Wednesday, March 4, 2009, 3:45 AM
On x86, the size of the instructions are fixed. If

you want

to access
multiple instructions in the instruction stream,

you only

need to store
the address of the first one, and can access the

others by

their relative
address. This saves a little memory.

Example (see JIT::linkCall):
 instruction at callLinkInfo-hotPathBegin:

points to

callee comparison
 instruction at
   callLinkInfo-hotPathBegin +
patchOffsetOpCallCompareToJump:
  points to the slow case entry jump

Zoltan


in jit.h, for example:
   static const int

patchOffsetOpCallCompareToJump = 9;

   static const int

patchOffsetPutByIdStructure =

7;

   static const int

patchOffsetPutByIdPropertyMapOffset = 22;

   static const int

patchOffsetGetByIdBranchToSlowCase = 13;

thanks for help, I'm stucked here now.
joe


--- On Sat, 2/28/09, Gavin Barraclough

barraclo...@apple.com wrote:



From: Gavin Barraclough

barraclo...@apple.com

Subject: Re: [webkit-dev] want to port

JIT to MIPS

- JIT reg usage clean

up?
To: WebKit Development

webkit-dev@lists.webkit.org

Date: Saturday, February 28, 2009, 12:19

PM

On Feb 27, 2009, at 4:55 PM, x yz wrote:


The regTx seems to be working

registers here,

yet

their definition are regparm(3) registers

for

function

arugments. Such usage would cause

conflict on

other

platforms. May I suggest that we use

individual

defined set

of regs for func i/o

Re: [webkit-dev] want to port JIT to MIPS - JIT reg usage clean up?

[Gavin Barraclough]

On Feb 27, 2009, at 4:55 PM, x yz wrote:

The regTx seems to be working registers here, yet their definition  
are regparm(3) registers for function arugments. Such usage would  
cause conflict on other platforms. May I suggest that we use  
individual defined set of regs for func i/o argument and working?


First up, I think you're getting slightly confused about regparm(3).   
This is not used anywhere in the JS language JIT, only in WREC.  In  
some configurations of the JIT we use fastcall semantics on x86... but  
none of this is really relevant to MIPS.  Just ignore all this.  Stick  
to the default MIPS ABI for stub functions.


Reading between the lines, I'm guessing your concern here is that in  
setting up arguments for a JIT stub call you may trample the JIT's  
temporary registers?  If so, I think you need to look at the argument  
passing more closely.  The mechanisms to pass arguments to stub  
functions pass all arguments in memory – typically passing a single  
pointer to the stub functions, which can be used to retrieve the  
arguments.  This pointer argument can be set up immediately prior to  
the call, so it does not interfere with the regT? temporaries.  We  
follow this pattern on x86-64, where the ABI is typically to pass  
arguments in registers.  You cannot trivially change the way this  
works, since the argument pointer is used for other purposes too (e.g.  
retrieving the arguments passed into the JIT code from within the  
stubs).


We strongly prefer small, simple, incremental changes.  A patch that  
tried to both port the JIT to a new platform and to introduce a new  
argument passing interface to the JIT stub functions sounds unlikely  
to get anywhere (a patch porting the JIT to a new platform is on its  
own very likely to be too much more than we'd want to land in one  
chunk).  I'd suggest that a port would be wise to engineer it's  
initial solution to fit one of the existing argument passing  
mechanisms (these are selected by JIT_STUB_ARGUMENT_* switches, to  
help find the relevant code).  (Alternatively, you're welcome to  
attempt to port x86-64 to make use of an in-register argument passing  
solution, which could be hugely useful.  With this landed first and  
separately, a port could then build on top of this.)


As a more direct answer to your question, you could endeavour to make  
the set of hardware registers used as JIT temporaries non-overlapping  
with ABI function argument registers on MIPS, but this is unlikely to  
be a general solution to anything for all platforms, due to limited  
register availability on some architectures.


we would put all these definition in a file named regMap.h, then we  
can remove all X86:: from other JIT files.


I don't think we'll be keen on taking preemptive changes so far ahead  
in preparation of a port.  The first logical step in porting to a new  
platform is still to start with WREC, and this requires no changes in  
the JIT directory.  Any refactoring of the existing JIT would make  
more sense more directly prior to work in that area.


cheers,
G.



I'd apperciate if sb can do it or help me to do it.
rgds
joe




--- On Sat, 2/28/09, x yz last...@yahoo.com wrote:


From: x yz last...@yahoo.com
Subject: Re: [webkit-dev] want to port JIT to MIPS - which calling  
convention is used here?
To: webkit-dev@lists.webkit.org, Zoltan Herczeg zherc...@inf.u-szeged.hu 


Date: Saturday, February 28, 2009, 7:40 AM
Hi,
Thanks for your help in advance:)
in JITPropertyAccess.cpp:
   if (transitionWillNeedStorageRealloc(oldStructure,
newStructure)) {
   pop(X86::ebx);  ///pop return address, why? for
exception?
#if PLATFORM(X86_64)///which convention is this?

move(Imm32(newStructure-propertyStorageCapacity()),
regT1);  //edx

move(Imm32(oldStructure-propertyStorageCapacity()),
X86::esi);
   move(regT0, X86::edi);
   callTarget = call();
#else   ///__cdecl, yet how can I know
resizePropertyStorage() use __cdecl?

push(Imm32(newStructure-propertyStorageCapacity()));

push(Imm32(oldStructure-propertyStorageCapacity()));
   push(regT0);
   callTarget = call();
   addPtr(Imm32(3 * sizeof(void*)), X86::esp);
///clean stack
#endif







___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] want to port JIT to MIPS - how to get of SSE2 now?

[Gavin Barraclough]

SSE2 code generation is guarded by calls to a function  
'isSSE2Present()'.


On Feb 26, 2009, at 12:27 PM, x yz wrote:



Hi,
Old version seems use ENABLE_JIT_OPTIMIZE_ARITHMETIC to enable sse2  
and only for X86_64, current version changes conf to:
1. you must ENABLE_JIT_OPTIMIZE_ARITHMETIC or else you use  
interpreter for arithmatic.

2. if ALTERNATE_JSIMMEDIATE not enabled you must have sse2 engine
3. if ALTERNATE_JSIMMEDIATE enabled, you use mmx arithematic, but  
ALTERNATE_JSIMMEDIATE is enabled in paltform.h only for X86_64   
MAC. That means on X86 you need sse2???

thanks for your time!
joe



--- On Sun, 2/22/09, x yz last...@yahoo.com wrote:


From: x yz last...@yahoo.com
Subject: Re: [webkit-dev] want to port JIT to MIPS
To: WebKit Development webkit-dev@lists.webkit.org, Gavin  
Barraclough barraclo...@apple.com

Date: Sunday, February 22, 2009, 4:34 PM
Thanks a lot otherwise I have misunderstanding. Yes I'll
do wrec first. I just want to clean up possible blocking
issues.

I see wrec uses regparm(3) and jit always use fastcall for
X86?
In JIT.cpp ctiTrampoline put CallFrame in edi, but how
about other arguments - where are they be fetched/poped from
stack?

when deal with caller/callee saved regs, gcc MIPS just
preserves them when necesasary. The problem is after JIT
used gcc may not have enough knowledge on
necessary, do we have a way to force gcc always
preserve
them?

how to identify a patch (patchimm/patchptr/patchaddr)
relates to a data field in an instruction or relates to an
element in a data array? In Mips the former means the 32bit
needs to be separated into two 16bits and patched into two
instructions. But if a 32bit is a pointer in a pointer
array, we can save it directly.

rgds
joe


--- On Fri, 2/20/09, Gavin Barraclough
barraclo...@apple.com wrote:


From: Gavin Barraclough barraclo...@apple.com
Subject: Re: [webkit-dev] want to port JIT to MIPS
To: WebKit Development

webkit-dev@lists.webkit.org

Date: Friday, February 20, 2009, 2:01 PM
On Feb 19, 2009, at 8:27 PM, x yz wrote:


I'd appreaciate your help to clarify the

problem I

faced:


1.In JIT.cpp I roughly understand ctiTrampoline()

except for sp-0x1C, I guess the 1C includes 6 argument

yet

the 7th or 1st may be the hidden C++ pointer? And the
reserved 1C stack space seems not used? why esi is

forced to

be 512 rather than use input argument?

The JIT allocates a fixed frame on the stack which is

used

to pass arguments into stub functions.  The 0x1C

contains a

spare word or two to maintain stack alignment.  %esi

is used

in the timeout check mechanism.


2.How to understand the stack balance in

ctiVMThrowTrampoline()? why after calling we still add

1C

w/o sub 1C before calling? where comes
_ZN3JSC11Interpreter12cti_vm_throwEPPv and how do I

know

which name for Mips? does this one relates to variable
argument function call?

ctiVMThrowTrampoline is never called as a function (it

is

declared as a function only to provide a symbol that

can be

manipulated from C code).  ctiVMThrowTrampoline is

used in

returning back from JIT generated code, in the case of

an

exception.


3.I know how to handle jump in Mips, but not sure

how/when to handle patchAddress/patchImm/patchPointer
because I'm not sure the instructions related. I

guess

all patches are for last 32bit IMM field of

instructions.

Mips can't load 32bit in one instruction,

thus I

need to know the instruction before I can patch/add in

the

32bit data.


4.I'm kind of want no asm code outside

assembler folder, any plan for that?

No.  The assembler is intended to be independent of
JavaScript types - it's just an assembler.  The

asm

trampolines are specific to the JIT.  It is currently

the

intention that architecture specific parts of the JIT
implementation will remain in the jit folder.

I'd suggest that in attempting to port the jit,

WREC

would be a good place to start.

cheers,
G.



rgds
joe

--- On Mon, 2/16/09, x yz

last...@yahoo.com

wrote:



From: x yz last...@yahoo.com
Subject: Re: [webkit-dev] want to port JIT to

MIPS

- when WREC/JIT enabled?

To: Gavin Barraclough

barraclo...@apple.com

Cc: WebKit Development

webkit-dev@lists.webkit.org

Date: Monday, February 16, 2009, 5:25 AM
Hi,
from paltform.h it is enabled only on X86

MAC/WIN;

from

javaScriptCore.pri it is also enabled for

(QT_ARCH,i386).

But, from config.log I see them are enabled!

how can I run WREC/JIT test so I can trace in

X86

asm coce

generated?
thanks a lot.
joe



--- On Sat, 2/7/09, Gavin Barraclough
barraclo...@apple.com wrote:


From: Gavin Barraclough

barraclo...@apple.com

Subject: Re: [webkit-dev] want to port

JIT to

MIPS -

using X86::ecx as base

To: last...@yahoo.com
Cc: WebKit Development

webkit-dev@lists.webkit.org

Date: Saturday, February 7, 2009, 7:08 AM
On Feb 6, 2009, at 2:52 PM, x yz wrote:


1.what's the meaning of

ALTERNATE_JSIMMEDIATE

and

slow case?

On x86-64 we use a different

implementation of

the

class

JSImmediate

Re: [webkit-dev] want to port JIT to MIPS - how to get of SSE2 now?

[Gavin Barraclough]

ALTERNATE_JSIMMEDIATE is only supported on 64-bit, and all 64-bit  
x86's have SSE2 – so the ALTERNATE_JSIMMEDIATE code is assuming that  
SSE2 is present.  If we wanted to make ALTERNATE_JSIMMEDIATE being  
enabled on 32-bit x86 possible, then we would also need to check  
isSSE2Present() here.


To address the problem at a slightly higher level,  
ENABLE_JIT_OPTIMIZE_ARITHMETIC is intended to guard JIT generation of  
double precision floating point math.  In the long run we will  
potentially place double precision operations within the domain of the  
MacroAssembler interface, but this is unlikely to happen before the  
JIT is ported to another platform that feature a 64-bit register file  
based FPU (which will help drive ensuring that we get the interface  
right).


I would suggest that ENABLE_JIT_OPTIMIZE_ARITHMETIC is not something  
interesting to worry about at this stage.  It only affects a couple of  
functions, and shouldn't have any wider ramifications on design  
decisions – a sensible approach in porting the JIT is to switch the  
three optimizations switches off and then not thinking about them  
until after the ported JIT is up and running.  (In fact, that is  
exactly why these three switches exist – to make it possible to port  
the JIT without worrying about some of the hairier bits of code  
generation.  These compile switches were added when we ported the JIT  
to x86-64.  Only once the JIT was up and running did we switch them on  
one by one).


cheers,
G.


On Feb 26, 2009, at 5:39 PM, x yz wrote:



yes but if isSSE2Present() returns false the code becomes very  
simple so I doubt it may be slow.

what's the benefit to enable/disable ALTERNATE_JSIMMEDIATE?
thanks
joe



--- On Fri, 2/27/09, Gavin Barraclough barraclo...@apple.com wrote:


From: Gavin Barraclough barraclo...@apple.com
Subject: Re: [webkit-dev] want to port JIT to MIPS - how to get of  
SSE2 now?

To: WebKit Development webkit-dev@lists.webkit.org
Date: Friday, February 27, 2009, 6:03 AM
SSE2 code generation is guarded by calls to a function
'isSSE2Present()'.

On Feb 26, 2009, at 12:27 PM, x yz wrote:



Hi,
Old version seems use ENABLE_JIT_OPTIMIZE_ARITHMETIC

to enable sse2

and only for X86_64, current version changes conf to:
1. you must ENABLE_JIT_OPTIMIZE_ARITHMETIC or else you

use

interpreter for arithmatic.
2. if ALTERNATE_JSIMMEDIATE not enabled you must have

sse2 engine

3. if ALTERNATE_JSIMMEDIATE enabled, you use mmx

arithematic, but

ALTERNATE_JSIMMEDIATE is enabled in paltform.h only

for X86_64 

MAC. That means on X86 you need sse2???
thanks for your time!
joe



--- On Sun, 2/22/09, x yz last...@yahoo.com

wrote:



From: x yz last...@yahoo.com
Subject: Re: [webkit-dev] want to port JIT to MIPS
To: WebKit Development

webkit-dev@lists.webkit.org, Gavin

Barraclough barraclo...@apple.com
Date: Sunday, February 22, 2009, 4:34 PM
Thanks a lot otherwise I have misunderstanding.

Yes I'll

do wrec first. I just want to clean up possible

blocking

issues.

I see wrec uses regparm(3) and jit always use

fastcall for

X86?
In JIT.cpp ctiTrampoline put CallFrame in edi, but

how

about other arguments - where are they be

fetched/poped from

stack?

when deal with caller/callee saved regs, gcc MIPS

just

preserves them when necesasary. The problem is

after JIT

used gcc may not have enough knowledge on
necessary, do we have a way to force

gcc always

preserve
them?

how to identify a patch

(patchimm/patchptr/patchaddr)

relates to a data field in an instruction or

relates to an

element in a data array? In Mips the former means

the 32bit

needs to be separated into two 16bits and patched

into two

instructions. But if a 32bit is a pointer in a

pointer

array, we can save it directly.

rgds
joe


--- On Fri, 2/20/09, Gavin Barraclough
barraclo...@apple.com wrote:


From: Gavin Barraclough

barraclo...@apple.com

Subject: Re: [webkit-dev] want to port JIT to

MIPS

To: WebKit Development

webkit-dev@lists.webkit.org

Date: Friday, February 20, 2009, 2:01 PM
On Feb 19, 2009, at 8:27 PM, x yz wrote:


I'd appreaciate your help to clarify

the

problem I

faced:


1.In JIT.cpp I roughly understand

ctiTrampoline()

except for sp-0x1C, I guess the 1C includes 6

argument

yet

the 7th or 1st may be the hidden C++ pointer?

And the

reserved 1C stack space seems not used? why

esi is

forced to

be 512 rather than use input argument?

The JIT allocates a fixed frame on the stack

which is

used

to pass arguments into stub functions.  The

0x1C

contains a

spare word or two to maintain stack alignment.

%esi

is used

in the timeout check mechanism.


2.How to understand the stack balance in

ctiVMThrowTrampoline()? why after calling we

still add

1C

w/o sub 1C before calling? where comes
_ZN3JSC11Interpreter12cti_vm_throwEPPv and how

do I

know

which name for Mips? does this one relates to

variable

argument function call?

ctiVMThrowTrampoline is never called as a

function

Re: [webkit-dev] want to port JIT to MIPS

[Gavin Barraclough]

On Feb 19, 2009, at 8:27 PM, x yz wrote:


I'd appreaciate your help to clarify the problem I faced:

1.In JIT.cpp I roughly understand ctiTrampoline() except for  
sp-0x1C, I guess the 1C includes 6 argument yet the 7th or 1st may  
be the hidden C++ pointer? And the reserved 1C stack space seems not  
used? why esi is forced to be 512 rather than use input argument?


The JIT allocates a fixed frame on the stack which is used to pass  
arguments into stub functions.  The 0x1C contains a spare word or two  
to maintain stack alignment.  %esi is used in the timeout check  
mechanism.


2.How to understand the stack balance in ctiVMThrowTrampoline()? why  
after calling we still add 1C w/o sub 1C before calling? where comes  
_ZN3JSC11Interpreter12cti_vm_throwEPPv and how do I know which name  
for Mips? does this one relates to variable argument function call?


ctiVMThrowTrampoline is never called as a function (it is declared as  
a function only to provide a symbol that can be manipulated from C  
code).  ctiVMThrowTrampoline is used in returning back from JIT  
generated code, in the case of an exception.


3.I know how to handle jump in Mips, but not sure how/when to handle  
patchAddress/patchImm/patchPointer because I'm not sure the  
instructions related. I guess all patches are for last 32bit IMM  
field of instructions.
Mips can't load 32bit in one instruction, thus I need to know the  
instruction before I can patch/add in the 32bit data.


4.I'm kind of want no asm code outside assembler folder, any plan  
for that?


No.  The assembler is intended to be independent of JavaScript types -  
it's just an assembler.  The asm trampolines are specific to the JIT.   
It is currently the intention that architecture specific parts of the  
JIT implementation will remain in the jit folder.


I'd suggest that in attempting to port the jit, WREC would be a good  
place to start.


cheers,
G.



rgds
joe

--- On Mon, 2/16/09, x yz last...@yahoo.com wrote:


From: x yz last...@yahoo.com
Subject: Re: [webkit-dev] want to port JIT to MIPS - when WREC/JIT  
enabled?

To: Gavin Barraclough barraclo...@apple.com
Cc: WebKit Development webkit-dev@lists.webkit.org
Date: Monday, February 16, 2009, 5:25 AM
Hi,
from paltform.h it is enabled only on X86 MAC/WIN; from
javaScriptCore.pri it is also enabled for (QT_ARCH,i386).
But, from config.log I see them are enabled!

how can I run WREC/JIT test so I can trace in X86 asm coce
generated?
thanks a lot.
joe



--- On Sat, 2/7/09, Gavin Barraclough
barraclo...@apple.com wrote:


From: Gavin Barraclough barraclo...@apple.com
Subject: Re: [webkit-dev] want to port JIT to MIPS -

using X86::ecx as base

To: last...@yahoo.com
Cc: WebKit Development

webkit-dev@lists.webkit.org

Date: Saturday, February 7, 2009, 7:08 AM
On Feb 6, 2009, at 2:52 PM, x yz wrote:


1.what's the meaning of ALTERNATE_JSIMMEDIATE

and

slow case?

On x86-64 we use a different implementation of the

class

JSImmediate.  See JSImmediate.h.
Re 'slow case', in the JIT code generation is
performed as two passes over the bytecode – see
JIT::privateCompileMainPass and
JIT::privateCompileSlowCases.


2.how come the following code can use ECX as base

register?

load32(Address(X86::ecx, FIELD_OFFSET(Structure,

m_typeInfo.m_flags)), X86::ecx);

if the X86::ecx just means its value 1 in ModR/M,

does

it means [BX+DI]?

I think you're looking at the old 16-bit

addressing

mode tables; 32/64-bit x86 can happily encode ecx as a

base

register.  If you're looking at the Intel IA-32

manual

volume 2, see table 2-2 on the next page.


3. can anybody help me on my previous questions?

does

JIT support floating point?

Yes, some.  See JITArithmetic.cpp.

cheers,
G.




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev






___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] want to port JIT to MIPS - using X86::ecx as base

[Gavin Barraclough]

On Feb 6, 2009, at 2:52 PM, x yz wrote:


1.what's the meaning of ALTERNATE_JSIMMEDIATE and slow case?


On x86-64 we use a different implementation of the class JSImmediate.   
See JSImmediate.h.
Re 'slow case', in the JIT code generation is performed as two passes  
over the bytecode – see JIT::privateCompileMainPass and  
JIT::privateCompileSlowCases.



2.how come the following code can use ECX as base register?
load32(Address(X86::ecx, FIELD_OFFSET(Structure,  
m_typeInfo.m_flags)), X86::ecx);
if the X86::ecx just means its value 1 in ModR/M, does it means [BX 
+DI]?


I think you're looking at the old 16-bit addressing mode tables; 32/64- 
bit x86 can happily encode ecx as a base register.  If you're looking  
at the Intel IA-32 manual volume 2, see table 2-2 on the next page.


3. can anybody help me on my previous questions? does JIT support  
floating point?


Yes, some.  See JITArithmetic.cpp.

 cheers,
G.


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] want to port JIT to MIPS, any coworker or any hint?

[Gavin Barraclough]

On Jan 24, 2009, at 8:36 PM, x yz wrote:

Just build webkit on XP using cgywin, not tested yet. I want to port  
to 32bit MIPS, it seems I need to touch JIT and rewrite assembler  
folder.


Once you have the bytecode interpreter up and running on MIPS, I'd  
recommend starting by just trying to port WREC (the regular expression  
JIT).  This is a good starting point because it utilizes a smaller  
subset of the MacroAssembler interface, and has a much simpler  
interface to C code (JIT code is called with C calling conventions,  
and no callbacks are made into C from the JIT generated code).


Any document there on javascripcore/assembler? I also want a smart  
way to make sure output is correct.


A very simple way to validate you are generating the correct code is  
to simply force the JIT to insert a breakpoint (i.e. use  
MacroAssembler::breakpoint()) at the head of the function you are  
generating, then run jsc under a debugger, and when it hits the  
breakpoint simply disassemble the code in memory at the point it has  
stopped.  Now you can visually inspect that it it has generated the  
code you were expecting.


Good luck!
G.







___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SquirrelFish Extreme for non x-86 platforms

[Gavin Barraclough]

On Dec 25, 2008, at 3:51 AM, Oliver Hunt wrote:


You can manually align the memory, eg.
char* memory = malloc(size + alignment - 1);
memory += alignment;
memory = ~(alignment - 1)
return memory;


Oops, think you meant:
memory += (alignment - 1);
G.


The obvious problem with this is that you can't directly free the  
result as it will not necessarily represent the start of the  
allocation, but there are mechanisms for working around that  
(storing the initial allocation address inline in the allocation  
itself for instance) but there are various trade offs involved.


--Oliver

On Dec 25, 2008, at 3:14 AM, Javed Rabbani wrote:


Oliver,

Thanks a great deal for this explanation. I am considering running  
JS SquirrelFish extreme engine on an ARM-based embedded platform.  
You are right that posix systems should provide mmap or  
posix_memalign that will serve the purpose. I am concerned about  
this issue because in my case, there is no mmap, vm_map etc. to do  
the job. The only available option is to use standard memory  
allocation routines. What is the way out for me to deal with such a  
situation? Obviously, standard malloc() call from within  
fastMalloc() is not doing anything good for me.



Regards,
J R Shah


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev