[webkit-dev] Thought about Nix JavaScriptCore port

[Filip Pizło]

> On Feb 10, 2016, at 1:40 AM, Konstantin Tokarev <annulen at yandex.ru> wrote:
> 
> 
> 
> 10.02.2016, 05:41, "Eric Wing" <ewmailing at gmail.com>:
>>> On 2/7/16, Konstantin Tokarev <annulen at yandex.ru> wrote:
>>>  Please try updated version of my branch, it now does not use LLVM unless you
>>>  enable USE_LLVM_DISASSEMBLER.
>> 
>> I merged your branch. That seemed to build and work.
>> So what would USE_LLVM_DISAAEMBLER get me if I could build it?
> 
> It will allow you to disassemble JIT code on architectures that are supported by LLVM but lack specialized disassembler inside JSC, e.g. it was known to work on ARM traditional.

We should drop the llvm disassembler support since we don't need it for ARM64, ARMv7, or x86. If we care about disassembly on ARM traditional, we should write one. It's not that hard. 

> 
>> Also, are there things I can do to shrink JavaScriptCore?

Disable various optimizing JITs if you're desperate enough. 

But I think you could also reduce size by experimenting with out-of-lining cold functions that are currently online. That would be a longer term project. 

> 
> 
> You can try to disable all code related to disassembler and inspector (if you don't need these features).
> 
> Also you can try building without API/JSCTestRunnerUtils.cpp and runtime/TestRunnerUtils.cpp.
> 
> 
>> It's now
>> over 20MB. I know ICU is a big part of that, but JSC itself seems to
>> keep getting bigger too.
>> 
>> To respond to a prior suggestion about ICU size, I am familiar with
>> the data archive option. However, there are several challenges with
>> that:
>> - I don't know what parts JSC actually needs to know what I can safely remove
> 
> 
> I second this request, it would be great if WebKit had a documentation which kinds of ICU data are used by JSC and by WebCore.
> 
> 
>> - I don't know how ICU/JSC load the data archive. Android APK file
>> semantics are pretty terrible and you have to send around a Java
>> AsssetManager to access everything. Standard file library calls don't
>> 'just work'.
>> - I really need to build as a static library because since it is a
>> private implementation detail of JSC. There are problems if somebody
>> downstream of me wants to use ICU, with a potentially different
>> version. If I dynamically link and use data archives, I open up a lot
>> of conflict issues. Similarly, Android itself may use ICU internally
>> and I've been warned of conflict problems by others. Static linking
>> avoids these headaches. Also, I haven't figured out if data archive
>> and static libraries are compatible.
> 
> 
> IIRC, Android is shipped with ICU4J, and in recent ICU versions they are using the same data format.
> 
> 
>> - I did notice Apple has a modified, stripped down version of ICU as
>> part of Darwin. I was unable to figure out how to get it built. It was
>> a pretty complicated Makefile.
>> 
>> Thanks,
>> Eric
>> 
>> P.S.
>> Here is an indentation fix for my previous ICU patch.
>> https://github.com/ewmailing/webkit/commit/e2c94e8b126143402b4e17cc514c4df412de5ace
> 
> -- 
> Regards,
> Konstantin
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev