I'd like to contact some one for discus eventual winndows port ...

[LadislavSopko]

I'm developing similar solution, but I choose much more simpler
aproach, I just replace mmap/VirtualAlloc calls in lj_alloc.c
with mine cooked mmap/VirtualAlloc calls . My code at start reserve 1-2GB of low address space
and then i just give it, in use to luajit ( I let luajit use it's memory allocator, I just provide blocks of address pages on demand from previously reserved space using RESERVE/COMMIT ram trick in win and similar aproach in nix.). I'd like to discuss some aspects of mine solution in respect of
yours, maby we can share experiences.

regards Ladisalv.

[yangshuxin]

Hi,
This is really great! Do you open source your work?

I think I use about the same approach as what you depicted. I call it user-space mmap() implementation. Basically, the ljmm hooks to luajit by replacing its function call the mmap/munmap/mremap. At start, the ljmm is to reserver the address space of [program's BSS, 2G], or [1G, 2G](so the glibc's mmap take over the [BSS, 1G] part).

I use a buddy system to keep track of the free blocks. Buddy system is able to combine adjacent with 2n pages into a bigger block (with 2(n+1) pages). While buddy allocator can handle external fragmentation very well, it's not able to handle internal fragmentation. In the worst, extreme case, the infragmentation would incur 50% waste. But in practice, it seems we should not worry about it.

I try to improve locality (by reducing the working set), but so far I don't have any good solution.

I don't have lots lua code at hand, I tested this work by hooking the ljmm to C/C++ applications. I measure the peformanc impact using CPU2000int, and did not find any negative performance impact. The testing is done by mmap() is small block right after .bss when app starts); this way glibc's malloc() is done by mmap()ing a big chunk of memory, and then carve an block out of it). C/C++ application test mmap/munmap() very well. However, the mremap() is not sufficiently tested. Unforuantely, mremap() is used extensively in luajit.

[LadislavSopko]

hi,
thank you for response. :)

sure, i can give all code, what is not dependent on our, internals(i use our logging framework, but except that all is free). what surprised me, is a fact to need handle free blocks (buddy blocks management in your case) and some sort of allocation it self, if luajit handle it already in lj_alloc.c.
I see it as to much overhead ( but it can be that i did not understand well, how lj handle it at all.
but what I ll try explain in next lines is already working, in early proof of concept project.
lets see my considerations( im not sure if im on right way... :) )
Memory handling as i understand it.
RAM is handled on 3 levels,
a: page level
b: custom allocator
c: garbage collector
I saw that good way should be inject code in level a.
there are things to handle:
- reserve address space under 4gb
- commit ram in reserved address space and give it as pages region to the luajit allocator
- reclaim pages from luajit
- release address space to system.

see each one in detail.

       - reserve ram, it is done by mmap / virtualalloc, with params and attributes set in way that no ram is allocated, just address space, and pages of ram are tagged as reserved. This is done at process start, in few big blocks, I start with 1gb block reserving, and few smaller to obtain, wanted 2 gb.  then i set for each block bitmap array, so i can flag used pages by luajit.( i just give to lua page sets.)

        - commit ram is done with virtualalloc/ mprotect, so system give me real ram.

when lua ask me some ram block for size, i just run in my bit arrays, linearly and find first place where are enough not used pages for that block, then i flag pages, and record block, so i can free it later.

        - when lua give me back block, i just flag pages as free, so i can reuse them next alloc req, and i protect them back to uncommitted but reserved state. virtualalloc/mprotect. ( i don't use virtualfree here!!!!! i just change its state)

        - at the end i just release address space to system with unmap/virtualfree.

i choose this approach cause im injecting my code at page level , not at malloc/free level
so luajit handle allocation on itself, i just give him ram pages when he need it, and i suppose its not so often. maybe linear search in bit array is slow, it should be optimized, but i suspect that we will not handle many requests for small blocks, cause it is handled on upper level.
there are some weaknesses here, problem is reserve ram, in linux, if used Map_32.. reserved addresses are good, in windows there is possibility that some one will steal lower ram. but i hope we will handle it well this, after when we have addresses reserved, then we will need handle
pages utilization, and her for sure we can probably optimize my approach if it will be slow...

sorry for my english, but i hope i explain me well, so we can continue our discussion.

ladislav ;)

