-
Enhancement
-
Resolution: Fixed
-
P4
-
14
-
b11
I want to change/rename markOop and markOopDesc
Today markOopDescs inherits from oopDesc even though they are not oopDescs (Java objects):
`class markOopDesc : public oopDesc {`
This is very confusing to new-comers (and probably to old-timers as well).
A simple fix would be to break the inheritance and do the following rename:
markOopDesc -> MarkWord
markOop -> markWord
However, there are more dubious code in this area. markOopDescs are created and used like this:
```
class oopDesc {
...
volatile markOop _mark;
...
markOop oopDesc::mark_raw() const { return _mark; }
...
// Usage
obj->mark_raw()->is_marked()
...
// Implementation
bool is_marked() const {
return (mask_bits(value(), lock_mask_in_place) == marked_value);
}
...
// Implementation
bool is_being_inflated() const { return (value() == 0); }
...
// Implementation of markOopDesc::value()
uintptr_t value() const { return (uintptr_t) this; }
```
Remember, _mark is an arbitrary bit pattern describing the object. We treat it as if it were a pointer to a markOopDesc object, but it's not pointing to such an object. While using that (weird) pointer we call value() and extract it's bit pattern to be used for further bit pattern checking functions. AFAICT, this is also undefined behavior. At least is_being_inflated() const is effectively 'return (uintptr_t) this == NULL'. This UB was recently discussed here:
https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038704.html
https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038712.html
Revoked: "I propose that we change MarkWord (markOopDesc) to be an AllStatic class instead and get rid of this (ab)use of the markWord (markOop) pointer."
Revised: "I propose that we change markWord (markOopDesc) to contain an uintptr_t _value member and stop using the bit pattern of the this pointer"
Today markOopDescs inherits from oopDesc even though they are not oopDescs (Java objects):
`class markOopDesc : public oopDesc {`
This is very confusing to new-comers (and probably to old-timers as well).
A simple fix would be to break the inheritance and do the following rename:
markOopDesc -> MarkWord
markOop -> markWord
However, there are more dubious code in this area. markOopDescs are created and used like this:
```
class oopDesc {
...
volatile markOop _mark;
...
markOop oopDesc::mark_raw() const { return _mark; }
...
// Usage
obj->mark_raw()->is_marked()
...
// Implementation
bool is_marked() const {
return (mask_bits(value(), lock_mask_in_place) == marked_value);
}
...
// Implementation
bool is_being_inflated() const { return (value() == 0); }
...
// Implementation of markOopDesc::value()
uintptr_t value() const { return (uintptr_t) this; }
```
Remember, _mark is an arbitrary bit pattern describing the object. We treat it as if it were a pointer to a markOopDesc object, but it's not pointing to such an object. While using that (weird) pointer we call value() and extract it's bit pattern to be used for further bit pattern checking functions. AFAICT, this is also undefined behavior. At least is_being_inflated() const is effectively 'return (uintptr_t) this == NULL'. This UB was recently discussed here:
https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038704.html
https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038712.html
Revoked: "I propose that we change MarkWord (markOopDesc) to be an AllStatic class instead and get rid of this (ab)use of the markWord (markOop) pointer."
Revised: "I propose that we change markWord (markOopDesc) to contain an uintptr_t _value member and stop using the bit pattern of the this pointer"
- duplicates
-
JDK-8064885 Remove oopDesc inheritance relation from markOopDesc
-
- Closed
-
- relates to
-
JDK-8276453 Undefined behavior in C1 LIR_OprDesc causes SEGV in fastdebug build
-
- Resolved
-
-
JDK-8235362 Possible markWord performance issue on Windows
-
- Open
-
-
JDK-8274322 Problems with oopDesc construction
-
- Resolved
-
- links to
-
Review openjdk/jdk11u/23