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

Eliot Miranda eliot.miranda at gmail.com
Wed Jan 29 19:08:09 UTC 2014


Hi Rob,


On Tue, Jan 28, 2014 at 8:15 PM, 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.
>

Have you had a look at Smalltalk/X?  They have a compiled method format
that allows up to four distinct bytecode sets and one of these is Java.  So
they may have a lot of what you want (which is doable, but a substantial
project with duration I estimate in the in the 2-5 person-years range)  .

To better understand your underlying motivations could you state what's
unsatisfactory about running scala on Java VMs?  (and in language that a
neophyte like me can understand?  I know Java a little and more about Java
VMs but I don't know scala).

 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've read ahead to the exchange between you and Frank Shearer so I'm
chearting here.  It helped a lot].

Fascinating.

So the issue is that on the Smalltalk side there's dynamic typing and on
the java/scala side there's static typing right?  And you want to check the
call for type safety at the time of call and allow it to proceed if safe?
 My immediate reaction is that down in the VM is far too low-level a place
to implement this, quite complex, functionality.  Implementing it in
Smalltalk in some sort of wrapper class for scala/java objects allows you
lots of freedom in implementation, cacheing previous results, and not least
efficient development; implementing at the VM level is alas slow, even in
the simulator.

Is there a necessity to push it down to the VM level?

Wouldn't it make more sense to get a working system at the Smalltalk level
and then push this down once the design was fully determined and you'd
profiled?


> Eliot, I am quite intrigued on your blog post on Spur's object stack
>> representation.  Does this format touch on the heap structure of an object?
>>
>
> What exactly do you mean by "Spur's object stack representation"?  Do you
> mean Spur's object representation, or do you mean the ObjStack datatype?
>  The latter is merely a segmented stack, like building OrderedCollection
> out of a linked list of pages, each page containing up to N elements.
>
>
>
> So Spur specifies heap structure?
>

Right.  Sista, which is being worked on mostly by Clément Bera, is the name
we've given to Cog's support for adaptive optimization and speculative
inlining (Sista = Speculative Inlining Small talk Architecture).  One part
of the VM infrastructure for Sista is a primitive that yields the satte of
the inline caches in a method.  That's I suspect the kind of type
informaiton youre after.  Am I right?


> Vis-a-Vis the lack of interoperability, Cap'n Proto would be just the
> thing to interoperate java and squeak and scala and groovy.   You own the
> metal so you can do whatever you imagine.
>

Right.

 Either way, using Cap'n Proto in the heap and Spur for the stack/queue
>> structures would be really nice if someone had one.  Does a lord or lady
>> own such a magic item +4?  on a raspberry?
>>
>
> https://plus.google.com/+KentonVarda/posts/GRJ4h4w2UN9?  Or am I being
> cynical?
>
>
> I am missing all this, 'cuse me '
>

Your initial post went rather over my head and I thought perhaps you were
pulling my chain.  I googled Cap'n Proto and saw "Cap'n Proto april fool"
and thought that I might be being led down the path :-).  I can see now
that's far from the case.  Forgive me.


> Indeed, best,
> Robert
>
> so sorry for all that noise ,
>>  - charlie (Rob WIthers)
>>
>
> --
> best,
> Eliot
>
>
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140129/97c75489/attachment.htm


More information about the Squeak-dev mailing list