Hi,<div><br></div><div>We will need a few supporters and a spec before a prototype. Will you be willing to support drafting a speck and volunteer for developing the prototype?</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><span style="font-family:'arial narrow',sans-serif">▣ </span><b style="font-family:'arial narrow',sans-serif"><i>Mobile</i></b><span style="font-family:'arial narrow',sans-serif">: +94-(0)711007945 </span><span style="font-family:'arial narrow',sans-serif">▣ </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></div>
<div dir="ltr"><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 May 2013 14:30, Clemens Eisserer <span dir="ltr"><<a href="mailto:linuxhippy@gmail.com" target="_blank">linuxhippy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Time to start writing a prototype - looking forward to your implementation :)<br>
<br>
Regards, Clemens<br>
<br>
2013/5/20 Suminda Dharmasena <<a href="mailto:sirinath@sakrio.com">sirinath@sakrio.com</a>>:<br>
<div class="HOEnZb"><div class="h5">> Hi,<br>
><br>
> I am looking to see if we can introduce user control for memory management<br>
> and more finer resource management ability through annotations and API.<br>
><br>
> Part of the discussion on this is in the comment section of the following<br>
> blog which I had with David Homes:<br>
> <a href="https://blogs.oracle.com/dholmes/entry/minimize_garbage_generation" target="_blank">https://blogs.oracle.com/dholmes/entry/minimize_garbage_generation</a><br>
><br>
> Many Java objects can either be allocated on the stack as well as deleted if<br>
> allocated in the heap without it being passed for GC. Since stack allocation<br>
> will only work for some objects and will break the current memory model an<br>
> annotation can be introduced to mark stack allocation. Any contained objects<br>
> cannot outlive the containing object in this case unless they are annotated<br>
> to escape. Escaping objects can be heap allocated and collected through the<br>
> normal GC process.<br>
><br>
> If an object is heap allocated it can be deleted at define points like block<br>
> exit, return or end of iteration (in loops) etc. Appropriate annotation can<br>
> be introduced to mark the deletion. In this case contained objects can out<br>
> live the containing object. The objects that cannot be deleted will be<br>
> marked for GC during the normal GC cycle. Also an annotation can be<br>
> introduced to help mark fields and methods which might escape and which does<br>
> not statically. For methods all parameters, local variables and returned<br>
> objects will not escape thus can be deleted after method returns. For<br>
> methods parameters, any objects passed will not escape and can be safely<br>
> deleted after method returns. Not all parameters may be marked. For fields,<br>
> the objects can be deleted when the containing object is deleted. These<br>
> objects if returned from a method will be clones and any pass to methods<br>
> which are not marked for non escape would be clones else the compiler should<br>
> complain. For local variables, they can be deleted when method returns or go<br>
> out of scope. Also for return values an annotation to mark the return value<br>
> safe to delete after returning and to mark that fields and methods in a<br>
> class do not escape.<br>
><br>
> There can be finer grain of specification on what the type of containment is<br>
> and what the escape is. Traditionally this might be thread, stack, etc. but<br>
> in this case we are more concerned with containment within the containing<br>
> object for field and containment when calling methods with regard to<br>
> parameters, local variables and return types.<br>
><br>
> In a nutshell we should be able to specify the lifetime of an object at<br>
> point of declaration so it gets deleted when its usefulness is over. Only<br>
> the occasional object that escapes this will need to be GCed.<br>
><br>
> More fine grain resource management can be done through annotation like<br>
> calling close() before trying to GC with appropriate annotations.<br>
><br>
> Also appropriate API can be defined also to perform some of the memory<br>
> management operations.<br>
><br>
> For further examples of possible annotations see the discussion on:<br>
> <a href="https://blogs.oracle.com/dholmes/entry/minimize_garbage_generation" target="_blank">https://blogs.oracle.com/dholmes/entry/minimize_garbage_generation</a><br>
><br>
> Also ability to turn off GC within a code block or function unless an<br>
> outofmemory error happens.<br>
><br>
> This would leave lesser workload for the GC system. Large part of memory<br>
> management workload will be at know at appropriate point in code (if the<br>
> programmer is disciplined). In GCing we do not know where the execution is<br>
> when GC happens. If this is in latency sensitive code block you are in<br>
> trouble. This way the developer is in true partnership with the GC and<br>
> memory management system.<br>
><br>
> Suminda<br>
> --<br>
> Suminda Sirinath Salpitikorala Dharmasena, B.Sc. Comp. & I.S. (Hon.) Lond.,<br>
> P.G.Dip. Ind. Maths. J'Pura, MIEEE, MACM, CEO Sakrīō! ▣ Address: 6G • 1st<br>
> Lane • Pagoda Road • Nugegoda 10250 • Sri Lanka. ▣ Mobile: <a href="tel:%2B94-%280%29711007945" value="+94711007945">+94-(0)711007945</a><br>
> ▣ Tele: +94-(0)11-5 864614 / 5 875614 / 2 825908 ▣ Web:<br>
> <a href="http://www.sakrio.com" target="_blank">http://www.sakrio.com</a> ▣<br>
><br>
> This email is subjected to the email Terms of Use and Disclaimer:<br>
> <a href="http://www.sakrio.com/email-legal" target="_blank">http://www.sakrio.com/email-legal</a>. Please read this first.<br>
> --<br>
</div></div></blockquote></div><br></div>