Smalltalk › Squeak › Squeak - Dev

java interpreter/compiler hosted with Spur?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

39 messages Options

charlie robert

java interpreter/compiler hosted with Spur?

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? COudl a scala type inferencer be built in Spur’s runtime? runtime?

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? 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?

so sorry for all that noise ,

- charlie (Rob WIthers)

Eliot Miranda-2

Re: java interpreter/compiler hosted with Spur?

Hi Charlie,

On Fri, Jan 24, 2014 at 9:11 PM, charlie robert <[hidden email]> 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?

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?

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.

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?

so sorry for all that noise ,

- charlie (Rob WIthers)

--
best,

Eliot

Colin Putney-3

Re: java interpreter/compiler hosted with Spur?

On Tue, Jan 28, 2014 at 3:54 PM, Eliot Miranda <[hidden email]> wrote:

> https://plus.google.com/+KentonVarda/posts/GRJ4h4w2UN9? Or am I being
> cynical?

Yeah, I think that's what he was talking about. It's hard to see how
dynamic languages could use Cap'n Proto, because they don't tend to
give enough low-level control over memory layout in the heap.

Eliot Miranda-2

Re: java interpreter/compiler hosted with Spur?

On Tue, Jan 28, 2014 at 1:08 PM, Colin Putney <[hidden email]> wrote:

On Tue, Jan 28, 2014 at 3:54 PM, Eliot Miranda <[hidden email]> wrote:

> https://plus.google.com/+KentonVarda/posts/GRJ4h4w2UN9? Or am I being
> cynical?

Yeah, I think that's what he was talking about. It's hard to see how
dynamic languages could use Cap'n Proto, because they don't tend to
give enough low-level control over memory layout in the heap.

Wouldn't pinning be enough? No, because one needs to intermix binary data and objects. But if one added a ref type, or some object handle type, so there's just one level of indirection from a handle in the protobuf and an object, that might get far enough no?

The alternative would be to add struct support to Spur which might be doable. But it's a lot of work for a rather specific application. Anyway, I'm open to others experimenting on this.

Reminds me of work Tony Mann at Harlequin did or described to me, which again is reminiscent of Digitalk's object layout. The idea is to have the class reference in an object (even if this is an index into a table) not point directly to the class object, but to refer to some intermediate, possibly hidden, structure.

In The Harlequin case this structure included code that would be run by the GC to traverse the object, which is how the system supports heterogenous structures, and saves on a size field (except for variable-sized objects).

In the Digitalk case the structure is a method dictionary, which allows the system to support easily instance-specific behaviours. (Forgive the digression).
--
best,

Eliot

charlie robert

Re: java interpreter/compiler hosted with Spur?

I was thinking that handle may be a capability ref, mutable in the scope of the ref state machine.

Thank you,

Robert

On Jan 28, 2014, at 2:36 PM, Eliot Miranda <[hidden email]> wrote:

On Tue, Jan 28, 2014 at 1:08 PM, Colin Putney <[hidden email]> wrote:

On Tue, Jan 28, 2014 at 3:54 PM, Eliot Miranda <[hidden email]> wrote:

> https://plus.google.com/+KentonVarda/posts/GRJ4h4w2UN9? Or am I being
> cynical?

Yeah, I think that's what he was talking about. It's hard to see how
dynamic languages could use Cap'n Proto, because they don't tend to
give enough low-level control over memory layout in the heap.

Wouldn't pinning be enough? No, because one needs to intermix binary data and objects. But if one added a ref type, or some object handle type, so there's just one level of indirection from a handle in the protobuf and an object, that might get far enough no?

The alternative would be to add struct support to Spur which might be doable. But it's a lot of work for a rather specific application. Anyway, I'm open to others experimenting on this.

Reminds me of work Tony Mann at Harlequin did or described to me, which again is reminiscent of Digitalk's object layout. The idea is to have the class reference in an object (even if this is an index into a table) not point directly to the class object, but to refer to some intermediate, possibly hidden, structure.

In The Harlequin case this structure included code that would be run by the GC to traverse the object, which is how the system supports heterogenous structures, and saves on a size field (except for variable-sized objects).

