search

mmtk / mmtk-core

Memory Management ToolKit
https://www.mmtk.io
Other
374 stars 68 forks source link

Allow unoptimized builds for bindings #353

Open qinsoon opened 3 years ago

qinsoon commented 3 years ago

Our current bindings (OpenJDK/JikesRVM/V8(?)) have optimizations to allow best performance (including embedding MMTk's mutator struct into their thread local storage, and genearting allocation fastpath with JIT). However, we should still allow the bindings to have an unoptimized build so a binding should be able to run any new GC from mmtk-core without any change to the binding (or minimal changes that anyone can do without deep knowledge about the binding). This would be helpful to people who implement new GCs in mmtk-core and could use a bindng to test its correctness.

The unoptimized build should not depend on the layout of any mmtk-core struct (e.g. they can save opaque pointers to mmkt-core structs). The unoptimized build should not generate allocation fastpath.

This issue tracks this issue in general and any changes required for mmtk-core. We should have separate issues for each binding in the binding repo.

wks commented 10 months ago

This issue should be moved to concrete bindings (OpenJDK and others) because the Rust structs that depend on the layout of C++ classes/structs are not in mmtk-core. It currently on affects the OpenJDK binding.

wks commented 10 months ago

I think we still need to discuss having bindings that do not depend on the struct layouts of anything in mmtk-core, for testing purposes.

Recent changes, includes the introduction of AllocatorInfo and BumpPointer, have made this much easier.