Inviato da iPad

Il giorno 18/apr/2015, alle ore 00:57, yangshuxin [email protected] ha scritto:

Hi,
This is really great! Do you open source your work?

I think I use about the same approach as what you depicted. I call it user-space mmap() implementation. Basically, the ljmm hooks to luajit by replacing its function call the mmap/munmap/mremap. At start, the ljmm is to reserver the address space of [program's BSS, 2G], or [1G, 2G](so the glibc's mmap take over the [BSS, 1G] part).
I use a buddy system to keep track of the free blocks. Buddy system is able to combine adjacent with 2n pages into a bigger block (with 2(n+1) pages). While buddy allocator can handle external fragmentation very well, it's not able to handle internal fragmentation. In the worst, extreme case, the infragmentation would incur 50% waste. But in practice, it seems we should not worry about it.

I try to improve locality (by reducing the working set), but so far I don't have any good solution.

I don't have lots lua code at hand, I tested this work by hooking the ljmm to C/C++ applications. I measure the peformanc impact using CPU2000int, and did not find any negative performance impact. The testing is done by mmap() is small block right after .bss when app starts); this way glibc's malloc() is done by mmap()ing a big chunk of memory, and then carve an block out of it). C/C++ application test mmap/munmap() very well. However, the mremap() is not sufficiently tested. Unforuantely, mremap() is used extensively in luajit.
—
Reply to this email directly or view it on GitHub.

[yangshuxin]

Hi,

 I think your design work perfectly well for common cases. However, 

I have bunch
of concerns that are not addressed by your description. See the
following interleaving
comment.

On 04/18/2015 09:10 AM, LadislavSopko wrote:

hi,
thank you for response. :)

sure, i can give all code, what is not dependent on our, internals(i
use our logging framework, but except that all is free). what
surprised me, is a fact to need handle free blocks (buddy blocks
management in your case) and some sort of allocation it self, if
luajit handle it already in lj_alloc.c.
I see it as to much overhead ( but it can be that i did not understand
well, how lj handle it at all.
but what I ll try explain in next lines is already working, in early
proof of concept project.
lets see my considerations( im not sure if im on right way... :) )
Memory handling as i understand it.
RAM is handled on 3 levels,
a: page level
b: custom allocator
c: garbage collector
I saw that good way should be inject code in level a.
Me too.

We once tried to modify Linux kernel such that mmap() such that it can
reserve block
from lowest possible address space without explicitly specifying the
starting address.
However, the story of mmap with MAP_32BIT really scare me.
http://timetobleed.com/digging-out-the-craziest-bug-you-never-heard-about-from-2008-a-linux-threading-regression/

there are things to handle:

• reserve address space under 4gb
  luajit used to have a problem of using [2gb-4gb] space on x86-64
  architecture. I don't know
  if it's still valid. see,
  http://lua-users.org/lists/lua-l/2010-10/msg00688.html
• commit ram in reserved address space and give it as pages region to
  the luajit allocator
• reclaim pages from luajit
• release address space to system.
  On Linux, luajit call mremap() which is able to shrink or expand
  existing allocated block.
  What's the counterpart on Window? Does luajit/win call this function on
  Windows platform?
  To me, mremap is far more complicated than mmap.

see each one in detail.

• reserve ram, it is done by mmap / virtualalloc, with params and
  attributes set in way that no ram is allocated, just address space,
  and pages of ram are tagged as reserved. This is done at process
  start, in few big blocks, I start with 1gb block reserving, and few
  smaller to obtain, wanted 2 gb. then i set for each block bitmap
  array, so i can flag used pages by luajit.( i just give to lua page sets.)