In the Digitalk case the structure is a method dictionary, which allows the system to support easily instance-specific behaviours. (Forgive the digression).
--
best,
Eliot

Robert Withers

Re: java interpreter/compiler hosted with Spur?

In reply to this post by Eliot Miranda-2

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 <[hidden email]> wrote:

Hi Charlie,

On Fri, Jan 24, 2014 at 9:11 PM, charlie robert <[hidden email]> 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.

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? 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.

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 '

Indeed, best,

Robert

so sorry for all that noise ,

- charlie (Rob WIthers)

--
best,
Eliot

Frank Shearar-3

Re: java interpreter/compiler hosted with Spur?

On 29 January 2014 04:15, Rob Withers <[hidden email]> 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 <[hidden email]> wrote:
>
> Hi Charlie,
>
>
> On Fri, Jan 24, 2014 at 9:11 PM, charlie robert <[hidden email]>
> 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

>> 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? 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.
>
>> 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 '
>
> Indeed, best,
> Robert
>
>
>>
>> so sorry for all that noise ,
>> - charlie (Rob WIthers)
>
>
> --
> best,
> Eliot

Robert Withers

Re: java interpreter/compiler hosted with Spur?

On Jan 29, 2014, at 3:14 AM, Frank Shearar <[hidden email]> wrote:

> On 29 January 2014 04:15, Rob Withers <[hidden email]> 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 <[hidden email]> wrote:
>>
>> Hi Charlie,
>>
>>
>> On Fri, Jan 24, 2014 at 9:11 PM, charlie robert <[hidden email]>
>> 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...

- Robert

smime.p7s (3K) Download Attachment

Frank Shearar-3

Re: java interpreter/compiler hosted with Spur?

On 29 January 2014 12:23, Robert Withers <[hidden email]> wrote:

>
> On Jan 29, 2014, at 3:14 AM, Frank Shearar <[hidden email]> wrote:
>
>> On 29 January 2014 04:15, Rob Withers <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>> Hi Charlie,
>>>
>>>
>>> On Fri, Jan 24, 2014 at 9:11 PM, charlie robert <[hidden email]>
>>> 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
>
>

Robert Withers

Re: java interpreter/compiler hosted with Spur?

On Jan 29, 2014, at 5:56 AM, Frank Shearar <[hidden email]> wrote:

> On 29 January 2014 12:23, Robert Withers <[hidden email]> wrote:
>>
>> On Jan 29, 2014, at 3:14 AM, Frank Shearar <[hidden email]> wrote:
>>
>>> On 29 January 2014 04:15, Rob Withers <[hidden email]> 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 <[hidden email]> wrote:
>>>>
>>>> Hi Charlie,
>>>>
>>>>
>>>> On Fri, Jan 24, 2014 at 9:11 PM, charlie robert <[hidden email]>
>>>> 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.

I don’t know functional but 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 kind of interesting. Specifically, of what I wanted to do in a typed (though inferenced) language, we to address the need for a wrapper proxy. One reason is no reference mutations are allowed on the JVM. The other is I wanted the returned promise to be typed as the real return and let the inferencer do its thing. I was told that Hindley-Milner was what I wanted. *shrug*

Getting to the type info is key, I think. Aren’t there 2 types of type systems? Do you or anyone know about that?

The strategy behind my request is to see if Cog could support multiple languages and modern languages. 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.

- Robert

smime.p7s (3K) Download Attachment

Robert Withers

Re: java interpreter/compiler hosted with Spur?

sorry for the typos…corrected:

On Jan 29, 2014, at 5:56 AM, Frank Shearar <[hidden email]> wrote:

> On 29 January 2014 12:23, Robert Withers <[hidden email]> 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.

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*

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 strategy behind my request is to see if Cog could support multiple languages and modern languages - i.e. broadly used languages. 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.

- Robert

smime.p7s (3K) Download Attachment

Frank Shearar-3

Re: java interpreter/compiler hosted with Spur?

On 29 January 2014 14:16, Robert Withers <[hidden email]> wrote:

