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

Suminda Dharmasena sirinath at
Mon May 20 07:41:29 UTC 2013


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

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

This email is subjected to the email Terms of Use and Disclaimer: Please read this first.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the hotspot-gc-dev mailing list