I tried to use bitmask as well. However, I don't know how to deal with
fragmentation with it.
To ease description, assuming you reserve space [2G, 2G+128]. Then
luajit start allocating
small objects, say 16 byte in size. Since there is no block available at
this time, luajit tries to
mmap() a block with 32kb (I don't remember the default size)... It
allocate 4 blocks, then
it starts to delete them. Assuming the 2nd and 3rd blocks are freed, and
you have 64kb free
space in total. However, the 64kb free space is not contiguous, and
hence not able to satisfy
the allocation request even for 34kb block.

If the luajit keep allocating small objects, and hence mmap-ping 32kb
block accordingly.
I think this way works perfectly well in the sense:
1. no fragmentation at all
2. the virtually "released" block can serve the next "commit"
request, which improve
locality, reduce working set, and reduce TLB miss.

The only reason I went for buddy allocation is to address the
external fragment.
It has drawback though, it does not have idea of locality (this might
present a problem).
Also, it give rise to the internal fragmentation -- consider the case
when buddy allocation
have to allocate 64kb for 32kb+1byte allocation request. So the worse
case for the
internal fragmentation is 50%!

For us, Internal fragmentation is not a big deal as most object are
quite small, therefore
more often than not, luajit allocate 32kb block. While the allocating
big objects take
place only once in a while, we have to have luajit survive.

• commit ram is done with virtualalloc/ mprotect, so system give me
  real ram.
  when lua ask me some ram block for size, i just run in my bit arrays,
  linearly and find first place where are enough not used pages for that
  block, then i flag pages, and record block, so i can free it later.
  What is the algorithm complexity of finding the first-fit or best fit?

Do you try to merge adjacent blocks into a big one?

• when lua give me back block, i just flag pages as free, so i can
  reuse them next alloc req, and i protect them back to uncommitted but
  reserved state. virtualalloc/mprotect.

If the released block have 56kb in size, and the next allocation is
32kb. How do you do in this situation?
Do you split the 56kb in into two parts to serve the allocation request?

Also, while luajit see a virtually released block, the OS view it as
physically used block,
and the pages in the bock are dirty! So, when the memory is tight, the
content of this
block will be swapped to disk. Well, the cost the write maybe not a big
deal. Next time
you start the use this previously released block, OS has to bring the
swap content back
although luajit dose not care about the old content of the previously
released block.

Linux's madvise() comes in handy for telling OS not to swap particular
part of memory.
But it has another cost -- this part of memory need to bzero()-ed for
the next use.

Does Window have similar problem?

Best Regards!
Shuxin Yang

[LadislavSopko]

hello again :), I'm really happy to have possibility, to discuss, ill leave comments in
text.

Inviato da iPad

Il giorno 19/apr/2015, alle ore 18:50, yangshuxin [email protected] ha scritto:

Hi,

I think your design work perfectly well for common cases. However,
I have bunch
of concerns that are not addressed by your description. See the
following interleaving
comment.

On 04/18/2015 09:10 AM, LadislavSopko wrote:

hi,
thank you for response. :)

sure, i can give all code, what is not dependent on our, internals(i
use our logging framework, but except that all is free). what
surprised me, is a fact to need handle free blocks (buddy blocks
management in your case) and some sort of allocation it self, if
luajit handle it already in lj_alloc.c.
I see it as to much overhead ( but it can be that i did not understand
well, how lj handle it at all.
but what I ll try explain in next lines is already working, in early
proof of concept project.
lets see my considerations( im not sure if im on right way... :) )
Memory handling as i understand it.
RAM is handled on 3 levels,
a: page level
b: custom allocator
c: garbage collector
I saw that good way should be inject code in level a.
Me too.

We once tried to modify Linux kernel such that mmap() such that it can
reserve block
from lowest possible address space without explicitly specifying the
starting address.
However, the story of mmap with MAP_32BIT really scare me.
http://timetobleed.com/digging-out-the-craziest-bug-you-never-heard-about-from-2008-a-linux-threading-regression/

