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

Frank Shearar frank.shearar at gmail.com
Wed Jan 29 12:56:26 UTC 2014


On 29 January 2014 12:23, Robert Withers <robert.w.withers at gmail.com> wrote:
>
> On Jan 29, 2014, at 3:14 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
>
>> On 29 January 2014 04:15, Rob Withers <robert.w.withers at gmail.com> wrote:
>>> Ok, I'm Robert, for professional reasons and done.  Charlie Robert is my
>>> nickname from long time back.  So let me stick to this email address...
>>>
>>> On Jan 28, 2014, at 1:54 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>>
>>> Hi Charlie,
>>>
>>>
>>> On Fri, Jan 24, 2014 at 9:11 PM, charlie robert <charlie.robert at icloud.com>
>>> wrote:
>>>>
>>>> I was curious whether java may be used in Cog.  I recall a fair project
>>>> with the serialization and core pojo representation, but my memory   Might
>>>> java interoperate natively, so as to call a java function in smalltalk, as a
>>>> smalltalk call with a closure/continuation, or perhaps in the other
>>>> direction?
>>>
>>>
>>> I'm sure one can write a Smalltalk/Java interconnect.  There are a number of
>>> ways to do it.  What are your requirements?  What do you mean by "native"
>>> operation?  e.g. VisualAgeForJava?
>>>
>>>
>>> My requirements, hmm.
>>>
>>> 1 - I would like to have .class files able to load in your VM/ObjectMemory.
>>> 2 - I would like java byte codes "JITted" into Smalltalk byte codes.
>>> 3 - I would like if one side (squeak) could invoke the other side (java)
>>> without explicit wrappers, and vice versa.  I mean this as native.
>>> 4 - I would like java serialization support.
>>> 5 - like JVM 8 has a byte code for reflective lookup, I would like Smalltalk
>>> bytecodes to have one bytecode for direct invocation, and bypass the
>>> reflective meta call
>>> 6 - I want to run scala on Cog/Spur
>>> 7 - then the "JIT"...I would like the program to start in dynamic mode then
>>> "JIT" with a call to the inferencer to determine type.
>>>
>>> This way, we have a JVM with mutable refs (become) so it would be a JVM++.
>>>
>>> The thing that gets me is that barely anything really interoperates.
>>>
>>>
>>>>
>>>> COudl a scala type inferencer be built in Spur’s runtime? runtime?
>>>
>>>
>>> I'm not sure what you mean.  Could you elaborate?  Spur is an object
>>> representation and set of garbage collection/memory management facilities.
>>> As such wouldn't it live below any type inferencer?
>>>
>>>
>>> Ok it is the inner Cog axle I think of, not Spur.  The lookup and invocation
>>> of a send, of a method.  At its root handler it could call an inline scala
>>> type inferencer.
>>
>> I don't understand this. Type inference happens at compile time. Once
>> you have bytecodes, there is no type inference going on.
>>
>> As an example, once Scala has compiled, method lookup is all about JVM
>> bytecodes, which have no idea about the Scala type system. In fact,
>> the Scala-ness has _disappeared_ after compilation, which is why you
>> can decompile the bytecodes as plain Java. (Well, where "plain" means
>> "mangled to pieces, and has random metadata scattered everywhere".)
>>
>> frank
>
> 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.

frank

> - Robert
>
>


More information about the Squeak-dev mailing list