[squeak-dev] java interpreter/compiler hosted with Spur?

Eliot Miranda eliot.miranda at gmail.com
Wed Jan 29 19:26:28 UTC 2014


Hi Rob,


On Wed, Jan 29, 2014 at 6:16 AM, Robert Withers
<robert.w.withers at gmail.com>wrote:

> sorry for the typos...corrected:
>
> On Jan 29, 2014, at 5:56 AM, Frank Shearar <frank.shearar at gmail.com>
> wrote:
>
> > On 29 January 2014 12:23, Robert Withers <robert.w.withers at gmail.com>
> wrote:
> >>
> >> Exactly, I am suggesting doing inferencing at runtime.  Instead of
> locking those types down, at compile time, be able to do the message send
> Smalltalk wise, then JIT it to be typed.  So dynamically switched from
> dynamic late-binding typing, to an early typing, with the optimizations.
> >>
> >> I figured it could useful to type at runtime, but if it is not needed...
> >
> > Oh, I see. The mention of Scala threw me off to thinking you
> > specifically meant Hindley-Milner, as opposed to, say, k-CFA.I think I
> > asked Eliot about this before: I wanted to know if the VM could expose
> > the types of a particular call site to the image, so that tools could
> > say "after the test suite ran, this method here at this call site is
> > sent to Number", or similar.
>
>
> I only know functional a little.  I still can't think functionally; I
> think objects, but dynamic objects instead of those pojos, DOA.  I do think
> the details of the type systems is interesting.  Specifically, what I
> wanted to do in a typed (though inferenced) language, is to address the
> need for a wrapper proxy on an eventual ref.  One reason we need a wrapper
> is no reference mutations are allowed on the JVM.  If we build Java support
> in Cog, we can change the mutation policy.
>

Again taking a look at the Java support in Smalltalk/X might be worth your
while.


> The other reason is that I wanted the returned promise to be typed as the
> real return and let the inferencer do its thing and rewrite send sites from
> dynamic lookup to direct calls.  I was told that Hindley-Milner was what I
> wanted.  *shrug*
>

Hmmm, I'm so dubious about this kind of approach.  Dynamic lookup, as it is
implemented in typcal Smalltalk JITs, Cog included, is pretty damn quick.
 Rewriting as direct calls would likely only buy you small factors on an
already fast operation.  On the other hand, allowing the type inferencer to
function well across the dynamic call seems like a sane desire.

Getting to the type info at runtime is key, I think.  Aren't there 2 types
> of type systems?  Type vs class?  Do you or anyone know about that?
>

The thing is that the former, at least at run-time, is not really a type
system, it's just type information, specifically the set of classes of
receiver that have been encountered since the start of execution, or since
the last method cache flush, up to this point.  That's proved to be
enormously useful information to guide a dynamic optimizer, but it doesn't
predict the types to be encountered in the future (and hence any optimizer
based on this info must guard against new types running the optimized code,
and typically deoptimize and reoptimize whenever new types are used in the
code).  You could use that information to provide info for the programmer
(eg. run unit tests and then report back on the types encountered), but
that's soft information, not an exhaustive proof of all possible types
encountered for all time.

The strategy behind my request is to see if Cog could support multiple
> languages and modern languages - i.e. broadly used languages.


Well Smalltalk/X is an existence proof.  I'm sure that Cog could support
Java on this basis.  And at Cadence we've implemented a JavaScript-like
language above Smalltalk.  But providing a working system in some limited
domain is far different than generally supporting e.g. Java, being able to
pass all the test suites, interoperate, etc.  That's proved a huge task/.
 I don't want to duscurage you from taking a tilt at this, but it really
helps to understand the scope.  Being able to run scala makes sense; that's
limited.  But I wonder if the right approach wouldn;t be to rewrite the
scala compiler to target Smalltalk bytecodes directly.  Wouldn't that be
simpler?  e.g.:

- Write a scala-to-Smalltalk translator, e.g. source-to-source, written in
either scala or smalltalk
- design and implement the scala run-time system for scala in Smalltalk
(sis??)
- translate the scala compiler to Smalltalk
- write a back-end for this compiler that targets Smalltalk bytecode,
written in scala
- bootstrap


>  It seems a dynamic runtime is better than a static vm to support both
> flavors of languages, though runtime feedback type inferencing seems
> important, in my gut.  Maybe it is just cool tech, great for ops.
>

I think its accepted that runtime type feedback is great for optimization,
and I expect it will be great for program comprehensibility too, not that
I'm aware of much work that's been done here.  But yes, it would be very
interesting to see how scala faired above a much more dynamic vm.

- Robert
>
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140129/be5e865c/attachment.htm


More information about the Squeak-dev mailing list