there are things to handle:

• reserve address space under 4gb
  luajit used to have a problem of using [2gb-4gb] space on x86-64
  architecture. I don't know
  if it's still valid. see,
  http://lua-users.org/lists/lua-l/2010-10/msg00688.html

yes this should be a problem, yes lj use 31 bit wide addresses, ill will handle this.

• commit ram in reserved address space and give it as pages region to
  the luajit allocator
• reclaim pages from luajit
• release address space to system.
  On Linux, luajit call mremap() which is able to shrink or expand
  existing allocated block.
  What's the counterpart on Window? Does luajit/win call this function on
  Windows platform?
  To me, mremap is far more complicated than mmap.

in windows it not use remap, ill do implement it on my page level, if no free space ill do move.. i have to make some testing here... shrink should be no problem, i just free pages, increase is the same , if there are free pages, if not ... worst case, anyway...

see each one in detail.

• reserve ram, it is done by mmap / virtualalloc, with params and
  attributes set in way that no ram is allocated, just address space,
  and pages of ram are tagged as reserved. This is done at process
  start, in few big blocks, I start with 1gb block reserving, and few
  smaller to obtain, wanted 2 gb. then i set for each block bitmap
  array, so i can flag used pages by luajit.( i just give to lua page sets.)

I tried to use bitmask as well. However, I don't know how to deal with
fragmentation with it.
To ease description, assuming you reserve space [2G, 2G+128]. Then
luajit start allocating
small objects, say 16 byte in size. Since there is no block available at
this time, luajit tries to
mmap() a block with 32kb (I don't remember the default size)... It
allocate 4 blocks, then
it starts to delete them. Assuming the 2nd and 3rd blocks are freed, and
you have 64kb free
space in total. However, the 64kb free space is not contiguous, and
hence not able to satisfy
the allocation request even for 34kb block.

If the luajit keep allocating small objects, and hence mmap-ping 32kb
block accordingly.
I think this way works perfectly well in the sense:

1. no fragmentation at all
2. the virtually "released" block can serve the next "commit"
   request, which improve
   locality, reduce working set, and reduce TLB miss.
   as i read in their code, they handle small blocks for them self, and ask to mmap, just bigger blocks, i need do some more testing, il do some allocation trace this week, to see how it handle,pages requests, ( do you have some lua script what i can use for test?)

The only reason I went for buddy allocation is to address the
external fragment.
It has drawback though, it does not have idea of locality (this might
present a problem).
Also, it give rise to the internal fragmentation -- consider the case
when buddy allocation
have to allocate 64kb for 32kb+1byte allocation request. So the worse
case for the
internal fragmentation is 50%!

For us, Internal fragmentation is not a big deal as most object are
quite small, therefore
more often than not, luajit allocate 32kb block. While the allocating
big objects take
place only once in a while, we have to have luajit survive.

ill probably try to patch lua jit allocator, in order that it call my pages allocator for some sort of bigger blocks, i have to test it a bit, i prefer tune lj allocator instead cook one new.

• commit ram is done with virtualalloc/ mprotect, so system give me
  real ram.
  when lua ask me some ram block for size, i just run in my bit arrays,
  linearly and find first place where are enough not used pages for that
  block, then i flag pages, and record block, so i can free it later.
  What is the algorithm complexity of finding the first-fit or best fit?
  now is just linear search, not optimized, ill trace allocation requests, in real
  use so ill measure how much this impact in overall performance. if necessary, ill probably
  do some sort of skip list in order to find fast free pages regions.

Do you try to merge adjacent blocks into a big one?
i have no merging, cause i not handle blocks, i just flag pages (4kb default)

• when lua give me back block, i just flag pages as free, so i can
  reuse them next alloc req, and i protect them back to uncommitted but
  reserved state. virtualalloc/mprotect.

If the released block have 56kb in size, and the next allocation is
32kb. How do you do in this situation?
Do you split the 56kb in into two parts to serve the allocation request?
now i dont handle blocks, tomorrow ill send you my code so it will be simpler
to discuss it.

Also, while luajit see a virtually released block, the OS view it as
physically used block,
here i have to test what happen, cause in fact ram should be reclaimed by os, and addresses should stay reserved.
and the pages in the bock are dirty! So, when the memory is tight, the
content of this
block will be swapped to disk. Well, the cost the write maybe not a big
deal. Next time
you start the use this previously released block, OS has to bring the
swap content back
although luajit dose not care about the old content of the previously
released block.

have to test , what happen when i unprotect page, im in early proof of concept stage.
i just exploring how underlaying things work... ;)

