jrate-devel Mailing List for jRate

Morgan,

First, I'm sorry for the long absence

> Hm.  How do you propose to statically tell that one object cannot have
> multiple owners or be involved in a cycle?  Are objects only
> assignable to "owned" fields immediately after construction time?

only objects created in the current method body and not assigned to
any other fields (or made arguments to other method calls) as well as
objects returned from a method declared to return an "ownable" object
can be assigned to "owned fields".

in turn, methods that return and "ownable" object (marked by the
keyword 'owned' as well) can only return object loacally created
objects that are not assigned to any other fields or made arguments to
other method calls.

This, along with the condition that no ownership cycle within one
method body will assure that one object cannot have multiple owners or
be involved in a cycle.

I should formally state this rules and prove them, but as I said .. it
is a work in progress.

> Ok.  You might introduce a number of race conditions into
> multithreaded code though.  And it looks like you'll have to ensure
> type invariance (maybe with a runtime check) at the reassignment site.

I must admit that I didn't fully consider the multithreading issues.
I'm also not familiar with the type invariance concept. could you
please point me to some papers about it ? I have both IEEE and ACM
digital libraries subscription

>  But it looks like mentorship applications
> are no longer being taken (as of a few days ago), and Angelo and I
> aren't signed up (are we, Angelo?)---do you have a mentor organization
> you plan to work with on this?  We can still help you out of course.

No problem, Google summer of code was only a means to get me involved
and motivated. we can still do that work regardless of the actual
participation in Google's SoC. Your Help is what really needed.

in a few days I will start a new thread about what should be done to
port jRate to GCC 4.x

Yours,
Sheref

Sheref,

On Wed, Mar 14, 2007 at 04:35:40PM +0200, Sheref Younan wrote:
> Fields in every class declaration will be marked as either owned or
> borrowed. Objects referenced through an 'owned' field will be owned to
> the referencing object, ones referenced by a 'borrowed' field is only
> borrowed, and should have an owner somewhere else. static rules will
> guarantee that every object is owned by only one owner, and no
> ownership cycles can happen. an Object is deallocated when its Owner
> is deallocated. *hopefully* I can can statically enforce the rule that
> no object is deallocated while it is still borrowed by other objects
> (by enforcing that objects can only borrow from owners higher up in
> the calling stack, still thinking about it)

Hm.  How do you propose to statically tell that one object cannot have
multiple owners or be involved in a cycle?  Are objects only
assignable to "owned" fields immediately after construction time?

> One tricky part is what should happen if an owner decided to replace
> an owned abject ? as far as the owner is concerned, the old (and now
> unreferenced) object is garbage. however borrowers of that object
> still expect to use it. my solution is make borrowers use the new
> object (the one that replaced the old). This would make my model
> significantly incompatible with the traditional java model. but it is
> natural that owners can do whatever they want with their owned
> objects. borrowers can use what they borrow without complain.

Ok.  You might introduce a number of race conditions into
multithreaded code though.  And it looks like you'll have to ensure
type invariance (maybe with a runtime check) at the reassignment site.

> This is my ideas in a very informal way.it is still work in progress,
> so feedback, suggestions and criticism is highly appreciated and
> desired.

Great.  One of jRate's key purposes in the past has been its use as a
research platform.  I think this would be a cool thing to do for
Google's Summer of Code.  But it looks like mentorship applications
are no longer being taken (as of a few days ago), and Angelo and I
aren't signed up (are we, Angelo?)---do you have a mentor organization
you plan to work with on this?  We can still help you out of course.

Morgan
-- 
Morgan Deters
md...@cs...

Hi Jean-Marie,

> Short of writting a real-time garbage collector, an easier endeavior would
> be to provide "stack allocation" support.
> You could for example base your work on Javolution (open-source) and make
> sure that "new" allocations while the thread execute in a PoolContext
> allocates from a local pool (Javolution being a pure java library requires
> the use of an ObjectFactory for the same effect).
>
> Let me know what you think,

The concept of object recycling is really interesting. but I think
that it is not as general is GC. It is more of an optimization. I
wonder how far the object recycling can be applied transparently (and
more importantly: predictably) into the compilation process.
This is just my initial thoughts, I'm still thinking about it, More
discussions to come.

