User Controlled Memory Management and Resource Management

[Eric McCorkle]

On 05/19/13 11:18, 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.
> 

I am actually in the process of developing a proposal to use
region/effect types to permit an alloca-like bytecode, and perhaps
malloc/free-like bytecodes to be added to the bytecode instruction set
and checked by the verifier.  At the Java language level, the same type
system extensions can be used to allow the compiler to transform GC
allocations into alloca's.

It would take more work to do something like this, but the Cyclone
language used similar type system features to check the correctness of
malloc/free-style memory management.

Transforming allocations to stack allocation is a guaranteed win.  With
malloc/free, the issue is a bit muddier.  The underlying question is
whether explicit memory management actually improves significantly over
GC allocations (or regions, for that matter), which is an issue that's
far from settled, not to mention heavily dependent on the application,
runtime, and GC/malloc implementations used.


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

The capacity to disable GC for a potentially unbounded period time;
however, is dangerous.  At the bytecode level, GC literature generally
favors safepoints as a means of explicitly controlling GC.  At the
language level, the block approach is more advisable; however, there
would need to be restrictions on what can be done inside such a block,
possibly to the point of "straightline code only".

> 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).

I'm not so sure about that.  GC workloads are notoriously hard to
predict, especially in a complex, server-type system.

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

Is the goal here to reduce demand on GC or to achieve better real-time
behavior?

> 
> 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 --------------
A non-text attachment was scrubbed...
Name: eric_mccorkle.vcf
Type: text/x-vcard
Size: 314 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20130521/b8268a0c/eric_mccorkle.vcf