Language Change Specification for Garbage Collection

LCS Number:	LCS-2016-030
Version:	1 {21-Jan-2017} 2 {08-Feb-2017}
Date:	08-Feb-2017
Status:	Voting
Author:	Patrick Lehmann
Email:	Main.PatrickLehmann
Source Doc:	Garbage Collection
Summary:	Allow Garbage Collection.

Voting Results: Cast your votes here

Yes:

1. Patrick Lehmann - 2017-02-08 - ver 2
2. Lieven Lemiengre - 2017-01-27 - ver 1
3. Hendrik Eeckhaut - 2017-01-27 ver 1
4. Martin Zabel - 2017-02-08 - ver 2
5. Jim Lewis- 2017-02-09 - ver 2 With deprecate message gone.
6. Rob Gaddi - 2017-02-12 - ver 2
7. Thomas Preusser - 2017-02-13 - ver 2
8. Farrell Ostler - 2017-02-14 - ver 2

No:

Abstain:

1. Brent Hayhoe - 2017-02-16 Version 2 - Abstain due to lack of personal time for review.

Style Notes

Changes are shown in red font.
Deletions are crossed out.
Editing or reviewing notes in green font.

Reviewing Notes

TODO

Details of Language Change

(030.1) 5.4.3 Allocation and deallocation of objects

An object designated by an access value is allocated by an allocator for that type. An allocator is a primary of an expression; allocators are described in 9.3.7. For each access type, a deallocation operation is implicitly declared immediately following the full type declaration for the type. This deallocation operation makes it possible to deallocate explicitly the storage occupied by a designated object.

Given the following access type declaration:

type AT is access T;

the following legacy operation is implicitly declared immediately following the access type declaration:

procedure DEALLOCATE (P: inout AT);

Procedure DEALLOCATE takes as its single parameter a variable of the specified access type. If the value of that variable is the null value for the specified access type, then t The operation has no effect . If the value of that variable is an access value that designates an object, the storage occupied by that object is returned to the system and may then be reused for subsequent object creation through the invocation of an allocator. The other than the access parameter P is set to the null value for the specified type.

NOTE -- If an access value is copied to a second variable and is then deallocated, the second variable is not set to null and thus references invalid storage.

NOTE -- If an access value is copied to a second variable and is then deallocated, the first variable is set to null, however, the designated object remains allocated and the second variable still designates the object.

(030.2) 9.3.7 Allocators

[...]

In the absence of explicit deallocation, aAn implementation shall guarantee that any object created by the evaluation of an allocator remains allocated for as long as this object or one of its subelements is accessible directly or indirectly; that is, as long as it can be denoted by some name.

NOTE 1 -- Procedure deallocate is implicitly declared for each access type. This procedure provides a mechanism for explicitly deallocating the storage occupied by an object created by an allocator.

[Reviewer note: Demand garbage collection]

NOTE 2 -- An implementation may (but need not)should deallocate the storage occupied by an object created by an allocator. , once this object has become inaccessible. Deallocation may be delayed by the implementation.

Comments

** Every program that currently does allocation currently calls deallocate. I consider it problematic if an implementation would not allow an explicit call to deallocate as an indication it is time to check the object and discard it if it is appropriate. No warning is warranted for this sort of action.

-- Jim Lewis - 2017-01-21

Old code is still working. Calling reallocated has almost no effect, but increases runtime.

It is considered bad practice in software development if a user is not warned about using deprecated subprograms.

-- Patrick Lehmann - 2017-01-22

I'd go even farther than Jim. An explicit call to DEALLOCATE is currently a means of saying "I don't care whether you think this object is in use or not, I'm telling you to get rid of it." I feel like that should continue to be the case, especially since it might be necessary to break a circular reference. No reason to deprecate it; old code for which the memory allocation/deallocation used to work correctly will still just work correctly.

That would collapse this entire LCS down to just: NOTE 2 -- An implementation should deallocate the storage occupied by an object created by an allocator once this object has become inaccessible. Deallocation may be delayed by the implementation.

Which would be a very small change for a very big change.

-- Rob Gaddi - 2017-01-26

On second thought, DEALLOCATE isn't necessary for circular references, you can just break the links by setting some nulls. My point about leaving DEALLOCATE active persists though, it seems like a thing that ain't broke.

-- Rob Gaddi - 2017-01-26

I vote No at present (Version 1) because I would prefer not to have a mandatory warning when DEALLOCATE is used and I don't think that DEALLOCATE should be "flagged" for possible future removal from VHDL.(The opposite view on both points has merit from a standpoint of "tidiness" but considerations of backward compatibility should outweigh this.)

I hope to vote Yes on an eventual LCS.

-- Farrell Ostler - 2017-01-26

PL Calling reallocated has almost no effect, but increases runtime.

MZ I think you meant "deallocate" instead of "reallocated". No it doesn't have an effect on the runtime, because the call of DEALLOCATE(x) can now be just replaced by "x := null;" (which must be done anyway).

Thus, there is no need to deprecate DEALLOCATE, it is just another form of assigning "null".

-- Martin Zabel - 2017-01-27

Patrick updated to version 2

-- Jim Lewis - 2017-02-10

TBP: cannot see any utility

PL: Switching from manual memory management to GC based memory management removes the possibility to get segmentation faults from the language.

TBP: GC is already possible now

PL: See here: "If the value of that variable is an access value that designates an object, the storage occupied by that object is returned to the system [...]". Currently, the simulation kernel has to return the occupied storage of an object back to the system.

-- Patrick Lehmann - 2017-02-12

Thanks for the clarification. Switching over to yes.

-- Thomas Preusser - 2017-02-13

Changing vote from "no" on version 1 to "yes" on version 2.

-- Farrell Ostler - 2017-02-15