From sirinath at sakrio.com Sun May 19 08:18:15 2013 From: sirinath at sakrio.com (Suminda Dharmasena) Date: Sun, 19 May 2013 20:48:15 +0530 Subject: User Controlled Memory Management and Resource Management Message-ID: 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. -- From sirinath at sakrio.com Sun May 19 23:57:42 2013 From: sirinath at sakrio.com (Suminda Dharmasena) Date: Mon, 20 May 2013 12:27:42 +0530 Subject: Object Lifetime Specification Message-ID: 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 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. > -- >