User Controlled Memory Management (Object Lifetime Management) and Resource Management

[Suminda Dharmasena]

Hi,

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?

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 20 May 2013 14:30, Clemens Eisserer <linuxhippy at gmail.com> wrote:

> Time to start writing a prototype - looking forward to your implementation
> :)
>
> Regards, Clemens
>
> 2013/5/20 Suminda Dharmasena <sirinath at sakrio.com>:
> > 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 and to mark that fields and methods in a
> > class do not escape.
> >
> > There can be finer grain of specification on what the type of
> containment is
> > and what the escape is. Traditionally this might be thread, stack, etc.
> but
> > in this case we are more concerned with containment within the containing
> > object for field and containment when calling methods with regard to
> > parameters, local variables and return types.
> >
> > In a nutshell we should be able to specify the lifetime of an object at
> > point of declaration so it gets deleted when its usefulness is over. Only
> > the occasional object that escapes this will need to be GCed.
> >
> > 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.
> > --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130520/684fc950/attachment.htm>