1) Separate the space type flags from the GC related flags;
2) the space type flags should be exclusive with each other, hence we shouldn't make them denoted
by specific dedicated bits respectively, because in that way we can't avoid multiple bits being set,
which is not what we expect.
3) the GC related flags are kept using dedicated flag bit for now. Going forward we should continuouslly
improve this, e.g., to check if some of these flags are also exclusive with each other, and to better
separate them from the space type flags with separately declared types, etc.
4) The judgement of whether an object is containted in the heap is _somehow_ improved, but as mentioned
in the code comments, it's still not safe and accurate enough, be careful when using it.
Issue: https://gitee.com/openharmony/ark_js_runtime/issues/I590Z8
Signed-off-by: Yuqiang Xian <xianyuqiang@huawei.com>
Currently there's an "implicit" assumption wide spread in a lot of places in the code,
that the region object is allocated in the JS heap together with the associated region
memory it manages (i.e., the C++ region object itself is treated as the header of the
associated memory region), but after all, from a normal user's perspective, it's still
a normal C++ object, and thus introduces a lot of confusions and it's very easy to
break the system with usages which are not "implicitly" expected.
This patch tries to relax the assumption / limitation, and the mostly affected usage case
is snapshot serialization / deserialization, which is refactored to not rely on that
implicit assumption.
Issue: https://gitee.com/openharmony/ark_js_runtime/issues/I590Z8
Signed-off-by: Yuqiang Xian <xianyuqiang@huawei.com>
1) Get rid of the dependency on "Space";
2) Fix a bug in RegionFlags definition, and tidy it up.
3) Fix the flag check logic to make it support multi-bit test;
4) Clean-up some logic to determine if a region or an object is valid / alive;
Issue: https://gitee.com/openharmony/ark_js_runtime/issues/I590Z8
Signed-off-by: Yuqiang Xian <xianyuqiang@huawei.com>
wengchangcheng