#javascriptcore

[gslin]

用 JavaScriptCore 實做的一站式方案 Bun

用 JavaScriptCore 實做的一站式方案 Bun

前幾天在 Hacker News 上討論得很熱烈的 Bun：「Bun: Fast JavaScript runtime, transpiler, and NPM client written in Zig (bun.sh)」。 從 Hacker News 上的標題上就可以看到 Bun 做了不少事情，看起來想要打造一個 all-in-one 環境，把所有開發與 server 端 JavaScript 所需要的東西就一次包進來，不需要在自己東挑西挑… 比較特別的是 Bun 在選 JavaScript Engine 的時候是選擇 Apple 家推出的 JSC (或者稱 JSCore，正式名稱是 JavaScriptCore)，而不是現在主流的 V8 (Google 家)，據說這樣比較省記憶體，但 server 端應用應該是不缺這個記憶體才對？ JavaScript runtime with…

View On WordPress

[dmauro]

How to keep JSContext from crashing your iOS 7 app

I found a pretty sneaky JavaScript Core bug recently which was triggered by getting an exception when evaluating JavaScript with a JSContext. When the JSContext that caught the exception is deallocated, it would crash my app. Luckily I ran into this not long before WWDC so I was able to get some help with it in the WebKit lab. As it turns out there was a bug in JSContext's dealloc method that was only just recently fixed, but unfortunately we won't see that fix until iOS8 is out. If you need to support iOS 7 and want to use JSContext to evaluate JS, the fix is very simple; before your context gets released, simply nil out its exception property. Here's a simple code example:

@autoreleasepool {     JSContext *context = [[JSContext alloc] initWithVirtualMachine:[[JSVirtualMachine alloc] init];     [context evaluateScript:@"bad"];     // This needs to get nil'd before deallocation     context.exception = nil; }

So save yourself the trouble and make sure to always clear the exception of any contexts you have used to evaluate code before deallocating it if you're targeting iOS 7.