Lifetime Issues #11

New Issue

pca006132 · 2021-05-20T17:36:51+08:00

pca006132 commented

2021-05-20 17:36:51 +08:00

Current Implementation

Runs after type checking, before IR generation.

Ideas:

Three ways for pointer to escape:
1. Assigning to another object.
  Solution: Ensures outlive relationship between LHS and RHS.
2. Returning to the caller.
  Solution: Only allow returning values that live forever.
3. Raising an exception containing the pointer.
  Solution: Disallow returning exceptions that refer to mutable data.
The current algorithm check the lexical scope of variables, validate the outlive relationship for assignments.
For expressions like the if expressions which may be evaluated to multiple objects, it would choose the shortest living operand.

Currently very buggy:

compiler: Function return values (?) not life-time-tracked
Long standing issue, fix is simple but is not yet fixed because global lifetime needs special handling.
Unsound parameter lifetime handling
Issue found today after reading the code. The lifetime of different parameters should be incomparable instead of the same, as they can come from different callers.
List elements not lifetime-tracked
Also found today... This would also affects object with fields.
Choosing the shortest living operand is unsound:
- Variable a Lifetime: Global / Local (selected with if expression).
- Variable b Lifetime: Local.
- By choosing shortest living operand, lifetime of a is considered as local.
- a.foo = b is now legal as b outlives local lifetime.

The later 3 bugs probably require algorithmic changes, simple fixes are not sufficient.

Other Ideas

We probably want a sound system with less restrictive lifetime.

Rust like ownership and lifetime, with type annotation.
- Probably need quite some annotations.
Static analysis, analyze the points-to set of each variables and validate against the rules.

# Current Implementation Runs after type checking, before IR generation. Ideas: - Three ways for pointer to escape: 1. Assigning to another object. Solution: Ensures outlive relationship between LHS and RHS. 2. Returning to the caller. Solution: Only allow returning values that live forever. 3. Raising an exception containing the pointer. Solution: Disallow returning exceptions that refer to mutable data. - The current algorithm check the lexical scope of variables, validate the outlive relationship for assignments. - For expressions like the if expressions which may be evaluated to multiple objects, it would choose the shortest living operand. Currently very buggy: - [compiler: Function return values (?) not life-time-tracked](https://github.com/m-labs/artiq/issues/1497) Long standing issue, fix is simple but is not yet fixed because global lifetime needs special handling. - [Unsound parameter lifetime handling](https://github.com/m-labs/artiq/issues/1677) Issue found today after reading the code. The lifetime of different parameters should be incomparable instead of the same, as they can come from different callers. - [List elements not lifetime-tracked](https://github.com/m-labs/artiq/issues/1678) Also found today... This would also affects object with fields. - Choosing the shortest living operand is unsound: - Variable `a` Lifetime: Global / Local (selected with if expression). - Variable `b` Lifetime: Local. - By choosing shortest living operand, lifetime of `a` is considered as local. - `a.foo = b` is now legal as `b` outlives local lifetime. The later 3 bugs probably require algorithmic changes, simple fixes are not sufficient. # Other Ideas We probably want a sound system with less restrictive lifetime. 1. Rust like ownership and lifetime, with type annotation. - Probably need quite some annotations. 2. Static analysis, analyze the points-to set of each variables and validate against the rules.

lifetime.pdf

58 KiB

Sign in to join this conversation.

No Label

No Milestone

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: M-Labs/nac3-spec#11