> sorry for the typos…corrected:
>
> On Jan 29, 2014, at 5:56 AM, Frank Shearar <[hidden email]> wrote:
>
>> On 29 January 2014 12:23, Robert Withers <[hidden email]> 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.

Hindley-Milner is a particular way of enforcing static type checks
through inference. It happens to be a _very good_ way of doing this,
but I'm sure it's not the only way.

> 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.

> 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*

Um, that sounds a bit weird, to be honest. A promise surely _can't_ be
typed as the real return since there _is_ no real return: a promise
can break! In Scala-ish terms (I've not written any Scala for about
two years...), a Promise[Int] is fundamentally different to an Int
because the latter is just a value whereas the former may or may not
result at some point in a value. It's only once a Promise has resolved
that things get interesting. And it sounds here like this is when
you'd like to optimise the Promise wrapper away, right?

> 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 study of type systems is a rather big subject!

> The strategy behind my request is to see if Cog could support multiple languages and modern languages - i.e. broadly used languages. 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.

Cog _does_ support multiple languages: Squeak and Newspeak. Given that
Ruby can run on top of Gemstone (Maglev), there shouldn't be an issue
with running other languages on top of Cog... assuming there's someone
sufficiently interested/available to actually _do_ that. (Oh, and of
course IBM ran Java on top of a Smalltalk VM in Visual Age for Java.)

frank

> - Robert

Jecel Assumpcao Jr

Re: java interpreter/compiler hosted with Spur?

Frank Shearar wrote:

> Cog _does_ support multiple languages: Squeak and Newspeak. Given that
> Ruby can run on top of Gemstone (Maglev), there shouldn't be an issue
> with running other languages on top of Cog... assuming there's someone
> sufficiently interested/available to actually _do_ that. (Oh, and of
> course IBM ran Java on top of a Smalltalk VM in Visual Age for Java.)

I didn't know that. I had always thought that the IBM team had written
all the development tools in Smalltalk but that the resulting code ran
on a conventional Java VM.

Note that the Java implementation on Self was sufficiently impressive
that it convinced Sun to buy Animorphic and do the HotSpot VM. That
project, called Pepe, was described in:

http://www.merlintec.com/vmworkshop99/sub.pdf

"Towards a Universal Implementation Substrate for Object-Oriented
Language"
Mario Wolczko, Ole Agesen, David Ungar

-- Jecel

Frank Shearar-3

Re: java interpreter/compiler hosted with Spur?

In reply to this post by Frank Shearar-3

On 29 January 2014 16:37, Jecel Assumpcao Jr. <[hidden email]> wrote:

> Frank Shearar wrote:
>
>> Cog _does_ support multiple languages: Squeak and Newspeak. Given that
>> Ruby can run on top of Gemstone (Maglev), there shouldn't be an issue
>> with running other languages on top of Cog... assuming there's someone
>> sufficiently interested/available to actually _do_ that. (Oh, and of
>> course IBM ran Java on top of a Smalltalk VM in Visual Age for Java.)
>
> I didn't know that. I had always thought that the IBM team had written
> all the development tools in Smalltalk but that the resulting code ran
> on a conventional Java VM.

