Announcement: micro-libgcj

Fri Jan 6 21:33:00 GMT 2006

On 1/6/06, Boehm, Hans <hans.boehm@hp.com> wrote:
> I guess I hadn't appreciated the J2ME licensing issues. That's
> unfortunate.
>> > From: Mike Emmel [mailto:mike.emmel@gmail.com]
> >
> > Now what is wrong with adding unsafe attributes things like
> > stack allocation can be checked via escape analysis etc to
> > increase there safety. Zone allocation is also of intrest.
> > And a java like language that embraces some C concepts is I
> > think useful for embedded programming and does not conflict
> > with Sun's official java.
> >
> For some applications, I agree.
>> On the other hand, it seems to me that a potentially major attraction is
> that you might be able to write small stand-alone applications for which
> you are not likely to later discover things like buffer overrun errors
> that complicate debugging and can potentially be turned into security
> exploits. It seems to me that to really get there, you need to preserve
> at least the type safety of the core language.
>I don't know It's more of a religous argument then pratical. The
nice thing about what I'm proposing is you can be as type safe as you
want when you want to but you have access to unsafe operations when
needed. C forces you into unsafe operations for all code. But a
extended java would have the potential to have the best of both
worlds. And generally only critical sections should be optimized using
unsafe coding so the amount of programmer care in this code would be
larger. Of course you would not be able to prevent a programmer
abusing such and api but on the same hand in the java embedded world
strong OO methods that allocate a lot of objects are just as bad in
the real world.
> If you add unchecked explicit deallocation, that breaks. A premature
> explicit deallocation may end up with the same piece of memory being
> treated as both a char array and an object containing a reference field.
> Aside from creating an interesting debugging problem, if an adversary
> can control the contents of the char array, and then can arrange to
> invoke a method on the referenced object, he can gain control of the
> process. The fact that subscripts are still checked makes it safer than
> C, but not safe.
>True I'm not saying that I'm proposing a safe solution just that
embedded java has a lot of problems and a extentend language that
allowed unsafe code has a place and could would be very useful to
embedded programmers. Today the answer is to recode critical sections
in C which introduces all the problems anyway.
> Of course, anything you can do with complete checking is fine. Escape
> analysis to automatically reduce heap allocation would be great. But as
> far as I know, anything beyond automatic compiler optimization of
> allocation either requires appreciable language changes (as in something
> like Cyclone), longer pointers (e.g. tagged with a generation count),
> and/or dynamic checks (e.g. for cross-region pointers, as in RTSJ, I
> believe). I'm not sure that the latter two improve on general GC by
> most metrics.
>Yes I agree thats why at the end of the day I think for embedded use a
semi-safe javaish language that brings back stack/zone allocation and
programmer controlled memory management is really needed. Despite the
work that has gone into garbage collection no one has really proved
that they can replace other allocation methods. On the same hand
having a good gc when needed or wanted is a good thing.
I might as well add that I'm currently working on a llvm backend for gcjx.
Once I complete that I plan to then use it as the basis for a new java
like language that does allow C style unsafe operations. It's
targeted at embedded systems and library writers that want to use a
modern language but need performance/custom memory mangment. I've
been doing java on embedded systems now for about six years and it
took a long time for me too convince myself that its time to revisit
some of the tools/techniques that java threw out for safety.
My overall research is based on the concept of developing a family of
languages that are designed to interoperate at each level in the
family the language gets safer and hopefully syntax gets more powerful
and easier to use. Surprisingly there seems to be little work in such
a solution. The gulf between unsafe languages like C and safe
languages like java is so large that there is a real need for a bridge
language that has concepts from both therefore its my first target
language in my family. Once its done I'll have a language group
consisting of C ->JavaishC->Java
The middle language I'm calling Core (Common Object Runtime
Environment ) for now. Llvm provides the perfect infrastructure to
allow mixing modules written in the various languages.
 Micro-libgcj is exactly the type of library solution that fits in the
concept of a language family well and its a part of the solution I'm
excited to see it !
But if you accept the concept of desiging a language family then the
need to make draconian design decisions in a particular language are
removed. Instead your more concerned with partitioning concept
between the languages in the family based on safety syntax etc etc.
Sorry to write so much but I've been working on this for a while and
not talking about it.
Mike
> Hans
>