(r15) LCS2016_030 < P1076

P1076 Web>VHDL2017>LCS2016_030 (revision 15) (raw view)~~EditAttach~~
---+ Language Change Specification for Garbage Collection

---++ 

| <sticky><b>LCS Number:</b></sticky> | LCS-2016-030 |
| <sticky><b>Version:</b>   </sticky> | 1 {21-Jan-2017} <span data-mce-mark="1">%BR%</span> 2 {08-Feb-2017} |
| <sticky><b>Date:</b>      </sticky> | 08-Feb-2017  |
| <sticky><b>Status:</b>    </sticky> | Voting |
| <sticky><b>Author:</b>    </sticky> | Patrick Lehmann |
| <sticky><b>Email:</b>     </sticky> | [[Main.PatrickLehmann]] |
| <sticky><b>Source Doc:</b></sticky> | [[GarbageCollection][Garbage Collection]] |
| <sticky><b>Summary:</b>   </sticky> | Allow Garbage Collection. |

---+++ Voting Results: Cast your votes here

Yes:
   1 <span data-mce-mark="1">%USERSIG{PatrickLehmann - 2017-02-08}%</span> - ver 2
   1 <span data-mce-mark="1">%USERSIG{LievenLemiengre - 2017-01-27}%</span> - ver 1
   1 <span data-mce-mark="1">%USERSIG{HendrikEeckhaut - 2017-01-27}%</span> ver 1
   1 <span data-mce-mark="1">%USERSIG{MartinZabel - 2017-02-08}%</span> - ver 2
   1 <span data-mce-mark="1">%USERSIG{JimLewis- 2017-02-09}%</span> - ver 2 With deprecate message gone.
   1 %USERSIG{RobGaddi - 2017-02-12}% - ver 2
   1 %USERSIG{ThomasPreusser - 2017-02-13}% - ver 2
   1 %USERSIG{FarrellOstler - 2017-02-14}% - ver 2

No:
   1 

Abstain:
   1 %USERSIG{BrentHahoe - 2017-02-16}% Version 2 - Abstain due to lack of personal time for review.

---++ Style Notes

<noautolink>

<sticky>
Changes are shown in %RED%red font%ENDCOLOR%.%BR%
Deletions are %RED%<del>crossed out</del>%ENDCOLOR%.%BR%
Editing or reviewing notes in %GREEN%green font%ENDCOLOR%.
 
---++ 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. %RED%<del>This deallocation operation
makes it possible to deallocate explicitly the storage occupied by a designated object.</del>%ENDCOLOR%

Given the following access type declaration:

<pre>
<b>type</b> AT <b>is access</b> T;
</pre>

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

<pre>
<b>procedure</b> DEALLOCATE (P: <b>inout</b> AT);
</pre>

Procedure DEALLOCATE takes as its single parameter a variable of the specified access type. %RED%<del>If the value
of that variable is the null value for the specified access type, then t</del> T%ENDCOLOR%he operation has no effect %RED%<del>. 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 </del>other than the %ENDCOLOR% 
access parameter P is set to the null value for the specified type.

%RED%<del>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.</del>%ENDCOLOR%

%RED%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.%ENDCOLOR%


---+++ (030.2) 9.3.7 Allocators
%GREEN%[...]%ENDCOLOR%

%RED%<del>In the absence of explicit deallocation, a</del>A%ENDCOLOR%n 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.

%GREEN%[Reviewer note: Demand garbage collection]%ENDCOLOR%

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


---++ 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.

-- %BUBBLESIG{JimLewis - 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.

-- %BUBBLESIG{PatrickLehmann - 2017-01-22}%


I&#39;d go even farther than Jim.  An explicit call to DEALLOCATE is currently a means of saying &#34;I don&#39;t care whether you think this object is in use or not, I&#39;m telling you to get rid of it.&#34;  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.

-- %BUBBLESIG{RobGaddi - 2017-01-26}%


On second thought, DEALLOCATE isn&#39;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&#39;t broke.

-- %BUBBLESIG{RobGaddi - 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&#39;t think that DEALLOCATE should be &#34;flagged&#34; for possible future removal from VHDL.(The opposite view on both points has merit from a standpoint of &#34;tidiness&#34; but considerations of backward compatibility should outweigh this.)

I hope to vote Yes on an eventual LCS.

-- %BUBBLESIG{FarrellOstler - 2017-01-26}%


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

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

Thus, there is no need to deprecate DEALLOCATE, it is just another form of assigning &#34;null&#34;.

-- %BUBBLESIG{MartinZabel - 2017-01-27}%



Patrick updated to version 2

-- %BUBBLESIG{JimLewis - 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: &#34;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 [...]&#34;. Currently, the simulation kernel has to return the occupied storage of an object back to the *system*. 

-- %BUBBLESIG{PatrickLehmann - 2017-02-12}%


Thanks for the clarification. Switching over to *yes*.

-- %BUBBLESIG{ThomasPreusser - 2017-02-13}%


Changing vote from &#34;no&#34; on version 1 to &#34;yes&#34; on version 2.

-- %BUBBLESIG{FarrellOstler - 2017-02-15}%
%COMMENT%</sticky>

</noautolink>
Topic revision: r1 - 2017-07-25 - 01:43:22 - TWikiGuest
P1076