Hi,<div><br></div><div>Many objects created locally and final static / constructor initialized composition objects in the locally created object can be allocated in the stack thus with proper compile time escape analysis in a language like java which does not have pointer aliasing can eliminate the need of a GC for about 90 % of the cases.</div>
<div><br></div><div>Introducing these semantics will ensure this as current java model defaults to heap allocation. Also giving control at what point to adjust the stack frame thus the memory allocated to the objects are claimed. This will increase Java's appeal for small memory embedded RT systems as GC will become the last resort fall back and many objects will not need to be GCed.</div>
<div><br></div><div>IMO, the runtime overhead of complicated GC mechanisms are not warranted as the objects that really needed to be allocated on the heap are static fields and fields that not final and cannot be declared final. Many fixed size non final objects also can be stack allocated. When they get updated the object needs to be replaced in the relevant stack frame. Also analysis could check if an object that escapes the current stack frame makes its way to a parent stack frame. This way provisions can be made to allocate in the parent frame.</div>
<div><br></div><div>Also many of the stack allocated objects need not be finalised unless the object's finalizer method is overridden. This will reduce memory reclaim overhead. </div><div><br></div><div>With regard to heap allocated objects the GC can also happen at defined intervals. E.g. if an object is marked GCOnReturn if the return object is not utilised after return it is GCed. Also GCOnBlockExit will ensure all objects in a loop be GCed.</div>
<div><br></div><div>Suminda<br clear="all">
<div><div dir="ltr"><div><span style="font-family:'arial narrow',sans-serif">--</span></div><span style="font-family:'arial narrow',sans-serif">Suminda Sirinath Salpitikorala Dharmasena</span><span style="font-family:'arial narrow',sans-serif">, B.Sc. Comp. & I.S. (Hon.) Lond., P.G.Dip. Ind. Maths. J'Pura, MIEEE, MACM</span><span style="font-family:'arial narrow',sans-serif">, CEO </span><span style="font-family:'comic sans ms',sans-serif">Sakrīō!</span><span style="font-family:'arial narrow',sans-serif"> </span><span style="font-family:'arial narrow',sans-serif">▣ </span><b style="font-family:'arial narrow',sans-serif"><i>Address</i></b><span style="font-family:'arial narrow',sans-serif">: 6G • 1st Lane • Pagoda Road • Nugegoda 10250 • Sri Lanka. ▣ </span><b style="font-family:'arial narrow',sans-serif"><i>Tele</i></b><span style="font-family:'arial narrow',sans-serif">: +94-(0)11-5 864614 / 5 875614 / 2 825908 ▣ <b><i>Web</i></b>: <a href="http://www.sakrio.com" target="_blank">http://www.sakrio.com</a> </span><span style="font-family:'arial narrow',sans-serif">▣</span><br style="font-family:'arial narrow',sans-serif">
<br><div><font face="arial narrow, sans-serif">This email is subjected to the email Terms of Use and Disclaimer: <a href="http://www.sakrio.com/email-legal" target="_blank">http://www.sakrio.com/email-legal</a>. Please read this first.</font></div>
<div><font face="arial narrow, sans-serif">--</font></div></div></div>
<br><br><div class="gmail_quote">On 20 April 2013 00:23, Bernd Eckenfels <span dir="ltr"><<a href="mailto:bernd-2013@eckenfels.net" target="_blank">bernd-2013@eckenfels.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="color:#777;font-size:12px;font-family:'Lucida Grande',Helvetica,Arial,sans-serif;padding:4px">
<a href="https://www.boxbe.com/overview" style="text-decoration:none;color:#5e96ea" target="_blank"><img alt="Boxbe" width="64px" style="margin-left:0px;border:none"></a>
<img>
Bernd Eckenfels (<a href="mailto:bernd-2013@eckenfels.net" target="_blank">bernd-2013@eckenfels.net</a>) is not on <a style="text-decoration:none;color:#5e96ea" href="https://www.boxbe.com/approved-list?tc_serial=13987150962&tc_rand=1830316824&utm_source=stf&utm_medium=email&utm_campaign=ANNO_MWTP&utm_content=001&token=ERETQw2iSwWyZqUVy76d2X7D%2F%2F1UN2fq1vBQ3U05A610e9%2BPq6fzfA1%2BIWsiZ6IC&key=tCvAXRTXiRsJgeiodBg7x4xQ4kT9uFWND969c4eXeK8%3D" target="_blank">your Guest List</a>
| <a style="text-decoration:none;color:#5e96ea" href="https://www.boxbe.com/anno?tc_serial=13987150962&tc_rand=1830316824&utm_source=stf&utm_medium=email&utm_campaign=ANNO_MWTP&utm_content=001&token=ERETQw2iSwWyZqUVy76d2X7D%2F%2F1UN2fq1vBQ3U05A610e9%2BPq6fzfA1%2BIWsiZ6IC&key=tCvAXRTXiRsJgeiodBg7x4xQ4kT9uFWND969c4eXeK8%3D" target="_blank">Approve sender</a>
| <a style="text-decoration:none;color:#5e96ea" href="https://www.boxbe.com/anno?tc_serial=13987150962&tc_rand=1830316824&utm_source=stf&utm_medium=email&utm_campaign=ANNO_MWTP&utm_content=001&dom&token=ERETQw2iSwWyZqUVy76d2X7D%2F%2F1UN2fq1vBQ3U05A610e9%2BPq6fzfA1%2BIWsiZ6IC&key=tCvAXRTXiRsJgeiodBg7x4xQ4kT9uFWND969c4eXeK8%3D" target="_blank">Approve domain</a>
<br>
</div>
<br>Am 19.04.2013, 10:06 Uhr, schrieb Suminda Dharmasena <<a href="mailto:sirinath@sakrio.com" target="_blank">sirinath@sakrio.com</a>>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- GCAtBlockEnd<br>
- GCAtBlockExit - for loops the GC happens when the<br>
- GCAtLastReference<br>
- GCAtEndOfScope<br>
- GCOnAssignment<br>
- GCOnReturn<br>
</blockquote>
...<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
At each point the objects pointed by the handle are GCed if there is<br>
a possibility (reference count becomes 0). If a reference to an object is<br>
specified to be<br>
</blockquote>
<br>
I think most of those annotations are not possible with modern GCs. You need to be aware that there is no reference counting and there is already Escape Analysis, Nursery and Thread Local allocations dealing with most of the scopes you listed above anyway.<br>
<br>
Greetings<br>
Bernd<br>
-- <br>
<a href="http://bernd.eckenfels.net" target="_blank">http://bernd.eckenfels.net</a><br>
<br></blockquote></div><br></div>