Details
-
Type:
New Feature
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 3.0
-
Component/s: Compiler: Baseline, Compiler: Optimizing, MMTk
-
Labels:None
-
Number of attachments :
Description
Our most frequent error on x86 is back to being a bad object reference being traced by the GC. The number of places we create object references are limited. We either load them or create them from objects. In the compiler we can create checks that ensure that an object reference that is loaded or converted from an object is well formed. A well formed object reference should be a nullReference or:
1) have a non-null TIB
2) the TIB should be of type TIB
3) have a TIB where we can read the type of the object
it would be nice to have non-null allowing variants of the creation routines for places where the GC assumes a reference cannot be null. If there are other places we can insert extra checks then please let me know.
This process comes from the thought that if MMTk manipulated objects that represented the state being manipulated then we could check when the state of such objects becomes corrupt. Obviously this technique is intended for non-production use.
Issue Links
Activity
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Status | Resolved [ 5 ] | Closed [ 6 ] |
Another way to create ObjectReferences is to convert an Address into and ObjectReference. Since Address supports plus, any Address can be made and thus any ObjectReference. I currently use invalid ObjectReferences at one point in some of the code I'm working on to reuse a field in the MiscHeader that no longer needs to serve it's primary purpose without having to write a second function that takes different arguments. So it's possible there might be other cases where invalid ObjectReferences created from Addresses could be useful.