Linux's madvise() comes in handy for telling OS not to swap particular
part of memory.
But it has another cost -- this part of memory need to bzero()-ed for
the next use.
linux swap only used pages no?, have to test what happen when page will be unprotected
Does Window have similar problem?
in windows, when page is uncommitted, system reclaim ram, but not address space.

Best Regards!
Shuxin Yang

—
Reply to this email directly or view it on GitHub.

[LadislavSopko]

Hello,

I have some new results of testing. I found that luajit allocator ask for
pages in many requests, it merge them if adjacent and release it all in few
calls (. So I'm working on handle this. In windows I have already
functional code with remap too.
Today I'll do linux port.

ladislav.

2015-04-19 23:33 GMT+02:00 Ladislav Sopko [email protected]:

hello again :), I'm really happy to have possibility, to discuss, ill
leave comments in
text.

Inviato da iPad

Il giorno 19/apr/2015, alle ore 18:50, yangshuxin <
[email protected]> ha scritto:

Hi,

I think your design work perfectly well for common cases. However,
I have bunch
of concerns that are not addressed by your description. See the
following interleaving
comment.

On 04/18/2015 09:10 AM, LadislavSopko wrote:

hi,
thank you for response. :)

sure, i can give all code, what is not dependent on our, internals(i
use our logging framework, but except that all is free). what
surprised me, is a fact to need handle free blocks (buddy blocks
management in your case) and some sort of allocation it self, if
luajit handle it already in lj_alloc.c.
I see it as to much overhead ( but it can be that i did not understand
well, how lj handle it at all.
but what I ll try explain in next lines is already working, in early
proof of concept project.
lets see my considerations( im not sure if im on right way... :) )
Memory handling as i understand it.
RAM is handled on 3 levels,
a: page level
b: custom allocator
c: garbage collector
I saw that good way should be inject code in level a.
Me too.

We once tried to modify Linux kernel such that mmap() such that it can
reserve block
from lowest possible address space without explicitly specifying the
starting address.
However, the story of mmap with MAP_32BIT really scare me.

http://timetobleed.com/digging-out-the-craziest-bug-you-never-heard-about-from-2008-a-linux-threading-regression/

there are things to handle:

• reserve address space under 4gb
  luajit used to have a problem of using [2gb-4gb] space on x86-64
  architecture. I don't know
  if it's still valid. see,
  http://lua-users.org/lists/lua-l/2010-10/msg00688.html

yes this should be a problem, yes lj use 31 bit wide addresses, ill will
handle this.

• commit ram in reserved address space and give it as pages region to
  the luajit allocator
• reclaim pages from luajit
• release address space to system.
  On Linux, luajit call mremap() which is able to shrink or expand
  existing allocated block.
  What's the counterpart on Window? Does luajit/win call this function on
  Windows platform?
  To me, mremap is far more complicated than mmap.

in windows it not use remap, ill do implement it on my page level, if no
free space ill do move.. i have to make some testing here... shrink should
be no problem, i just free pages, increase is the same , if there are free
pages, if not ... worst case, anyway...

see each one in detail.

