- squirrelfish-dev - lists.macosforge.org

Building Squirrelfish with Visual Studio 2005
by dipak kumar 12 Jan '11

12 Jan '11

Dear Sir, I have built the JavaScriptCore.dll using Cygwin. Now I am trying to build my browser application which uses this dll and lib using Visual Studio 2005. I am getting number of errors. Following errors occur in most of the file repeatedly : 1. javascriptcore\runtime\jswrapperobject.h(45) : error C2027: use of undefined type 'JSC::JSObject' 2. javascriptcore\runtime\jswrapperobject.h(31) : error C2504: 'JSC::JSObject' : base class undefined 3. javascriptcore\jit\executableallocator.h(77) : error C2589: '(' : illegal token on right side of '::' 4. javascriptcore\runtime\dateinstancecache.h(49) : error C2079: 'JSC::DateInstanceData::m_cachedGregorianDateTime' uses undefined struct 'JSC::GregorianDateTime' For the first error, I have found that it's a known issue with Visual Studio (Ref : http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/02aaef70-8a92-… ). I have following queries: 1. Can we build Squirrelfish files using visual studio 2005? 2. If yes, Please provide us with steps (links). We urgently need these clarification to go ahead for our project work. Awaiting Reply. Thanks and Regards, Dipak Kumar

1 0

New entry
by Tarun Sharma 04 Jan '11

04 Jan '11

Hi , I have just subscribed for the Squirrelfish-dev .Hope to learn a lot as i gp through the squirrelfish code and understandsvarious aspects of the code. -- Regards Tarun Sharma

1 0

Parent Problem
by mohit kingra 28 Oct '10

28 Oct '10

Dear all, Below is the problem i'm stuck at in a Project. Your browser must support javascript. The scope of the problem: - It is related to the interfacing of browser core and Squirrelfish JS Engine via exposed C interfaces by use of JSClassDefinition. Problem Statement: As per our understanding for every DOM document (HTMLPage with JS), we create context and register the DOM objects in engine and at runtime we set or retrieve or process an event via callback mechanism. The problem arises when we try to communicate between the DOM Objects in two different contexts. To explain it further, we have the following html page: <html> <head> <script> function showAlert(){“I am able to call parent function as well!!!!”); </script></head> <body> <iframe src=”frmsrc.html”> </body> </html> The content of the frmsrc.html is given below: - <html> <head> <script> function child() {alert(“I am able to call child function”);} </script> </head> <script> child(); parent.showAlert(); </script> </html> In ideal case in any browser, it should display both the alert messages. In our case, we are getting the alert message in the frmsrc.html i.e: “I am able to call child function”. But when it is trying to access the showAlert() in the parent html it is not accessible. Basically it is not able to access the non standard (user defined) properties/functions of DOM objects in different contexts. Our understanding: Whenever we encounter a page we create a context and initialize Window Object using Squirrelfish APIs. We are not very clear what to be done for the previous context while creating the new context for the new page. We have the browser core code in C so we are forced to use the callback mechanism to interact with Squirrelfish Engine. (i.e; - registering all attributes and functions for the Object during context creation while initializing the Window Class and then getting callback at run time). We are not sure what is do be done for communication of DOM objects across contexts. Best Regards, Mohit Kingra Loading... 1 Ctrl+FSearch the document F3Find next Shift+F3Find previous Edit online Download original Save in Google Docs Ctrl+PPrint (PDF) Zoom in Zoom out Fit page to screen Fit two pages to screen Shift+Ctrl+FCompact controls Plain HTML

2 9

Ever considered inlining 'hot' functions?
by Holger Freyther 21 Sep '10

21 Sep '10

Hi all, I might be completely wrong, my understanding of our JIT or JIT in general might be flawed as well. I have been reading some papers on SELF93s type based optimizations and related papers and started to wonder. >From my understanding our JIT is generating code on the method level (a whole method), did you ever consider inlining small functions? E.g. where the number of bytecode is < 2 * the size of an activation record? is that already done? was it tried? does it make sense? z.

3 6

Re: [squirrelfish] Generating bytecode documentation from Interpreter.cpp
by Maciej Stachowiak 21 Sep '10

21 Sep '10

On Sep 21, 2010, at 11:22 AM, Holger Freyther wrote: > On 09/22/2010 01:38 AM, Maciej Stachowiak wrote: > >>> comments? >> >> The docs actually are generated from Interpreter.cpp, from the doc comments on each case statement. It just hasn't been updated in a while. Also the following opcodes lack documentation: > > Could you help me to find that script? I can help with describing the semantic > of these opcodes. This rule from DerivedSources.make is supposed to regenerate it: docs/bytecode.html: make-bytecode-docs.pl Interpreter.cpp perl $^ $@ The script is at docs/make-butecode-docs.pl Regards, Maciej

