logicmoo~ The company I work for actually does exactly what you are describing. We have extended Janino and fixed a bunch of bugs in it to support out needs.
http://code.google.com/p/janino-streambase/ But in essence, we build an EventFlow specific AST which we transform into a composite AST (we make very heavy use of value types, having most of our primitives expand into multiple local variable or fields) we then transform that AST in a Janino AST which we use to either produce bytecode directly or java code to aid in debugging. The ability to generate the java code (complete with indicating lines in our compiler that generated the code) has been immensely useful for us. We have also seen very strong performance through our use of value types. Matt On Sun, Nov 22, 2009 at 11:06 AM, <[email protected]> wrote: > > Some jvm languages have problems left to solve: > > ---------------------------------------------Problem1--------------------------------------------- > P1) Whole program type inference to allow use of jvm primitives for their > numeric types and math. > (Even the use of Strings and other types we tend to be > a HolderForATypicalJREClass) > > Some strategies used: (So far the compilers that get closest to > optimal have done the hard ones like S5 and S1,) > > S1) Some people had to "force themselves" to use java primitives. And when > they could not get away with it, at least used > some JRE version of a java.lang.PrimitiveHolder. Stayed frustrated for a > few hours but finally conceded that this was no longer their problem. > > S2) Some (like myself) used my.lang.PrimitiveHolder. Consoling myself with > "java did it!" or "when its time, *eventually* will fix this to use > primitives" or "what knucklehead thought 16 bits is enough to represent > any character?" or "they forgot unsigned byte.. I need a special holder > that helps mark this as so" > > S3) Create a couple generic HolderForJavaObject and optimize the use of > reflection > or make HolderForWidelyUsedJREInterface(s) > > S4) Guess what the user will likely use based on the types from MyLang: > MyLangJavaNetSocket, MyLangJavaReader, MyLangJavaWriter, etc > > S5) Or enforce strong typing and never cheat using a > HolderForATypicalJREClass... force my compiler to invoke-virtual > > S6) and/or make my MyLangWhatever implement JRE interfaces.. Later on work > on passing JRE objects thru > > S7) Pick out a set of well documented interfaces from something external > like CORBA > .. and make my compiler only target that > > * Know I've missed a few (We could try on this list to keep enumerating > them) > > > ---------------------------------------------Problem2--------------------------------------------- > P2) Excluding P1, if some user would have just written their application in > .java in many cases, > The bytecode that would have resulted from their code would be a > tad better than ours. > > S8) invoke static > to MyLangLibrary.tooWierdOfFeatureToCompileSmartly(MyLangASTLikeObject obj) > {... written in java ..} > > S9) Make the user just write java in a new featurefull syntax > > S10) inline S8 into bytecode (Not a strategy: But allot of people think it > is.. profiling might tell otherwise.. ("method too large to JIT")) > > S11) have 2nd-4th passes that optimize their intermediate proposals before > bytecode representation is emitted. > > S12) Some may even run bytecode optimizations like SOOT > One JVM lang even had to write their own post process: GJIT > (http://code.google.com/p/gjit/), > > > * Know I've missed a few (We could try on this list to keep enumerating > them) > > > ---------------------------------------------Problem3--------------------------------------------- > P3) Maintaining and improving our compilers to solve P1 & P2 better. > > > S13) Improve the built in functions of our runtime > > S14) Use JAVAP/JAD/JODE on the emitted output. (I think we of are > constantly doing this.. but...) > > !!!!Now the reason for my Email!!!! > > S15) Create a .Java emitter branch > > Instead of emitting bytecode .. make compilers emit java code that would > have produced the same bytecode > (jvm language permitting/omitting optimizations = Can some on list please > enumerate what they cannot translate to .java?) > > > - Compile an entire user program into a tree of .java files > - Decide if that was how you would have written their program in > .java > If not, see how many simplistic changes you could make that > could be done at compiler/translator level > - Get an overview of how many changes you'd like to make (like S1 > thru S9) at the compiler but would be just be too grueling > - Could you write an AST transform/refactor tool targeting this > .java source to improve it? > If so, can this be incorporated into the compiler as a pass? > - Now that their program is a .java program.. Include your Runtime > and make a java project out of it. > since you are a java hacker, you can experiment and profile > what are good and bad ideas better. to find what optimizations are worth it > With that information .. re-include it into the > emitter/compiler. > > Pretty much IMO most complier writers that try to do all the above in > typical S14 and profiling and have even reached best-cases quite often .. > Most jvm languages go directly from source to bytecode: > We want to get to execution quickly as possible or Can advertise as a real > compiler. or Makes the user feel more secure with their proprietary code > > But regardless feel they never reached "Whole program" efficiency I think it > is because the limited scope of S14 > I suspect the more time one spends in the java-emitter branch of their jvm > language (dealing with entire user programs), > the better their compiler trunk will become. > > Here is an example of a complier-as-emitter.. An entire user's program was > translated from SubLisp to .java > > line 117 of > http://larkc.svn.sourceforge.net/viewvc/larkc/trunk/platform/src/com/cyc/cycjava/cycl/constant_reader.java?revision=254&view=markup > > It uses a for/next look on a boxed Fixnum. but if that was fixed.. line 118 > which only consumes Fixnums has to be updated as well. > And so the cycle begins, replacing fixnums with primitive 'long's (or maybe > 'int's if array index accesses will be found in the call tree). > This code could be manipulated with some heavy java AST manipulation tools. > Same way bytecode could have been.. > > I just bring all this up in case people are looking for new ideas and might > find sometimes easier to work with java in their compiler > improvement workflows. > > Myself, once I got the .java down that I thought best its just as easy to > compile and then get the best bytecode version for a compiler. > > > > > > -- > > You received this message because you are subscribed to the Google Groups > "JVM Languages" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/jvm-languages?hl=. > -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=.