Yours,
Sheref Younan

Hi Morgan, Angelo

> Simpler and safer in what sense?  Guaranteed not to throw exceptions
> at runtime?  More easily sharable between threads without employing
> the (anti)patterns in the literature?  Are you suggesting actual Java
> language extensions (e.g. like Boyapati), or explicit but safe
> deallocation of regions in the style of Gay & Aiken, or something like
> scopes but with relaxed single-parent and referencing rules, or
> something entirely new?

By Simpler I mean that it has a higher level of abstraction and easier
to understand and use by programmers. Safer means that It should
eliminate much of the possible exceptions at run time.

I'm suggesting java language extensions, in fact my work is very
similar to (and largely inspired by) Boyapati's. It also depends on
the concept of ownership relations among objects. we agree on that
every object is owned by another object and that ownership relations
forms a forest (no cycles, no multiple owners). But I differ on how to
express this relationship in the code. I suggest adding only two
additional keywords to the standard java: owned and borrowed.

Fields in every class declaration will be marked as either owned or
borrowed. Objects referenced through an 'owned' field will be owned to
the referencing object, ones referenced by a 'borrowed' field is only
borrowed, and should have an owner somewhere else. static rules will
guarantee that every object is owned by only one owner, and no
ownership cycles can happen. an Object is deallocated when its Owner
is deallocated. *hopefully* I can can statically enforce the rule that
no object is deallocated while it is still borrowed by other objects
(by enforcing that objects can only borrow from owners higher up in
the calling stack, still thinking about it)

This model is probably less expressive than other ownership models.
but I argue that it is also simpler and easier to use because
ownership semantics (expressed via instance fields) scale well to the
higher abstractions in the program,  for example: a GUI object may
hold a reference to the display object, but this reference is only
borrowed (the GUI doesn't own the display, it merely borrows it to use
its functionality). The OS is probably the owner of the display
object. another example is that a data structure owns its nodes, other
objects (i.e. an iterator) may borrow a node or so.

One tricky part is what should happen if an owner decided to replace
an owned abject ? as far as the owner is concerned, the old (and now
unreferenced) object is garbage. however borrowers of that object
still expect to use it. my solution is make borrowers use the new
object (the one that replaced the old). This would make my model
significantly incompatible with the traditional java model. but it is
natural that owners can do whatever they want with their owned
objects. borrowers can use what they borrow without complain.

This is my ideas in a very informal way.it is still work in progress,
so feedback, suggestions and criticism is highly appreciated and
desired.

> Well, grab a Subversion client and get the latest sources from
> SourceForge.  Make sure you can build it (on top of GCC 3.3.3
> sources).  That's a good place to start.
>
> We have some notes in the top-level of the jRate source tree, also
> there's some stuff in SourceForge's DocManager, available from the
> jRate SourceForge project page under Documentation.  You'll also want
> to look around online for GCC documentation and poke around the GCC
> sources.  I have some old seminar notes up at:
>
>   http://www.cs.wustl.edu/~mdeters/seminar/fall2005/
>
> that you might find useful.  Also check out the "gccint" info pages.
> There's a lot there, some parts you'll be more interested in than
> others.
>

Thank you very much, I haven't looked through the seminar notes
thoroughly yet but It looks very useful.

Yours,
Sheref Younan

Hi Sheref,

On Tue, Mar 13, 2007 at 03:35:59PM +0200, Sheref Younan wrote:
> I'm working on non Garbage Collection Memory Management, trying to
> propose a memory management technique that doesn't need a GC, yet
> simpler and safer than scoped memory.

Simpler and safer in what sense?  Guaranteed not to throw exceptions
at runtime?  More easily sharable between threads without employing
the (anti)patterns in the literature?  Are you suggesting actual Java
language extensions (e.g. like Boyapati), or explicit but safe
deallocation of regions in the style of Gay & Aiken, or something like
scopes but with relaxed single-parent and referencing rules, or
something entirely new?

> It seems that porting jRate to GCC 4.1.x would be the first thing to
> do. but to tell that truth I'm not sure from where to start or what
> exactly to do, though I'd love to learn.

