Object Lifetime Specification
sirinath at sakrio.com
Sun May 19 23:57:42 PDT 2013
As a matter of clarification the scheme I am proposing is to be able to
specify the life time of an object after which it is deleted.
Let me know your interests. Further details are below.
Suminda Sirinath Salpitikorala Dharmasena, B.Sc. Comp. & I.S. (Hon.) Lond.,
P.G.Dip. Ind. Maths. J'Pura, MIEEE, MACM, CEO Sakrīō! ▣ *Address*: 6G • 1st
Lane • Pagoda Road • Nugegoda 10250 • Sri Lanka. ▣ *Mobile*
: +94-(0)711007945 ▣ *Tele*: +94-(0)11-5 864614 / 5 875614 / 2 825908 ▣ *Web
*: http://www.sakrio.com ▣
http://www.sakrio.com/email-legal. Please read this first.
On 19 May 2013 20:48, Suminda Dharmasena <sirinath at sakrio.com> wrote:
> I am looking to see if we can introduce user control for memory management
> and more finer resource management ability through annotations and API.
> Part of the discussion on this is in the comment section of the following
> blog which I had with David Homes:
> Many Java objects can either be allocated on the stack as well as deleted
> if allocated in the heap without it being passed for GC. Since stack
> allocation will only work for some objects and will break the current
> memory model an annotation can be introduced to mark stack allocation. Any
> contained objects cannot outlive the containing object in this case unless
> they are annotated to escape. Escaping objects can be heap allocated
> and collected through the normal GC process.
> If an object is heap allocated it can be deleted at define points like
> block exit, return or end of iteration (in loops) etc. Appropriate
> annotation can be introduced to mark the deletion. In this case contained
> objects can out live the containing object. The objects that cannot be
> deleted will be marked for GC during the normal GC cycle. Also an
> annotation can be introduced to help mark fields and methods which might
> escape and which does not statically. For methods all parameters, local
> variables and returned objects will not escape thus can be deleted after
> method returns. For methods parameters, any objects passed will not escape
> and can be safely deleted after method returns. Not all parameters may be
> marked. For fields, the objects can be deleted when the containing object
> is deleted. These objects if returned from a method will be clones and any
> pass to methods which are not marked for non escape would be clones else
> the compiler should complain. For local variables, they can be deleted when
> method returns or go out of scope. Also for return values an annotation to
> mark the return value safe to delete after returning.
> More fine grain resource management can be done through annotation like
> calling close() before trying to GC with appropriate annotations.
> Also appropriate API can be defined also to perform some of the memory
> management operations.
> For further examples of possible annotations see the discussion on:
> Also ability to turn off GC within a code block or function unless
> an outofmemory error happens.
> This would leave lesser workload for the GC system. Large part of memory
> management workload will be at know at appropriate point in code (if the
> programmer is disciplined). In GCing we do not know where the execution is
> when GC happens. If this is in latency sensitive code block you are in
> trouble. This way the developer is in true partnership with the GC and
> memory management system.
> Suminda Sirinath Salpitikorala Dharmasena, B.Sc. Comp. & I.S. (Hon.)
> Lond., P.G.Dip. Ind. Maths. J'Pura, MIEEE, MACM, CEO Sakrīō! ▣ *Address*:
> 6G • 1st Lane • Pagoda Road • Nugegoda 10250 • Sri Lanka. ▣ *Mobile*:
> +94-(0)711007945 ▣ *Tele*: +94-(0)11-5 864614 / 5 875614 / 2 825908 ▣ *Web
> *: http://www.sakrio.com ▣
> http://www.sakrio.com/email-legal. Please read this first.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the compiler-dev