A little bit of digging reveals this:
https://web.archive.org/web/20090122105548/http://talklikeaduck.denhaven2.com/articles/2008/10/15/will-it-go-round-in-circles
which looks like it was written by Rick DeNatale (judging by the "I
served as the secretary of X3J20." sentence.)

frank

> Note that the Java implementation on Self was sufficiently impressive
> that it convinced Sun to buy Animorphic and do the HotSpot VM. That
> project, called Pepe, was described in:
>
> http://www.merlintec.com/vmworkshop99/sub.pdf
>
> "Towards a Universal Implementation Substrate for Object-Oriented
> Language"
> Mario Wolczko, Ole Agesen, David Ungar
>
> -- Jecel
>
>

Robert Withers

Re: java interpreter/compiler hosted with Spur?

In reply to this post by Frank Shearar-3

On Jan 29, 2014, at 7:41 AM, Frank Shearar <[hidden email]> wrote:

> On 29 January 2014 14:16, Robert Withers <[hidden email]> wrote:
>
>> 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*
>
> Um, that sounds a bit weird, to be honest. A promise surely _can't_ be
> typed as the real return since there _is_ no real return: a promise
> can break! In Scala-ish terms (I've not written any Scala for about
> two years...), a Promise[Int] is fundamentally different to an Int
> because the latter is just a value whereas the former may or may not
> result at some point in a value. It's only once a Promise has resolved
> that things get interesting. And it sounds here like this is when
> you'd like to optimise the Promise wrapper away, right?

I was under the impression that Hindley-Milner was able to construct union types, which is why it was recommended to me.

>
>> The strategy behind my request is to see if Cog could support multiple languages and modern languages - i.e. broadly used languages. 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.
>
> Cog _does_ support multiple languages: Squeak and Newspeak. Given that
> Ruby can run on top of Gemstone (Maglev), there shouldn't be an issue
> with running other languages on top of Cog... assuming there's someone
> sufficiently interested/available to actually _do_ that. (Oh, and of
> course IBM ran Java on top of a Smalltalk VM in Visual Age for Java.)

It may be clearer for me to say that it would be awfully nice if Cog allowed for bytecode virtualization. In 64-bit values, a couple of bits for bytecode index (have a cache of 4 bytecode sets, so 4 different languages, concurrently executing). Add a bit for a capability/promise for pipelining. All at the expense of the range of the immediates, but maybe that’s ok, I do not know.

- Robert

smime.p7s (3K) Download Attachment

Eliot Miranda-2

Re: java interpreter/compiler hosted with Spur?

In reply to this post by charlie robert

Hi Charli,

On Tue, Jan 28, 2014 at 5:54 PM, charlie robert <[hidden email]> wrote:

I was thinking that handle may be a capability ref, mutable in the scope of the ref state machine.

Perhaps you're assuming much more knowledge about Cap'n Proto than I have. Could you explain the above? I have no idea which state machine you're talking about. Sorry :-(

Thank you,
Robert

On Jan 28, 2014, at 2:36 PM, Eliot Miranda <[hidden email]> wrote:

On Tue, Jan 28, 2014 at 1:08 PM, Colin Putney <[hidden email]> wrote:

On Tue, Jan 28, 2014 at 3:54 PM, Eliot Miranda <[hidden email]> wrote:

> https://plus.google.com/+KentonVarda/posts/GRJ4h4w2UN9? Or am I being
> cynical?

Yeah, I think that's what he was talking about. It's hard to see how
dynamic languages could use Cap'n Proto, because they don't tend to
give enough low-level control over memory layout in the heap.

Wouldn't pinning be enough? No, because one needs to intermix binary data and objects. But if one added a ref type, or some object handle type, so there's just one level of indirection from a handle in the protobuf and an object, that might get far enough no?

The alternative would be to add struct support to Spur which might be doable. But it's a lot of work for a rather specific application. Anyway, I'm open to others experimenting on this.

Reminds me of work Tony Mann at Harlequin did or described to me, which again is reminiscent of Digitalk's object layout. The idea is to have the class reference in an object (even if this is an index into a table) not point directly to the class object, but to refer to some intermediate, possibly hidden, structure.

In The Harlequin case this structure included code that would be run by the GC to traverse the object, which is how the system supports heterogenous structures, and saves on a size field (except for variable-sized objects).

In the Digitalk case the structure is a method dictionary, which allows the system to support easily instance-specific behaviours. (Forgive the digression).
--
best,
Eliot

--
best,

Eliot

Eliot Miranda-2

Re: java interpreter/compiler hosted with Spur?

In reply to this post by Robert Withers

Hi Rob,

On Tue, Jan 28, 2014 at 8:15 PM, Rob Withers <[hidden email]> 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 <[hidden email]> wrote:

Hi Charlie,

On Fri, Jan 24, 2014 at 9:11 PM, charlie robert <[hidden email]> 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

Jecel Assumpcao Jr

Re: java interpreter/compiler hosted with Spur?

In reply to this post by Frank Shearar-3

Frank Shearar wrote:

> A little bit of digging reveals this:
> https://web.archive.org/web/20090122105548/http://talklikeaduck.denhaven2.com/articles/2008/10/15/will-it-go-round-in-circles
> which looks like it was written by Rick DeNatale (judging by the "I
> served as the secretary of X3J20." sentence.)

Thanks for the information! I was aware of Smalltalk/X using dual
bytecode sets but didn't know it had been done previously. Allowing
multiple bytecodes is one of the features planned for Cog, right? My own
design allows multiple bytecodes but it is very costly to switch between
them.

-- Jecel

Eliot Miranda-2

Re: java interpreter/compiler hosted with Spur?

In reply to this post by Robert Withers

Hi Rob,

On Wed, Jan 29, 2014 at 6:16 AM, Robert Withers <[hidden email]> wrote:

sorry for the typos…corrected:

On Jan 29, 2014, at 5:56 AM, Frank Shearar <[hidden email]> wrote:

> On 29 January 2014 12:23, Robert Withers <[hidden email]> 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

Eliot Miranda-2

Re: java interpreter/compiler hosted with Spur?

In reply to this post by Frank Shearar-3

On Wed, Jan 29, 2014 at 12:14 PM, Jecel Assumpcao Jr. <[hidden email]> wrote:

Frank Shearar wrote:

> A little bit of digging reveals this:
> https://web.archive.org/web/20090122105548/http://talklikeaduck.denhaven2.com/articles/2008/10/15/will-it-go-round-in-circles
> which looks like it was written by Rick DeNatale (judging by the "I
> served as the secretary of X3J20." sentence.)

Thanks for the information! I was aware of Smalltalk/X using dual
bytecode sets but didn't know it had been done previously. Allowing
multiple bytecodes is one of the features planned for Cog, right?

Cog already supports multiple bytecode sets. The current compiled method header format has only space for a single bit so Cog currently supprts two bytecode sets. The Squeak VMs support only the current Squeak V3 + closures bytecode set (see EncoderForV3PlusClosures).

Teh Newspeak VMs support that, extended with two bytecodes for the old Newspeak implementation, and a new bytecode set that I designed for Newspeak that supports absent receiver sends. It's very much a first cut and we may do more bytecode sets. In a Newspeak image look for EncoderForNewsqueakV4, and in the VMMaker package look for initializeBytecodeTableForNewspeakV4

My own
design allows multiple bytecodes but it is very costly to switch between
them.

Why is it costly?

In Cog it is essentially free in the JIT, and in the interpreter it is a matter of testing a flag on method activation and return and setting the bytecode set offset as a result. I'm grateful to Claus Gittinger for this technique.

So in the Cog Newspeak Interpreter the bytecode dispatch case statement has 512 entries, 256 for the Squeak V3 + Closures + Newspeak set, and 256 for the NewsqueakV4 set. The dispatch looks like

fetchNextBytecode

"This method fetches the next instruction (bytecode). Each bytecode method is responsible for fetching the next bytecode, preferably as early as possible to allow the memory system time to process the request before the next dispatch."

self cppIf: MULTIPLEBYTECODESETS

ifTrue: [currentBytecode := self fetchByte + bytecodeSetSelector]

ifFalse: [currentBytecode := self fetchByte]

setMethod: aMethodObj

"Set the method and determine the bytecode set based on the method header's sign.

If MULTIPLEBYTECODESETS then a negative header selects the alternate bytecode set.

Conditionalizing the code on MULTIPLEBYTECODESETS allows the header sign bit to be

used for other experiments."

<inline: true>

method := aMethodObj.

self assert: (objectMemory isOopCompiledMethod: method).

self cppIf: MULTIPLEBYTECODESETS

ifTrue: [bytecodeSetSelector := (self methodUsesAlternateBytecodeSet: method)

ifTrue: [256]

ifFalse: [0]]

where setMethod: is called on return, and its close twin setMethod:methodHeader: is called on frame build.

--
best,

Eliot