New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New reify classes #4648

Merged
merged 7 commits into from May 17, 2018

Conversation

Projects
None yet
3 participants
@headius
Member

headius commented Jun 7, 2017

Work to unify variable and structural reification of Ruby classes. See #4643.

headius added some commits Jun 6, 2017

Separate base class reification from method reification.
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.
Generate all specialized width-specific RubyObject subclasses.
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.

@headius headius added this to the JRuby 9.2.0.0 milestone Jun 7, 2017

if (allocator != null) return allocator;
final String clsPath = "org/jruby/specialize/RubyObject" + size;

This comment has been minimized.

@kares

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)?

This comment has been minimized.

@headius

headius Jun 8, 2017

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.

@ivoanjo

This comment has been minimized.

Contributor

ivoanjo commented Sep 9, 2017

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_s

And 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 super.

I'm not sure what the is best choice here:

@headius headius merged commit 39a76a3 into master May 17, 2018

0 of 2 checks passed

continuous-integration/travis-ci/push The Travis CI build could not complete due to an error
Details
continuous-integration/travis-ci/pr The Travis CI build failed
Details

@headius headius deleted the new_reify_classes branch Jun 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment