P4
Issues with current implementation:
1. We have an exception mark, so any call to `obj_at` will exit the VM if we run out of memory.
2. A lot of the callers to `objArrayOopDesc::obj_at` do no expect safepoints.
3. If an element is read inside of a safepoint operation, we can not rely on running GC. Hence, whether the allocation will succeed or not is random. It might be that we carefully avoid reading flat values from inside of safepoint operations though.
Investigate removal of `flatArrayOopDesc::obj_at(int index)` and `objArrayOopDesc::obj_at(int index)` and only expose `objArrayOopDesc::obj_at(int index, TRAPS)`.
1. We have an exception mark, so any call to `obj_at` will exit the VM if we run out of memory.
2. A lot of the callers to `objArrayOopDesc::obj_at` do no expect safepoints.
3. If an element is read inside of a safepoint operation, we can not rely on running GC. Hence, whether the allocation will succeed or not is random. It might be that we carefully avoid reading flat values from inside of safepoint operations though.
Investigate removal of `flatArrayOopDesc::obj_at(int index)` and `objArrayOopDesc::obj_at(int index)` and only expose `objArrayOopDesc::obj_at(int index, TRAPS)`.