SquirrelFish Extreme for non x-86 platforms

SquirrelFish Extreme for non x-86 platforms

 I want to know whether WebKit JavaScript Engine SquirrelFish Extreme (SFX)
has been reported to work on any embedded, non-x86 platform? I have built a
recent nightly build on Windows and it works fine. However, there is use of
Windows specific VirtualAlloc() API functions for allocating memory from
virtaul address space. What will be the alternative for this routine on
non-Windows platforms, especially the embedded ones? Thanks.

To be more specific:

1) The JS engine should work on any CPU and on most reasonable  
operating systems in bytecode mode. It's still pretty fast as bytecode  
- nearly an order of magnitude faster than the old WebKit JS engine.

2) Currently the JIT only fully works on x86 and will soon also work  
on x86_64 (currently some basic tests pass but neither performance nor  
correctness are where we want them to be).

3) We are considering ports of the JIT to other CPU architectures. For  
mobile platforms, it's not entirely clear whether the JIT will turn  
out to be better than the bytecode interpreter - the memory cost might  
outweigh the speed benefit.

That means the current JS Engine (SquirrelFish Extreme) can be run on
embedded/mobile platforms in bytecode mode without JIT. Correct me if I am
wrong? If I am correct, then how to enable the engine's bytecode mode? There
are number of ENABLE switches related to current JS engine...

It should compile with JIT disabled on platforms that do not support  
the JIT.

This way the engine will run without JIT support. However, what to do with
memory allocation functions like VirtualAlloc() that are only available on
Windows? I mean to say, to run on embedded platforms, what alternate has to
exist that may provide the facility of VirtualAlloc(). As far I have seen,
the virtualAlloc() calls can be disabled even on Windows by setting
HAVE_VIRTUAL_ALLOC to 0 in JSC/wtf/Platform.h. However, the garbage
collection implementation uses this particular call inside
JSC/runtime/Collector.cpp irrespective of HAVE_VIRTUAL_ALLOC being 0 or 1.
Any suggestions on this front?

That call to VirtualAlloc is inside a PLATFORM(WIN_OS) guard -- you  
should not be hitting it on a non-windows platform
This is basically expected -- as the code for other platforms should  
have also indicated the collector has important alignment requirements  
that fastMalloc does not guarantee.

Alignment -- VirtualAlloc, mmap, vm_map all produce page aligned  
memory (which is at least 4k aligned), and the posix_memalign version  
appears to actually over align memory (my following of the code makes  
me thinks it's requesting 64k alignment.
I'm still not sure what your problem is -- posix systems should  
provide mmap or posix_memalign either of which will achieve correct  
behaviour
All of the #if branches allocateBlock will guarantee 64k alignment,  
which is what is required. That's with the exception of the  
PLATFORM(SYMBIAN) branch, which appears to be incorrect. I would  
expect it to lead to crashes as a result of incorrect garbage  
collection.