-
-
Notifications
You must be signed in to change notification settings - Fork 649
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
Implement reference counting and/or garbage collection #16
Comments
See: examples/ugc/assembly/ugc.ts This doesn't do anything useful on its own but instead relies on the compiler to generate the respective per-module scan and free functions that take advantage of the compiler's knowledge of managed objects' internal memory layouts. This should be a lot more efficient than scanning the entire memory for stuff that resembles a pointer. To make this work, each managed object would then start with an |
Is it worth to implement GC? Full implementation of all JS semantic will require to literally reimplement full JS engine and compile it to WASM. It will work just slow. May be it's better to focus on features, which can improve developers efficiency, but wont affect code performance? Like for example high order functions. If someone will need full set of JS features, it will be much easier (and probably even more performant) to use just plain JS code. |
That's correct, just compiling JS to WASM doesn't make sense and AssemblyScript isn't doing it. This is somewhat outlined in limitations. The wiki might generally be of interest to you.
Well, without a GC there is no |
Is it possible in theory to implement manual memory managment? Another thought about that - people still need sometimes manual memory managment. For example in gamedev there is a pattern |
Manual memory management is implemented already. At this point it works by using import "allocator/tlsf";
@unmanaged
class SomeClass {
field: i32;
}
var myClass = changetype<SomeClass>(allocate_memory(sizeof<i32>()));
myClass.field = 42;
...
free_memory(changetype<usize>(myClass)); That's also how the allocators theirself are implemented. Unmanaged classes work just like structs (with methods), but you have to keep track of their sizes manually in most cases. For example there is no way to tell a |
Thank you, i've missed the part about @unmanaged
class SomeClass {
field: i32;
anotherField: i16;
}
sizeof<SomeClass>(); //compiled to const 6 If yes, it's probably enough to implement my case with ECS. |
At this point this is equivalent to Alternatively there could be something like a What I have been doing in the allocators so far is this: @unmanaged
class SomeClass {
field: i32;
anotherField: i16;
static readonly FIELD_OFFSET: usize = 0;
static readonly ANOTHERFIELD_OFFSET: usize = SomeClass.FIELD_OFFSET + sizeof<i32>();
static readonly SIZE: usize = SomeClass.ANOTHERFIELD_OFFSET + sizeof<i16>();
}
allocate_memory(SomeClass.SIZE); // compiles to `6`
@unmanaged
class AnotherClass extends SomeClass {
additionalField: i16;
static readonly ADDITIONALFIELD_OFFSET: usize= SomeClass.SIZE;
static readonly SIZE: usize= AnotherClass.ADDITIONALFIELD_OFFSET + sizeof<i16>();
}
allocate_memory(AnotherClass .SIZE); // compiles to `8` Just note that the offsets must be properly aligned (that is |
|
Well, if you have a need for it and are confident that it'll help you, I can make it return the computed class size. Just need to finish up what I am working on currently first :) |
But don't rush in any case, I don't really need this right now (just because i haven't even started to use ASC), i'm just trying to understand if this project will be usefull in the future, digging into code, play a little bit at web assembly studio etc, so lack of proper |
Yeah, I am a bit cautious when it comes to the roadmap because I had to throw away quite a few ideas already. Maybe projects can help? |
That was actually the way how i came to this issue. In any case it's better than nothing. Thank you for details! |
I took some time to update the status page, and tried to keep it a bit more high level as low-level details should be in projects now. Does this help? :) |
Yep, it's better now :) Last question here: what is the best way to communicate with you about this project? Create new issue about every question? Or ask you directly through any other website? For example i want to discuss contribution guidelines, it's really hard to understand how to run test properly after adding some code (looks like i need to copy-paste compiled code to .wat files, but it looks a bit weird) |
@dcodeIO Hmm, what about create slack or telegram channel about this project? |
@MaxGraey i totally for slack just because it doesn't require installing and it's simplier to copy-paste code snippets, markdown etc. |
Issues are great as others will be able to find the information as well then. Seems I'll have to update the test instructions as well. The way this works at this point is that you create a Creating fixtures is a bit inconsistent at this point because the parser suite can only regenerate all fixtures at once through Then rinse and repeat until you are confident that the fixture is correct. Running just |
To get back to the |
Closing in favor of #89 |
Enable GitLab CI
Ideally implemented in tandem with a memory manager.
If reference cycles can be figured out, an automatic reference counting variant seems like a good fit.
The text was updated successfully, but these errors were encountered: