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=.
