Subject: grant meeting summary
From: Craig Chambers (chambers@cs.washington.edu)
Date: Tue Oct 02 2001 - 22:38:59 PDT
Here is my summary of notes taken at Monday's group meeting:
rant programs:
Next Generation Software ($200K-$1M/year, 3 yrs): Nov. 2
Programming Languages & Software Eng ($100K/year, 3 yrs): Nov. 5
ITR Medium (<$1M/year, 5 yrs): Nov. 13
Compilers ($100K/year, 3 yrs): Dec. 5
ITR Small (<$100K/year, 5 yrs): Feb. 7
($100/year = 1 student! ~$60K/student after that)
Possible target applications:
UrbanSim, one.world, LabScape
geo-sciences infrastructure/middleware?
Theme 1: effective support for advanced OO applications
. targetting the first line of target applications above
. staging of OO languages, including separate, jar-link-time,
JVM-dynamic-load-time (maybe some sort of static load time), and
run-time (probably 3 years of work here easily, with various things
Matthai and I have talked about with making the current staging ideas
more long term)
. representation optimizations (Keunwoo already has ideas for
UrbanSim optimizations; what's to be done longer term?)
. modular language support (Todd's work on MultiJava and
applications to one.world and LabScape is an excellent start on this;
what's the next step, over 3 years?)
. software architecture support?
. static type system support?
. see extensible type system theme below
Theme 2: handling dynamically evolving software
. need some good, compelling applications; e.g. software maintenance
& bug fixing, software evolution, dynamically customizable software,
extensible servers, ...?
. reoptimization after dynamic changes to software
. staging?
. multijava dynamic loading is an application that needs this kind
of optimization
. static typechecking in the face of long-running & evolving
software [recent related POPL paper to read!]
Theme 3: specifying and enforcing system invariants
. example applications?
. specifying system invariants: like a fancy type system
. specifying system invariants: software architecture is an example
. how to make something extensible, but usable?
. static checking of invariants
. how to specify & check these things modularly
. generating dynamic checks where static checks insufficient
. optimizing the dynamic checks
. maybe dynamically reoptimize things, if dynamic checks change
as the system changes, or maybe we allow dynamic imposition of
checking?
. DCPI: lightweight dynamic monitoring; is there a parallel here
where we might want to specify and "enforce" monitoring, profiling, &
other instrumentation, not just checking?
Other ideas:
. program analysis/optimization targetting to software maintenance/bug
finding/fixing
. "type inference" to decide how to partition computations (or data?)
in a distributed system
. mining a bug database, e.g. apache's
. language generators
-- Craig
P.S. I'm thinking of an afternoon brainstorming session to follow up this
meeting, maybe this Saturday or Sunday. Think about it. We'll decide Wednesday
at 590L whether to do it.
_______________________________________________
Cecil mailing list
Cecil@cs.washington.edu
http://majordomo.cs.washington.edu/mailman/listinfo/cecil
This archive was generated by hypermail 2b25 : Tue Oct 02 2001 - 23:08:03 PDT