Bill Dortch wrote:
The variables code is/was in place in the bdortch/attrs branch, but I'm
moving it to bdortch/vars, with some changes (due in part to much
refactoring in trunk since I first wrote it). I plan to work on this
tonight and tomorrow (Saturday), and hope to finish it up by Sunday
evening, if not sooner. At that point, it will need to be reviewed and
tested before being merged to trunk. I'll write up a more detailed note
Sunday, but here are a couple of quick items:
Ok...I'm going to be working through the weekend, so I will be looking
out for your changes and for you to stop into #jruby if possible. More
below...
- The code addresses symbols, variables (ivars and cvars), and
constants, as well as internal (or "special") variables.
These are areas that have started to show up on profiling for me, so I'm
keen to get your changes incorporated. Instance variables in JRuby
currently appear to be faster than MRI on trunk...but there's room for
improvement. Witness pastie:
http://pastie.caboo.se/104470
Constant lookup, on the other hand, is considerably slower than Ruby,
and uses many of the same structures. I also realized this week that
looking up and failing to find a constant causes a hash to come into
existence; that too most definitely needs to be repaired:
http://pastie.caboo.se/104471
- In general, synchronized (or synchronized-access) HashMaps are
replaced with custom concurrent hash implementations. Also, "fast"
accessors are provided that can be used when a variable/constant/symbol
name is known to be interned. For single-threaded access, the result is
30-100% faster reads (best improvement is for ivars;
constant/cvar/symbol lookup is more complicated, but still much faster).
For multi-threaded access, the improvement can be nX faster (I've run
benchmarks that show 200-300% better throughput). That probably won't
help much for ivars, but symbol and constant lookup should be much
improved in multi-threaded applications.
I noticed that the standard ConcurrentHashMap is quite a bit faster for
reads and somewhat slower for writes, but I think that in Ruby as in
most languages reads are going to be more important. So I think this is
still a good path to follow.
At one point about a year ago I looked at putting in an "interned" path
for method lookup; in the end it became too cumbersome, but the idea
seemed sound. However there may be a more reliable way: provide a path
that only excepts an "ID" object, and have all appropriate places in the
system store such IDs. This would allow fast hashing when using IDs and
a migration path for existing code that may not be interning strings
right now. This also fits with MRI's use of unique IDs for various
identifiers, and it would guarantee we don't accidentally (and nearly
undetectably) pass a non-interned string along an interned path. Unit
testing and assertions can help, but a specific known-to-be-unique type
of object would guarantee safety.
- I had played with some initial refactoring of IRubyObject/RubyObject,
but don't plan to include that in the bdortch/vars branch. I think this
*badly* needs to be done; the current hierarchy is very rigid and forces
us into less-than-optimal implementations of built-in objects and Java
objects, among other things. (Even without going as far as
"lightweight" implementations, there is no reason a RubyFixnum, for
example, should need to carry fields for flags, dataStructs, finalizers,
instance variables, and so on.) But I think this will need to wait
until after 1.1 -- it will be a big change, will likely break
external/3rd party code, and needs discussion and debate. Perhaps we
should start a thread or JIRA (or some other forum -- Google doc?
group?) on JRuby 1.x architecture. I've got a few other notions on the
subject, more on this later.
I was worried you might try to get deep into this refactoring. I agree
it should wait. There will be real tangible benefits from it, but it
shouldn't be done this last in the release cycle and it definitely
shouldn't be done by just one person. Moving to lightweights and pure
Java representations of objects is going to be a big job we'll all have
to work on.
That said, I think we should start those discussions immediately. I
think we should consider making the next release after 1.1 a 2.0
release, and as part of that the object model would change to better
support lightweight objects throughout the system. I believe this needs
to be done, and along with the static compiler I think it would finally
round out the final design for JRuby.
So in short, I support holding off on this, and I feel much safer about
pulling in your branch without it.
- I think the major JI overhaul will also need to wait for post-1.1 --
ideally, after we've reached some conclusions on overall architecture
issues. In the meantime, I plan to implement some less-drastic
performance improvements over the next couple of weeks. More on this later.
Agreed. We can do a lot to improve performance and simplify call paths
(especially if we bail entirely on the idea of lower vs higher Java
support) without the complete overhaul. And really any ultimate overhaul
would necessarily want to work in concert with the "lightweight"
migration, so we must take the two hand in hand. JRuby 2.0.
Please keep us posted...I would like to look at reviewing and merging
your branch this coming week, so performance work can continue (I do not
want to struggle with constants and ivars myself if you have better,
complete solutions for them now, but performance work must continue ASAP).
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
