New reify classes #4648
Merged
New reify classes #4648
Conversation
The goal here is to start splitting off the method reification, which many (most) people don't need, so we can still get the benefit of generating a real class for every custom Ruby class without the hassle of binding a bunch of methods. See #4643.
This is a first step toward unifying all forms of reification. In this commit, all the hand-implemented RubyObjectVar* and ObjectAllocator* are instead generated as needed and then reused statically. Since this will be a bounded number of classes (based on the max size of inspected instance vars in user classes) it should not use too much memory. This now allows us to support reified instance variable fields up to an arbitrary size. Note that although the allocators are generated on a per-class basis (necessary without using MethodHandle for allocation) the variable accessors are still hand-written and only call the appropriate getVariable# or setVariable# up to 9 as before. It is an open TODO to generate these accessors on a per-class basis so they inline all the way through. The alternative would be moving toward more MethodHandle-based factories, but that limits cross-JVM support and may result in startup impact. For #4643 among others.
|
|
||
| if (allocator != null) return allocator; | ||
|
|
||
| final String clsPath = "org/jruby/specialize/RubyObject" + size; |
kares
Jun 8, 2017
Member
there's org/jruby/gen to distinguish generated code, maybe it makes sense to use it as well (org.jruby.gen.specialize)?
there's org/jruby/gen to distinguish generated code, maybe it makes sense to use it as well (org.jruby.gen.specialize)?
headius
Jun 8, 2017
Author
Member
I agree this generated code should go into org.jruby.gen. The "org.jruby.specialize" was a typo on my part; it would have been specialized, which I think we will keep to separate the hand-written pieces from the generated stuff.
I agree this generated code should go into org.jruby.gen. The "org.jruby.specialize" was a typo on my part; it would have been specialized, which I think we will keep to separate the hand-written pieces from the generated stuff.
|
I've just retried with this branch with the following testcase (from #4643) class BrokenReify
def to_s
super
end
end
puts BrokenReify.new.to_sAnd it still causes a stack overflow. I believe the reason why it fails is still similar: it's because unlike other reification options (e.g. reify variables) we define the instance methods from the ruby class in the reified class, which is what breaks code which tries to call I'm not sure what the is best choice here:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Work to unify variable and structural reification of Ruby classes. See #4643.