<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - JS engine completely broken on ia64"
href="https://bugs.webkit.org/show_bug.cgi?id=129992#c4">Comment # 4</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - JS engine completely broken on ia64"
href="https://bugs.webkit.org/show_bug.cgi?id=129992">bug 129992</a>
from <span class="vcard"><a class="email" href="mailto:fpizlo@apple.com" title="Filip Pizlo <fpizlo@apple.com>"> <span class="fn">Filip Pizlo</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=129992#c0">comment #0</a>)
<span class="quote">> 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).</span >
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.
<span class="quote">>
> [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].</span >
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.
<span class="quote">>
> [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 <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - CopiedSpace::tryAllocateOversize assumes system page size"
href="show_bug.cgi?id=80615">bug #80615</a>, but I may be wrong.</span >
I doubt that this is an issue anymore. I know we run with different page sizes on different platforms now.
<span class="quote">>
> 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] <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642750#96">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642750#96</a>
> [2] <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694971#5">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694971#5</a>
> [3] <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=589735">https://bugzilla.mozilla.org/show_bug.cgi?id=589735</a>
> [4]
> <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=69;filename=01-ia64-wide">https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=69;filename=01-ia64-wide</a>-
> ptr.patch;att=1;bug=642750
> [5]
> <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=69;filename=02-ia64-use">https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=69;filename=02-ia64-use</a>-
> system-malloc.patch;att=2;bug=642750
> [6]
> <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=large-mem-page">https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=large-mem-page</a>.
> patch;att=1;bug=694971</span ></pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>