You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently when Honey Potion translates code, we often create a "result" variable that keeps the result of an operation. As a barebones example, we could have:
result = Operation(...) # Result is alive.
... |
use(result) # Result dies here.
...
result2 = Operations(...) # Result 2 is alive.
... |
use(result2) # Result 2 dies here.
It is easy to notice that both variables have no intersection (The lines marked by #----#), which means that both could use the same memory space. Here is an example where a memory space is represented by a variable.
memspace1 = Operation(...) # Result is alive. Uses memspace1
... |
use(memspace1) # Result dies here. Liberates memspace1
...
memspace1 = Operations(...) # Result 2 is alive. Uses the liberated memspace1
... |
use(memspace1) # Result 2 dies here. Liberates memspace1 once again
However, currently we keep creating new variables instead of reusing the old space, which makes using up the 512 byte stack limit of eBPF much easier. As a way to make our programs significantly bigger, we wish to reuse space with cleverer Memory Management going forward.
This issue should start being worked on after the new translation discussed on #39 and should integrate with the liveness analysis that is already in Honey Potion.
The text was updated successfully, but these errors were encountered:
Currently when Honey Potion translates code, we often create a "result" variable that keeps the result of an operation. As a barebones example, we could have:
It is easy to notice that both variables have no intersection (The lines marked by #----#), which means that both could use the same memory space. Here is an example where a memory space is represented by a variable.
However, currently we keep creating new variables instead of reusing the old space, which makes using up the 512 byte stack limit of eBPF much easier. As a way to make our programs significantly bigger, we wish to reuse space with cleverer Memory Management going forward.
This issue should start being worked on after the new translation discussed on #39 and should integrate with the liveness analysis that is already in Honey Potion.
The text was updated successfully, but these errors were encountered: