[Webkit-unassigned] [Bug 129992] JS engine completely broken on ia64

[bugzilla-daemon at webkit.org]

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

--- Comment #4 from Filip Pizlo <fpizlo at apple.com> ---
(In reply to comment #0)
> Hi,
> 
> Starting up a WebKit-based application, e.g. GNOME Epiphany or Yelp,
> immediately segfaults.
> 
> Back in the WebKit 1.x days, patches for WebKit 1.8.1 on Debian were
> provided to fix JS engine on ia64 [1][2]. Sadly, it seems to me that these
> were never reported/merged upstream. They address three problems in WebKit
> JS engine.
> 
> [1st issue] On ia64, USE(JSVALUE64) is true. From the source code comment,
> JSVALUE64 path uses some sophisticated tricks in order to get everything in
> a 64-bits wide data type. As outlined there, this will work as long the high
> 16-bits of the addresses of any allocated memory are cleared. This is not
> always the case on ia64. A similar issue was fixed on Mozilla JS engine [3].
> Original 01-ia64-wide-ptr patch against WebKit 1.8.1 [4] fixed this issue by
> defining a third JSVALUE64W option that was used on ia64 only. This path
> uses an encapsulated union without any trick for the variant data. As
> outlined by original author, this a portable but the data type is 128-bits
> wide and enabling JIT compiler isn't possible (note that ia64 doesn't have a
> JIT compiler).

You're going to have a really bad time with JSVALUE64W, particularly since it will always be an obscure configuration that nobody uses.  This is especially true since ia64 is effectively dead - it's hard to get help implementing and maintaining a port for unused architectures. I recommend trying to address this problem with a less invasive approach that is less work to implement and less work to maintain.

I suggest teaching our GC to allocate pages in a low memory range where the top 16 address bits are zero. I think that's what Mozilla did. 

You could also have a global variable that contains the global heap offset and turn each access into:

PtrBits = Value & 0xffffffffffff
Ptr = HeapBase + PtrBits

This would still be a big change, so it's preferable to just find the right mmap trick to pin the heap in low memory. 

> 
> [2nd issue] On ia64, and probably other arches too, caches are not coherent
> automatically. As such fast malloc implementation in
> Source/JavaScriptCore/wtf/FastMalloc.cpp is totally buggy. This was
> work-around by using system malloc instead in ia64-use-system-malloc patch
> [5].

If this is true then you'll need to make lots of other changes in WebKit. WebKit assumes that the memory model is never weaker than what ARM would do. 

> 
> [3rd issue] On Linux ia64, and probably other arches too, memory pages are
> not necessarily 4K. ia64 can have 4K, 8K, 16K or 64K memory pages. Most
> (all?) Linux ia64 distributions come with 16K memory pages. This was fixed
> in large-mem-page patch [6]. It's my understanding that this issue has also
> been fixed in bug #80615, but I may be wrong.

I doubt that this is an issue anymore. I know we run with different page sizes on different platforms now. 

> 
> So, we're left with first two issues, unless second issue is no more valid
> nowadays.
> 
> Since original patch author no more wants to invest time on debugging
> WebKit, I've tried to port his work to WebKit 2.2.5, as it's the version
> we're trying to stabilize with GNOME 3.10 on Gentoo. It's not an easy task
> for me as (i) I'm not the original patch author so don't know what he's got
> in mind and (ii) I'm not a WebKit developer at all, so don't know how code
> has evolved or has been refactored since the Webkit 1.x days.
> 
> So, if a kind soul could have a look at the patches I'll post in this
> bugreport and give me advice to get WebKit JS engine fixed on ia64 or
> commonalize this work with other arches (is ia64 the only one using full
> 64-bit data path?), I would be really happy ;-)
> 
>      Émeric
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642750#96
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694971#5
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=589735
> [4]
> https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=69;filename=01-ia64-wide-
> ptr.patch;att=1;bug=642750
> [5]
> https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=69;filename=02-ia64-use-
> system-malloc.patch;att=2;bug=642750
> [6]
> https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=large-mem-page.
> patch;att=1;bug=694971

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151101/7a0b5fb5/attachment-0001.html>