Starting work on an Interface Injection prototype

Tobias Ivarsson thobes at gmail.com
Sun Jan 25 06:57:39 PST 2009


On Sun, Jan 25, 2009 at 12:43 AM, John Rose <John.Rose at sun.com> wrote:

> On Dec 11, 2008, at 2:55 AM, Tobias Ivarsson wrote:
>
> *John*: last time you and I spoke about this you said that you were going
> to start working on some core implementation details. Have you had time to
> look into that?
> If not - that's ok, I'll go ahead anyway, I just don't want to be
> duplicating too much of the effort.
>
>
> I sent you my current sketches the other day; I hope they help.  Feel free
> to ask me what I'm intending in them, or else what design alternative you
> favor.
>

I noticed that, I have read through your patch once. Sadly I spent
Thursday-Friday being sick, and then had family visiting Saturday. So I
haven't done more since then. From what I have looked at it looks very
similar to my ideas, the main difference being naming, I am a bit more
verbose than you are. I liked the way you used arrays to represent each
extension record, it ties in more easily with existing systems, such as
garbage collection. I defined a C++ structure for the extension records, but
I'll change that since I think your approach is more elegant there.

I have been thinking about one thing in the JITing phase, that I have not
implemented. If interfaces are marked as being injectable or not, then we
would not have to emit the code for looking up the interface in the
extension list if it's not injectable. To do this the method that emits the
instructions needs to have access to the klass representing the interface.
Is that possible? Is it desirable?

>
> Let's use the follow public page as a notebook on the project:
>   http://wikis.sun.com/display/mlvm/InterfaceInjection
>
> This page also has information about how interfaces work:
>   http://wikis.sun.com/display/HotSpotInternals/InterfaceCalls
>
> If you have looked into it, I would love if you could share the material
> you have, in terms of source code or analytical documents. But don't feel
> the need to work on this now if you haven't before just because I'm starting
> this project - I'll be able to manage just fine on my own (Although I might
> drop you an e-mail or two with questions).
>
>
> Basic idea is that each klass structure already includes (allocated inline)
> a 2-dimensional ragged table of its statically defined interfaces.  In
> meth.patch I've rationalized this a little to prepare for your work.  I put
> more extensive notes on the wiki page mentioned above.
>

Excellent notes, I'll add to that page as well.

>
> Best wishes,
> -- John
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090125/74ea9f8a/attachment.html 


More information about the mlvm-dev mailing list