-
-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: memory mapping #117
feat: memory mapping #117
Conversation
Codecov Report
@@ Coverage Diff @@
## master #117 +/- ##
==========================================
+ Coverage 82.72% 83.39% +0.66%
==========================================
Files 147 158 +11
Lines 9704 10646 +942
==========================================
+ Hits 8028 8878 +850
- Misses 1676 1768 +92
Continue to review full report at Codecov.
|
910e0dc
to
5760961
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is one crazy PR. I love it! This seems very promising (given the tests). I'm very curious about how good this works in practice!
👏 👏 for this PR. Amazing job!
I've really only got some minor comments.
When an assembly has been hot reloaded, but some of its types are still in use, the entire assembly needs to be kept in memory to maintain validity of existing TypeInfo pointers
macOS seems to use a shared library's install_name when opening a shared library. Previously we stored the full path, which caused the OS to always point to the same file even when copies were made.
When a
struct
's memory layout changes, we want any existing instances of that struct to be converted to the new memory layout. E.g. given a struct definition:we construct a
Foo { a: 1, b: 3.0, c: 5.0 }
. Now we make several changes to the struct definition, as follows:For all moved fields, we expect the values to be mapped (i.e. copied), whereas new values should be zero initialized. In the example, resulting struct would look like this:
The current implementation does not support type casting such as
fn(f32) -> f64
yet.PR #140 adds type casting of primitive types.