1 0

Re: [squirrelfish] Ever considered inlining 'hot' functions?
by Oliver Hunt 21 Sep '10

21 Sep '10

arguments is a live reference to the arguments on the call stack, so function f(a) { g(); alert([a, arguments[0]]) } function g() { f.arguments[0] = "foo"; } f("bar"); will produce foo, foo Isn't ES a marvelous language? :D caller and callee aren't writable though. --Oliver On Sep 21, 2010, at 11:37 AM, Holger Freyther wrote: > On 09/22/2010 02:09 AM, Oliver Hunt wrote: > >> >> In the general case this would require being able to convert from inlined code to a 'correct' call stack at some arbitrary point > > argh, I had hoped that such things would be only necessary when we have a > debugger attached. This mean besides what maciej had said, we will need to > remember that this range of instructions belongs to a inlined call and be able > to generate the virtual call record. > > Can one write to arguments, callee and such? > > I wonder (and will try to measure based on sunspider and other test content) > how many functions occur like function f(x) { return x +2; } or even fully > constant. Is there any classification of the complexity of functions at parse > time?

1 0

Generating bytecode documentation from Interpreter.cpp
by Holger Freyther 21 Sep '10

21 Sep '10

Hi all, it seems that squirrelfish-bytecode.html is out of sync with the reality again. A simple grep on the DEFINE_OPCODE (and removing some) shows that we have about 136 opcodes, searching for "<h2><code>" in the HTML only reveals 78 documented opcodes. I have tried to find a missing one (to support my hypothesis) and "op_eq_null" seems to be among the undocumented ones. Is there any interest to generate the documentation from the switch/case of the Interpreter.cpp? I think I could come up with a small python script to do that. comments?

2 2

limiing JSC memory consumpion
by Zoltan Herczeg 04 Aug '10

04 Aug '10

Hi, I saw a lot of paches about changing the memory allocation behaviour of JavaScriptCore, and would like to start a discussion about the long term purpose of these changes. If I understand corectly, the aim is to limit the memory consumption of JavaScripCore to a certain level, and keep the browser alive when a bad code tries to allocate a huge memory area and the browser forced to crash (is it?). In practice we could build a sandbox around JavaScriptCore (maybe one for each page) and keep every allocation there isn'it? This pobably mmap-ed region could be used by ExecutableAllocator, GarbageCollector, and by other regular allocations. I also saw a patch about moving garbage collector, that is also an interesting area. Regards, Zoltan

2 3

Coalescing slow cases to improve JIT memory usage.
by Nathan Lawrence 26 Jun '10

26 Jun '10

The size of our JIT generated code is a memory known issue. According to Oliver the slow cases for some of our operations is on the order of 128 bytes. It occurred to me that we could reduce the JITed code by only compiling the slow case once and having all of the subsequent generated code jump to that specific slow case. The issue with this is our slow cases jump back to specific locations in the hot path, with potentially different values on the stack, as opposed to a normal function which returns back to a very specific state. We can circumvent this issue by hand writing the assembly to return to an offset of the return address with the required state. What do people think? -- Nathan

5 5

Exceptions in JSC C API
by Jedrzej Nowacki 14 Jun '10

14 Jun '10

Hi, I would like to ask about an exception handling policy in JSC C API implementation. After checking the code I found a common pattern: (A) if (exec->hadException()) { if (exception) *exception = toRef(exec, exec->exception()); exec->clearException(); } Which means that exception handler value is set only when an exception occurs. Another approach that I found is in JSValueCreateJSONString: (B) if (exception) *exception = 0; if (exec->hadException()) { if (exception) *exception = toRef(exec, exec->exception()); exec->clearException(); } That code always set exception handler. Advantage of this solution (B) is that after call, an api user can check if actually an exception occured by checking value of the exception handler (it was possible with the first approach (A) by initialize exception handler to null, but it is rather a side effect). The B pattern is not optimal, because the exception handler may be reinitialized. I believe that an exception handler should be used for simple error checking; - there is not null exception value => it means that returned value is not valid, because of an error. - there is null exception => everything is ok. What do you think about code C? (C) if (exception) { if (exec->hadException()) { *exception = toRef(exec, exec->exception()); exec->clearException(); } else *exception = 0; } else exec->clearException(); In this case exception handler is always set correctly. Would it make sense to change the behavior? The change unifies interface and is binary compatible. It shouldn't break a correct code... :-) Cheers, Jędrek

3 3