Charles Oliver Nutter wrote:
> I see class-per-method...faster than reflection-based, but perhaps a
> heavy load on permgen space, no? Have other options been considered?
I don't know what you are referring to with class-per-method.
> Loading all those classes could be a hit in itself. Looks like thousands
> of them. One possible option: provide a single classes with numeric
> methods and switch on some index for separate "method instances". You
> take the hit from the switch, but that's super fast and you can cut your
> class load down by orders of magnitude.
> The optimizations for fast invocation of 1-4 arg methods are a good
> idea...might be worth trying to do in JRuby too.
> You guys sure love your underscores, though I know that's a Python thing
> JRuby's method-binding logic is quite similar to Jython's, though as I
> mentioned we primarily use reflection (bad) but are switching to direct
> invocation through a multiple-method interface (good). JRuby's
> performance has recently gotten to the point where reflection is a
> substantial part of our performance issues, so we're starting to make
> that change.
> I see the Python compiler, but it looks like that's as far as it goes,
> yes? Is Jython is still pure interpreted (as in bytecode interpretation
> and no JIT to Java bytecode at any time)?
there's no AST executing walker or own bytecode intepreter. We always
compile down to java
bytecode but the resulting code uses extensively the runtime. Whether
more involved type-feedback
based approaches would help is an open question, the cost of
instrumentation and of class loading
should be taken into account.
We have an extensive runtime because things like
for example have quite involved semantics in Python, it may result in
various method dispaches,
not a simple one to a.
> I have started working on JIT
> compilation for JRuby among other options. Bytecode isn't a whole lot
> faster than AST-walking, but since it would allow us to make better use
> of the Java call stack we're looking into that as well. Many possible
> Hmm, now I find ClassFile, which seems to be a very simple Java code
> generator. Would something like ASM be better to use here? Why was one
> rolled from scratch?
> How's ORO been working out? That goes way back. I have a few Rails test
> cases that can easily blow the Java stack using Java's regex impl. We're
> going to have to consider switching to something else. The current
> front-runner is JRegexp, which has a stackless implementation that
> should work nicely, but it's a non-trivial change.
ORO was used in the past. Python has its own regexp machinary in sre.py
and the _sre extension,
of which Jyhton has its own if a bit outdated implementation.
> I notice some use of the synchronized collections in places where it's
> probably not needed...ScopeCompiler uses Hashtable and Stack, ClassFile
> uses Vector...etc. We've seen noticeable improvements in many places by
> using unsynchronized collections.
> Ahh ThreadState. The equivalent to our ThreadContext. We have been
> mercilessly working to simply and eliminate it. ThreadContext in JRuby
> has been the source of much low-hanging performance fruit. ThreadState
> looks very similar, though we've moved a lot of logic into our
> implementation to centralize it for eventual simplification and removal.
> Heh, even down to using thread-locals to retrieve the current
> ThreadState (which is has been another constant bottleneck in
> JRuby...10-15% in profiling). ThreadLocal is costly.
> Yes, I think we can work with this. It certainly could use a refresh up
> to 2006 Java standards, but many of the same optimizations we've done in
> JRuby will be applicable to Jython. I'm still fuzzy on how far Jython
> compiles Python code...there just doesn't seem to be enough
> code-generation going on for there to be a full compiler. Someone set me
> straight if I'm wrong.
There's quite some cruft in the codebase, also some quite clever code
that is probably not worth the complexity
especially if one wants a large pool of maintainers.
As the person still somehow involved with the project probably knowing
the code base best, and having done
the last big surgery to it (implementing new-style classes), I can only
repeat that I think that cleaning up the code base
to some extent is a necessary step before it can be brought in any new