On Oct 12, 2007, at 2:49 AM, Attila Szegedi wrote:
> it would be great to
> have a runtime where you can go one level lower and actually load
> metaobject protocols into the runtime dynamically. I don't know yet
> whether this makes sense (it feels to me it does), but is definitely
> something to think about.
There are projects to soften up the JVM's object architecture,
to give it a MOP, but that sort of thing probably requires
a redesign from the ground up.
With HotSpot, I hope to make the bytecode set more flexible,
so that it can be used as a type-safe, GC-able assembly language,
and then build MOPs on top.
But (thinking here...) there might be MOP-like capabilities we could to
do push downward into the current hardwired runtime. For example,
it might be reasonable, given method handles, to have a VM-level
operation for creating a class and populating its vtable with closures.
(I once wrote a Scheme system which did this to C++ base classes.)
But that's probably secondary, compared with a primary feature of
method handles. (With purely structural (signature-based) calling
sequence and provision for making closures, of course.)
The fast out-of-line dynamic calling sequence in HotSpot is called
a monomorphic inline cache. It involves having the caller pass a
token (expected callee class) which the callee checks quickly on
method entry. (This is called the "verified entry point", or VEP,
as opposed to the "unverified entry point", or UEP.)
Calling a method handle probably requires a similar check,
of a receiver signature rather than a receiver class.
(After all, closures are classified by their signatures.)
Introducing such a calling sequence into the JVM would
be very profitable.
I'll post more on method handles when I get some blog time.
> Of course, there's always the danger of losing focus if the goal is
> too
> broad; see history of Parrot for terrifying examples.
Yes. That initial list of ideas, if fully explored, would cost
decades of work.
(And that's just my own pick of favorites.) So there is (as always)
a need to
choose the most profitable projects first. I'm working on dynamic
invoke,
and I agree that some sort of method handles are also a big need.
You mentioned continuations. I have a low-level design
and a rough implementation sketch for the suspension,
pickling, and resumption of coroutines, but (short on time
and expertise) I left out the all-important part of resumption,
which HotSpot would call on-stack replacement.
HotSpot does perform several kinds of stack frame editing.
That code is not easy to extend. (Suprised?) It would be
lovely to have (someday) a flexible system ("MsfP") for
stack frame management, so we could do things like
reoptimization, evacuation to the heap on overflow,
or work stealing directly from the execution stack.
> Although I'm
> optimistic -- building on a foundation of the HotSpot JVM architecture
> gets you immediately past lots of project infancy problems.
Yes, that's the really appealing thing to me about this.
We've spent 10 years working on this platform,
investing in Java, and now it's time to make that
investment pay off for the newer crop of languages.
One big investment, BTW, are the JITs.
The server compiler is not Java-specific at all.
It has a (now-classic) SSA sea of low-level nodes.
As a good citizen of the JVM, it knows how to leverage
type profiles and invariants provided by the object architecture.
But it's really a pretty general purpose compiler.
(Recently we added some vectorization optimizations.)
-- John
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
