Object Lifetime Specification

[Suminda Dharmasena]

Hi,

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
--
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 ▣

This email is subjected to the email Terms of Use and Disclaimer:
http://www.sakrio.com/email-legal. Please read this first.
--


On 19 May 2013 20:48, Suminda Dharmasena <sirinath at sakrio.com> wrote:

> Hi,
>
> 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:
> https://blogs.oracle.com/dholmes/entry/minimize_garbage_generation
>
> 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:
> https://blogs.oracle.com/dholmes/entry/minimize_garbage_generation
>
> 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
> --
> 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 ▣
>
> This email is subjected to the email Terms of Use and Disclaimer:
> http://www.sakrio.com/email-legal. Please read this first.
> --
>