JVM Languages Google Group

Re: [jvm-l] Re: Trying to apply various techniques of new JS runtimes to JVM dynamic languages

charles.nut...@sun.com (Charles Oliver Nutter) — Fri, 05 Sep 2008 10:16:27 UT

I was more thinking about providing a mapping file in a given class that
says "this method here actually means foo, not foo$BLAH/__wahoooyippee.
Not necessarily a standard mangling convention, but a way to specify how
you've mangled.
- Charlie

Re: [jvm-l] Re: Trying to apply various techniques of new JS runtimes to JVM dynamic languages

szege...@gmail.com (Attila Szegedi) — Thu, 04 Sep 2008 20:25:27 UT

Well, in my original example, I would've expected the runtime to
create a class out of two object literals, {re:5,im:6} and {re:7,im:
9}. I would be highly surprised if you could have a compiler deduce a
non-mangled name out of these :-) (best it could come up with would be
"ReIm", IMHO; or "re_int$im_int").

Re: [jvm-l] Re: Trying to apply various techniques of new JS runtimes to JVM dynamic languages

charles.nut...@sun.com (Charles Oliver Nutter) — Thu, 04 Sep 2008 17:02:37 UT

The Inline annotation would be a hint to hotspot that a given method
should at all costs be inlined into its callers (if I remember
discussions with John correctly). Potentially this could also be an
explicit way to break the N-bytecode size limit for inlined methods.
Basically I see it as a way to hint to hotspot that it shouldn't use a

Re: [jvm-l] Re: Trying to apply various techniques of new JS runtimes to JVM dynamic languages

charles.nut...@sun.com (Charles Oliver Nutter) — Thu, 04 Sep 2008 16:47:25 UT

Python uses "slots" heavily, and many optimizations in Python impls seek
to optimize access to those slots. Method invocation is not just
"dispatch to this method", it's "lookup whatever's in this slot and
invoke it like a method". I believe local variables are also technically
slot-based, which makes it much similar to JS in that regard. So the

Re: [jvm-l] Re: Trying to apply various techniques of new JS runtimes to JVM dynamic languages

kasou...@gmail.com (Rastislav Kassak) — Thu, 04 Sep 2008 14:23:04 UT

Ruby is class based, but not only.
You can extend single living object in runtime and it turns this
object to singleton, creating new hidden subclass in fact.
So if you have some kind of framework dynamically creating such
singletons in runtime, it could possibly create a lot of hidden
subclasses.
IMHO. I'm not MRI or JRuby surgeon, this is only from application

Re: [jvm-l] Re: Trying to apply various techniques of new JS runtimes to JVM dynamic languages

szege...@gmail.com (Attila Szegedi) — Thu, 04 Sep 2008 11:31:18 UT

Indeed, that's exactly what I had in mind.
Why would we need an explicit inline annotation? I was under
impression that use of invokedynamic would open the opportunity for
HotSpot to inline the code with certain types of MethodHandles.
Yeah, my wet dream of combining this with the type specialization of

Re: [jvm-l] Re: Trying to apply various techniques of new JS runtimes to JVM dynamic languages

szege...@gmail.com (Attila Szegedi) — Thu, 04 Sep 2008 11:23:23 UT

Well, JS as such has no threading or other concurrency primitives,
this much is true. But you can have a JS environment where a program
accesses objects shared by multiple threads, i.e., with Rhino in
JVM... You're right that a JS runtime in a browser would most likely
be single threaded (at least, have a thread-per-document, where it

Re: [jvm-l] Re: Trying to apply various techniques of new JS runtimes to JVM dynamic languages

tugwil...@gmail.com (John Wilson) — Thu, 04 Sep 2008 11:05:38 UT

As well as the comic there's this description
[link]
As I understand it each object is an instance of a "hidden class" and
contains a reference to that class. If an object's structure is
mutated by adding a property then a new class, which is a subclass of
the original class, is created and replaces the "hidden class"

Re: [jvm-l] Re: Trying to apply various techniques of new JS runtimes to JVM dynamic languages

szege...@gmail.com (Attila Szegedi) — Thu, 04 Sep 2008 11:05:28 UT

Spot on. Code is data. If it were easy to load new snippets of code
into the JVM and have them GCed when not used, I'd be much less uneasy
about creating a bunch of type-specialized methods from the same
source code; heck, I'd probably even have them being soft-referenced
if possible (as they're just a optimized representation of something

Re: [jvm-l] Re: Trying to apply various techniques of new JS runtimes to JVM dynamic languages

m...@martin-probst.com (Martin Probst) — Thu, 04 Sep 2008 10:08:06 UT

Hi,
Excuse my curiosity, but my basic understanding of this optimization
is like this: in JS, you don't have classes, so every object is
potentially completely different from all others. Therefore, you'd
always need to make the hash lookup when something says "foo.bar", as
everything foo might be is always different. Thus creating these

Re: [jvm-l] Re: Trying to apply various techniques of new JS runtimes to JVM dynamic languages

charles.nut...@sun.com (Charles Oliver Nutter) — Wed, 03 Sep 2008 23:21:34 UT

I'm fresh from reading Rhino source last night. Rhino currently does
probably "level zero" optimization for slot access by caching the most
recently-access hash bucket. As you'd expect, it's only a minimal gain,
and only really useful if you're only using one bucket in sequence. In
practice I'd be surprised if this is very common. I tried upping the

Re: [jvm-l] Trying to apply various techniques of new JS runtimes to JVM dynamic languages

charles.nut...@sun.com (Charles Oliver Nutter) — Wed, 03 Sep 2008 22:29:11 UT

I've toyed with these techniques in JRuby before and always came back to
the same point: yes, they could make things faster by varying degrees,
but in no case was it worth the pain of managing all that transient
code. That is, until anonymous classloading came along.
IMHO the biggest things we need to make easier on JVM:

Re: [jvm-l] Re: Trying to apply various techniques of new JS runtimes to JVM dynamic languages

charles.nut...@sun.com (Charles Oliver Nutter) — Wed, 03 Sep 2008 22:26:15 UT

My understanding of this optimization in V8 is that it's laser-targeted
at probably the biggest bottleneck of Javascript: property lookup. Every
JS impl seems to have their own way of tackling the problem, but the
bottom line is that if you want a decent JS impl you're going to need a
way to optimize name-based property lookup beyond the dumb hash every

Re: [jvm-l] Trying to apply various techniques of new JS runtimes to JVM dynamic languages

john.r...@sun.com (John Rose) — Wed, 03 Sep 2008 21:56:42 UT

To paraphrase a loan commercial: "When VMs compete, language
implementors win."
That's something you can build in JVM bytecodes using invokedynamic.
The call site should use not a generic signature but a signature
which reflects exactly the types known statically to the caller, at
the time it was byte-compiled.

Re: [jvm-l] Trying to apply various techniques of new JS runtimes to JVM dynamic languages

rsch...@sonic.net (Randall R Schulz) — Wed, 03 Sep 2008 21:38:27 UT

I read the "press release" yesterday (probably the most informative
comic I've ever seen, not that I'm a big comic book... I mean graphic
novel reader) but I don't think I can see right off how inferring a
class structure from a lot of instances with similar attribute
structure helps a VM optimize execution.