Hi everyone,
Once the latest pull-requests from Stefan and Djordje get merged, we should have functionally correct LuaJIT AARCH64 port with LJ_GC64 JIT enabled.
What remains to be done is a clean-up effort (w/some small optimizations) before the code can be presented to Mike.
I suggest this to be done by one side only, to avoid different code styles and such issues. I would nominate Stefan and/or Djordje to do this, if no one objects.
What do you say? Ryan?
Regards,
Petar
On Wed, Sep 28, 2016 at 7:20 AM, Petar Jovanovic petar.jovanovic@rt-rk.com wrote:
Hi everyone,
Once the latest pull-requests from Stefan and Djordje get merged, we
should have functionally correct LuaJIT AARCH64 port with LJ_GC64 JIT enabled.
What remains to be done is a clean-up effort (w/some small optimizations)
before the code can be presented to Mike.
I suggest this to be done by one side only, to avoid different code
styles and such issues. I would nominate Stefan and/or Djordje to do this, if no one objects.
What do you say? Ryan?
Regards,
Petar
Hi Petar,
We (Linaro) were just discussing this yesterday at our Linaro Connect conference.
We agree that we have reached functional completeness. This is absolutely fantastic news.
What sort of optimizations are necessary for upstreaming?
We agree that Stefan or Djordje should do the code/style updates to the port. We were also discussing the future upstreaming effort. As RT-RK has some experience with upstreaming the MIPS port, perhaps you guys will have the most luck with this process? What are your thoughts on upstreaming time-frames and the effort involved? The Linaro engineers will be prepared to work on the necessary changes following any code-review.
Remaining Functional Issues:
1) Garbage-collection issue preventing full completion of the test-suite:
Charles is working on this.
2) Another 48-bit address space bug/issue:
Any allocation done outside of the luajit allocator can run into an issue where that memory might be allocated above the bottom 47-bits that LuaJIT can address, for example some C code executing(allocating) via the LuaJIT FFI.
When LuaJIT tries to access such memory it will overwrite the higher bits in the pointer and access the wrong memory.
Further Efforts:
1) Integration Testing:
Zheng Xu is working on getting NGINX working with ARM64 jit enabled.
2) Continuous Integration:
Zheng Xu is working on setting up a Linaro CI loop and has written a dashboard http://64.28.99.85/ that includes per-patch performance information.
3) Further ARM64 Optimizations:
Charles will start to look at this.
On Wed, Sep 28, 2016 at 9:54 AM, Ryan Arnold ryan.arnold@linaro.org wrote:
On Wed, Sep 28, 2016 at 7:20 AM, Petar Jovanovic petar.jovanovic@rt-rk.com wrote:
Hi everyone,
Once the latest pull-requests from Stefan and Djordje get merged, we should have functionally correct LuaJIT AARCH64 port with LJ_GC64 JIT enabled.
What remains to be done is a clean-up effort (w/some small optimizations) before the code can be presented to Mike.
I suggest this to be done by one side only, to avoid different code styles and such issues. I would nominate Stefan and/or Djordje to do this, if no one objects.
What do you say? Ryan?
Regards,
Petar
Hi Petar,
We (Linaro) were just discussing this yesterday at our Linaro Connect conference.
We agree that we have reached functional completeness. This is absolutely fantastic news.
What sort of optimizations are necessary for upstreaming?
We agree that Stefan or Djordje should do the code/style updates to the port. We were also discussing the future upstreaming effort. As RT-RK has some experience with upstreaming the MIPS port, perhaps you guys will have the most luck with this process? What are your thoughts on upstreaming time-frames and the effort involved? The Linaro engineers will be prepared to work on the necessary changes following any code-review.
Remaining Functional Issues:
- Garbage-collection issue preventing full completion of the test-suite:
Charles is working on this.
- Another 48-bit address space bug/issue:
Any allocation done outside of the luajit allocator can run into an issue where that memory might be allocated above the bottom 47-bits that LuaJIT can address, for example some C code executing(allocating) via the LuaJIT FFI.
When LuaJIT tries to access such memory it will overwrite the higher bits in the pointer and access the wrong memory.
Linaro is discussing this issue with the Linaro Linux kernel team. One thought/solution is to provide a kernel per-process kernel personality which restricts memory allocations to the bottom 47-bits of the address space.
Further Efforts:
- Integration Testing:
Zheng Xu is working on getting NGINX working with ARM64 jit enabled.
- Continuous Integration:
Zheng Xu is working on setting up a Linaro CI loop and has written a dashboard http://64.28.99.85/ that includes per-patch performance information.
- Further ARM64 Optimizations:
Charles will start to look at this.
--
Ryan S. Arnold | Linaro Toolchain Engineering Manager ryan.arnold@linaro.org | ryanarn on #linaro-tcwg @ freenode.irc.net
Hi Ryan,
What sort of optimizations are necessary for upstreaming?
What we had in mind are small optmizations while we are doing the clean up. E.g. allocating registers for 64-bit constants, improve algorithm for loading constants, etc.
As RT-RK has some experience with upstreaming the MIPS port, perhaps you guys will have the most luck with this process?
Sure, we will do that.
What are your thoughts on upstreaming time-frames and the effort involved?
I believe the code will be ready for a review in several weeks. The actual effort that will come afterwards is not known. Hopefully, if we tighten up the code, Mike will have easier task.
- Garbage-collection issue preventing full completion of the test-suite
Charles is working on this.
Is this stack_purge.lua that you are referring to? FWIW, this test is failing on X86-64 too.
- Further ARM64 Optimizations:
Charles will start to look at this.
What do you have in mind? More we optimize and get better code generation, more welcome will be our patches.
Regards, Petar
-
Petar Jovanovic -
Ryan Arnold