• reserve ram, it is done by mmap / virtualalloc, with params and
  attributes set in way that no ram is allocated, just address space,
  and pages of ram are tagged as reserved. This is done at process
  start, in few big blocks, I start with 1gb block reserving, and few
  smaller to obtain, wanted 2 gb. then i set for each block bitmap
  array, so i can flag used pages by luajit.( i just give to lua page
  sets.)

I tried to use bitmask as well. However, I don't know how to deal with
fragmentation with it.
To ease description, assuming you reserve space [2G, 2G+128]. Then
luajit start allocating
small objects, say 16 byte in size. Since there is no block available at
this time, luajit tries to
mmap() a block with 32kb (I don't remember the default size)... It
allocate 4 blocks, then
it starts to delete them. Assuming the 2nd and 3rd blocks are freed, and
you have 64kb free
space in total. However, the 64kb free space is not contiguous, and
hence not able to satisfy
the allocation request even for 34kb block.

If the luajit keep allocating small objects, and hence mmap-ping 32kb
block accordingly.
I think this way works perfectly well in the sense:

1. no fragmentation at all
2. the virtually "released" block can serve the next "commit"
   request, which improve
   locality, reduce working set, and reduce TLB miss.

as i read in their code, they handle small blocks for them self, and ask
to mmap, just bigger blocks, i need do some more testing, il do some
allocation trace this week, to see how it handle,pages requests, ( do you
have some lua script what i can use for test?)

The only reason I went for buddy allocation is to address the
external fragment.
It has drawback though, it does not have idea of locality (this might
present a problem).
Also, it give rise to the internal fragmentation -- consider the case
when buddy allocation
have to allocate 64kb for 32kb+1byte allocation request. So the worse
case for the
internal fragmentation is 50%!

For us, Internal fragmentation is not a big deal as most object are
quite small, therefore
more often than not, luajit allocate 32kb block. While the allocating
big objects take
place only once in a while, we have to have luajit survive.

ill probably try to patch lua jit allocator, in order that it call my
pages allocator for some sort of bigger blocks, i have to test it a bit, i
prefer tune lj allocator instead cook one new.

• commit ram is done with virtualalloc/ mprotect, so system give me
  real ram.
  when lua ask me some ram block for size, i just run in my bit arrays,
  linearly and find first place where are enough not used pages for that
  block, then i flag pages, and record block, so i can free it later.
  What is the algorithm complexity of finding the first-fit or best fit?

now is just linear search, not optimized, ill trace allocation requests,
in real
use so ill measure how much this impact in overall performance. if
necessary, ill probably
do some sort of skip list in order to find fast free pages regions.

Do you try to merge adjacent blocks into a big one?

i have no merging, cause i not handle blocks, i just flag pages (4kb
default)

• when lua give me back block, i just flag pages as free, so i can
  reuse them next alloc req, and i protect them back to uncommitted but
  reserved state. virtualalloc/mprotect.

If the released block have 56kb in size, and the next allocation is
32kb. How do you do in this situation?
Do you split the 56kb in into two parts to serve the allocation request?

now i dont handle blocks, tomorrow ill send you my code so it will be
simpler
to discuss it.

Also, while luajit see a virtually released block, the OS view it as
physically used block,

here i have to test what happen, cause in fact ram should be reclaimed by
os, and addresses should stay reserved.

and the pages in the bock are dirty! So, when the memory is tight, the
content of this
block will be swapped to disk. Well, the cost the write maybe not a big
deal. Next time
you start the use this previously released block, OS has to bring the
swap content back
although luajit dose not care about the old content of the previously
released block.

have to test , what happen when i unprotect page, im in early proof of
concept stage.
i just exploring how underlaying things work... ;)

Linux's madvise() comes in handy for telling OS not to swap particular
part of memory.
But it has another cost -- this part of memory need to bzero()-ed for
the next use.

linux swap only used pages no?, have to test what happen when page will be
unprotected

Does Window have similar problem?

in windows, when page is uncommitted, system reclaim ram, but not address
space.

Best Regards!
Shuxin Yang

—
Reply to this email directly or view it on GitHub
#2 (comment).

