Implement reference counting and/or garbage collection about assemblyscript HOT 19 CLOSED

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 u32 internal classId (optionally with a few additional tag bits), while unmanaged objects would not. Bonus: With such a classId it'll also become possible to implement instanceof.

from assemblyscript.

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.

from assemblyscript.

Full implementation of all JS semantic will require to literally reimplement full JS engine and compile it to WASM

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.

May be it's better to focus on features, which can improve developers efficiency

Well, without a GC there is no new and if there is no new there can't be proper arrays, strings and other classes. It's not that hard to build one that works and doesn't suck.

from assemblyscript.

Well, without a GC there is no new and if there is no new there can't be proper arrays, strings and other classes. It's not that hard to build one that works and doesn't suck.

Is it possible in theory to implement manual memory managment? new operator will just allocate new object in the heap. But I don't know about manual deleting - it's possible to create kind of function free(), which will deallocate object, but such code probably wont be compatible with current js/ts semantic.

Another thought about that - people still need sometimes manual memory managment. For example in gamedev there is a pattern entity component system (ECS), which relies on manual memory allocation, to store related data, such as position vectors of all game objects in one big array, it makes algorythms cache-friendly and very performant. ECS doesn't use OOP at all, so most common data structure there is an array of structs. All logic is detached from data and stored in game systems, so data structs doesn't have (and even need) methods at all. For such patterns people needs to use custom memory allocation and of cource struct support (it probably can be achieved by classes without methods). This structs shouldn't be affected by GC at all. It will be hard to implement true ECS with enforced GC, so it would be nice to have possibility to use classes and objects like a just C/C++ structs, without methods, GC and other such stuff.

from assemblyscript.

Is it possible in theory to implement manual memory managment? new operator will just allocate new object in the heap. But I don't know about manual deleting - it's possible to create kind of function free(), which will deallocate object, but such code probably wont be compatible with current js/ts semantic.

Manual memory management is implemented already. At this point it works by using allocate_memory and free_memory, like so:

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 field: string[] how many items it is supposed to contain in TypeScript, that's why it's always a pointer. You can work around this to some degree with custom offset management (calculating, then using load<T>, store<T>). The std/allocator sources might be good examples.

from assemblyscript.

Thank you, i've missed the part about @unmanaged annotation. Is it possible to use sizeof like this?

@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.

from assemblyscript.

sizeof<SomeClass>()

At this point this is equivalent to sizeof<usize>() and while it isn't that hard to make it return the class size, returning the size computed by the compiler will not match anymore once a developer decides to do some things with manual offsets. To support this, there should at least be two additional internal decorators @size(nBytes) for the class (when using custom offset management) and @offset(index) on members (to simplify custom offset management), that sizeof<T> would then take into account when doing its computations. So, not yet.

Alternatively there could be something like a StaticArray<T,count> type, or whatnot. As you see this all boils down to TypeScript not supporting such things syntactically, or being hard to polyfill in portable code.

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 i16 to 2 bytes etc.).

from assemblyscript.

@offset(index) for me it's rare case and at the beginning it will be enough to just calculate with default offsets, like it works for structs in C/C++. And it's really needed feature, since hand-written sum of fields could be wrong because of aligning (i don't know if field aligning is already implemented). So sizeof will be really helpfull and more error-prone than manual size calculation

from assemblyscript.

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 :)

from assemblyscript.

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 sizeof doesn't block me at all. I just want to understand roadmap and which features you are trying to focus first (thats why i've asked you about GC above). There is no any clear roadmap, i can find only checklist of features to implement, but it doesn't look like a plan.

from assemblyscript.

There is no any clear roadmap, i can find only checklist of features to implement, but it doesn't look like a plan.

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?

from assemblyscript.

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!

from assemblyscript.

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? :)

from assemblyscript.

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)

from assemblyscript.

@dcodeIO Hmm, what about create slack or telegram channel about this project?

from assemblyscript.

@MaxGraey i totally for slack just because it doesn't require installing and it's simplier to copy-paste code snippets, markdown etc.

from assemblyscript.

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 .ts file in either tests/parser or tests/compiler and generate a fixture from it. For development, you should run npm run clean once so test suites pick up the source files instead of the dist files.

Creating fixtures is a bit inconsistent at this point because the parser suite can only regenerate all fixtures at once through npm run test:parser -- --create but the compiler suite can do it for individual tests like npm run test:compiler -- mynewtest --create.

Then rinse and repeat until you are confident that the fixture is correct. Running just npm run test:parser or npm run test:compiler runs the tests.

from assemblyscript.

To get back to the sizeof<T> issue above: There's now offsetof<SomeClass>("someFieldName") that returns the computed offset of that field. If the field name is omitted (offsetof<SomeClass>()), it returns the computed offset after the last field that the compiler would use as the base offset of an additional field, if it'd exist, before alignment. The value returned in this case is equal to the class's computed size in memory.

from assemblyscript.

Closing in favor of #89

from assemblyscript.