Great, as I've said much of that work is already done.  I'll have to
go back and figure out where I left off..  IIRC the compiler is done
but the runtime is crashing on startup somewhere.

> The real time GC seems to be a true addition to jRate, as well as a
> really challenging project. Perhaps I could also make it a part of my
> master work.

Yes on both counts.. it's a hot area of research.

> In the meanwhile, can you Direct me on where to start working and
> understanding jRate and GCJ ? (Reading materials, Text books, source
> code ...)

Well, grab a Subversion client and get the latest sources from
SourceForge.  Make sure you can build it (on top of GCC 3.3.3
sources).  That's a good place to start.

We have some notes in the top-level of the jRate source tree, also
there's some stuff in SourceForge's DocManager, available from the
jRate SourceForge project page under Documentation.  You'll also want
to look around online for GCC documentation and poke around the GCC
sources.  I have some old seminar notes up at:

  http://www.cs.wustl.edu/~mdeters/seminar/fall2005/

that you might find useful.  Also check out the "gccint" info pages.
There's a lot there, some parts you'll be more interested in than
others.

Morgan
-- 
Morgan Deters
md...@mo...

Hi Morgan and Angelo,

I'm working on non Garbage Collection Memory Management, trying to
propose a memory management technique that doesn't need a GC, yet
simpler and safer than scoped memory.

It seems that porting jRate to GCC 4.1.x would be the first thing to
do. but to tell that truth I'm not sure from where to start or what
exactly to do, though I'd love to learn.

The real time GC seems to be a true addition to jRate, as well as a
really challenging project. Perhaps I could also make it a part of my
master work.

In the meanwhile, can you Direct me on where to start working and
understanding jRate and GCJ ? (Reading materials, Text books, source
code ...)

Yours,
Sheref

Hi Angelo and Sheref,

On Sun, Mar 11, 2007 at 10:31:15PM +0100, Angelo Corsaro wrote:
> The first thing I would do is to port jRate to GCC 4.1.x. Then, I could
> suggest the following projects:
> 
>   - Real-Time GC
>   - Garbage Collected VTMemory (predictable, fast and efficient)
>   - Transactional Memory for jRate/GCJ
> 
> Morgan do you have some other suggestion to add to this list?

Well, those are certainly big ones that have been on jRate's wish list
for awhile, and predictable GC would certainly be a great addition to
jRate.  There are always the outstanding standards-compliance issues
with jRate, but those are less challenging, novel, and publishable,
although important.  There's also the matter of getting jRate to work
well under RTAI/fusion -- that might be a good project depending on
your interests.

I'll echo Angelo though -- if you have a specific research interest,
there are probably additional things to recommend, whether they be
scheduling-related, analysis-related (either statically or at
runtime), etc.  We're certainly not opposed to jRate reaching outside
of the real-time Java standard where it makes sense for developing
real-time and embedded software.  (I have some flags in there to run
it in "standards-compliant" mode, which disables extensions, though to
be honest it's far from "compliant"; there's still a fair amount of
missing functionality outlined in the standard.)

Some of the porting work to GCC 4.1.x is already complete.  It's not a
huge job, and it has a lot of benefits since the Java support in 4.1.x
is greatly improved (compiler bugfixes etc).  I can share what I have
already if you like.

Morgan
-- 
Morgan Deters
md...@cs...

Hello Sheref,

On 3/11/07, Sheref Younan <she...@gm...> wrote:
>
> Hi all,
> I'm a master student and my thesis involves real time java.


On what are you working exactly, that might help choosing one topic to add.

I also
> wanted to participate in Google's Summer of Code.
> I was wondering if there is any thing that can be done in jRate as my
> participation in Summer of Code ?



The first thing I would do is to port jRate to GCC 4.1.x. Then, I could
suggest the following projects:

   - Real-Time GC
   - Garbage Collected VTMemory (predictable, fast and efficient)
   - Transactional Memory for jRate/GCJ

Morgan do you have some other suggestion to add to this list?

Thanks for you interest.

Cheers,
     Angelo

Hi all,
I'm a master student and my thesis involves real time java. I also
wanted to participate in Google's Summer of Code.
I was wondering if there is any thing that can be done in jRate as my
participation in Summer of Code ?

Best Rsgards,
Sheref Younan