[LadislavSopko]

I manage it to work, In linux it is even more fast as original luajit. In windows it loose some farction
of time. ;)
Check my code here : https://github.com/LadislavSopko/libvmm

regards
Ladislav

[yangshuxin]

That is truly great! I will read your code sometime this week-end or
next week.
Give you a star on Github first:-)

Best Regards
Shuxin

On 04/29/2015 09:00 AM, LadislavSopko wrote:

I manage it to work, In linux it is even more fast as original luajit.
In windows it loose some farction
of time. ;)
Check my code here : https://github.com/LadislavSopko/libvmm

regards
Ladislav

—
Reply to this email directly or view it on GitHub
#2 (comment).

[LadislavSopko]

Thank you :)

[LadislavSopko]

I did small change, Now it can use all 32bits so actually it reserve 3,5GB
and
it function ...

2015-04-29 18:37 GMT+02:00 yangshuxin [email protected]:

That is truly great! I will read your code sometime this week-end or
next week.
Give you a star on Github first:-)

Best Regards
Shuxin

On 04/29/2015 09:00 AM, LadislavSopko wrote:

I manage it to work, In linux it is even more fast as original luajit.
In windows it loose some farction
of time. ;)
Check my code here : https://github.com/LadislavSopko/libvmm

regards
Ladislav

—
Reply to this email directly or view it on GitHub
<#2 (comment)
.

—
Reply to this email directly or view it on GitHub
#2 (comment).

[yangshuxin]

How did you manage to sidestep the pointer-sign-extension problem?

Thanks
Shuxin

On 04/30/2015 05:09 AM, Ladislav Sopko wrote:

I did small change, Now it can use all 32bits so actually it reserve 3,5GB
and
it function ...

2015-04-29 18:37 GMT+02:00 yangshuxin [email protected]:

That is truly great! I will read your code sometime this week-end or
next week.
Give you a star on Github first:-)

Best Regards
Shuxin

On 04/29/2015 09:00 AM, LadislavSopko wrote:

I manage it to work, In linux it is even more fast as original luajit.
In windows it loose some farction
of time. ;)
Check my code here : https://github.com/LadislavSopko/libvmm

regards
Ladislav

—
Reply to this email directly or view it on GitHub

<#2 (comment)
.

—
Reply to this email directly or view it on GitHub

#2 (comment).

—
Reply to this email directly or view it on GitHub
#2 (comment).

[LadislavSopko]

I don't have manage it, but I found that LJ it self have problem inside jited parts and gc with sign extension, so it's better to hold addresses in max31bits.
http://www.freelists.org/post/luajit/LuaJIT-x64-limited-to-31-bit-address-space-even-without-MAP-32BIT-restrictions

so I'll limit it back to 31 bit. Its just questin change 2 defines.... Pity, no problem for me, any way, cause our scripts, are relatively small, and 2gb are far enough.

Inviato da iPad

Il giorno 30/apr/2015, alle ore 20:00, yangshuxin [email protected] ha scritto:

How did you manage to sidestep the pointer-sign-extension problem?

Thanks
Shuxin

On 04/30/2015 05:09 AM, Ladislav Sopko wrote:

I did small change, Now it can use all 32bits so actually it reserve 3,5GB
and
it function ...

2015-04-29 18:37 GMT+02:00 yangshuxin [email protected]:

That is truly great! I will read your code sometime this week-end or
next week.
Give you a star on Github first:-)

Best Regards
Shuxin

On 04/29/2015 09:00 AM, LadislavSopko wrote:

I manage it to work, In linux it is even more fast as original luajit.
In windows it loose some farction
of time. ;)
Check my code here : https://github.com/LadislavSopko/libvmm

regards
Ladislav

—
Reply to this email directly or view it on GitHub

<#2 (comment)
.

—
Reply to this email directly or view it on GitHub

#2 (comment).

—
Reply to this email directly or view it on GitHub
#2 (comment).

—
Reply to this email directly or view it on GitHub.