Ola Bini wrote:
> I was thinking if the slowness of loading is because of all the class
> loaders used... Would it make sense to let the standard library run with
> the same class loader, you think?
> And in the same manner, when we're talking about compiling RubyGems on
> installation, having the same class loader for the whole gem seems to
> make sense, neh?
Yes, I have been thinking the same thing, and trying to reconcile how to
know when we should switch to a different classloader for new methods.
Since "def" is always a runtime operation, there's no clear distinction
between doing
while true; def some_method; end; end
and doing
def some_method; end
But the first case would leak classes if it always generated, say,
invokers into the same classloader.
I also would like to find a way to reduce the overhead of starting up
the class, possibly by generating a single custom call adapter per
compiled class that has custom methods for each call site and n * 3
fields for the inline cache; that would allow a single object to be
constructed rather than one per invocation.
There's a lot of room for improvement here.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
