Smalltalk › Redline Smalltalk

A few thoughts

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

JONNALAGADDA Srinivas

A few thoughts

James,

Since you have mentioned that you will be spending some substantial effort on Redline over the next few days, I voice some thoughts here. I have not studied the compiler part of the source so far, so I may have made some invalid assumptions, too. Please correct them.

1. We should target JRE/JDK 1.7 not 1.5

With Java 1.6 reaching end of life (public updates themselves will end in Feb 2013), we do not gain anything by maintaining compatibility strictly on the level of 1.5 (refer the Getting Started page). Enterprises, which are the places still lagging in terms of adoption of 1.7, are anyway in no great hurry to deploy Redline into production :-). In addition, we will not be able to utilise invokedynamic, etc., if we continue to target 1.5 compatibility.

2. Per-object overhead

(a) Currently, the per-object memory allocation requirement is quite high. Object itself supports indexed attributes, and has an array to support that. The Blue Book mandates the protocol on Object, but not necessarily its satisfaction at that level. It can be subclass responsibility.

(b) It should be possible to make the definition of PrimObject a little leaner. For instance, it can have:

reference to its class.

The underlying value can be obtained through delegated (to subclasses) calls.

reference to its metaclass,
reference to its superclass,
javax.lang.model.type.TypeKind to indicate the actual type represented by this PrimObject.

(d) Concrete subclasses of PrimObject can be defined for all those types that can be natively represented in the JVM. Those representing primitive JVM types can actually have internal representations that match their corresponding native JVM types. Only those corresponding to the DECLARED type need instance variables (and, optionally, indexed variables for collection types). The new Map approach that you mentioned in a different post earlier today, works well for such types.

The above have a big bearing on the foundations. That is why I moot the discussion now! Thanks.

-- |0|0|

James Ladd

Re: A few thoughts

Hey Srinivas,

Answers inline below.

On Sun, Dec 30, 2012 at 4:39 PM, JONNALAGADDA Srinivas <[hidden email]> wrote:

James,

Since you have mentioned that you will be spending some substantial effort on Redline over the next few days, I voice some thoughts here. I have not studied the compiler part of the source so far, so I may have made some invalid assumptions, too. Please correct them.

1. We should target JRE/JDK 1.7 not 1.5

With Java 1.6 reaching end of life (public updates themselves will end in Feb 2013), we do not gain anything by maintaining compatibility strictly on the level of 1.5 (refer the Getting Started page). Enterprises, which are the places still lagging in terms of adoption of 1.7, are anyway in no great hurry to deploy Redline into production :-). In addition, we will not be able to utilise invokedynamic, etc., if we continue to target 1.5 compatibility.

If public updates are ending in Feb 2013 for 1.6 then it would make sense to move to 1.7.
I'd like to think that Enterprises are 'not yet' in a great hurry to adopt :)
The invokeDynamic functionality is off by default in JDK 1.7 and needs a switch to
enable. It should also be noted that Redline doesn't currently make use of
invokeDynamic. I'm looking into it and how to adapt.

2. Per-object overhead

(a) Currently, the per-object memory allocation requirement is quite high. Object itself supports indexed attributes, and has an array to support that. The Blue Book mandates the protocol on Object, but not necessarily its satisfaction at that level. It can be subclass responsibility.

Personally I don't think the per object overhead is high, however I'm open to a suggested
Object format that is capable of being a lower overhead and yet cater for the needs of
being a Smalltalk.

(b) It should be possible to make the definition of PrimObject a little leaner. For instance, it can have:

reference to its class.
The underlying value can be obtained through delegated (to subclasses) calls.

Note, currently there is not a 1-to-1 mapping of a Java class to Smalltalk class.
This is because a Smalltalk class can change its shape at runtime. Changing both
methods, variables and even hierarchy.

(c) PrimObjectClass can have:

reference to its metaclass,
reference to its superclass,
javax.lang.model.type.TypeKind to indicate the actual type represented by this PrimObject.

(d) Concrete subclasses of PrimObject can be defined for all those types that can be natively represented in the JVM. Those representing primitive JVM types can actually have internal representations that match their corresponding native JVM types. Only those corresponding to the DECLARED type need instance variables (and, optionally, indexed variables for collection types). The new Map approach that you mentioned in a different post earlier today, works well for such types.

The above have a big bearing on the foundations. That is why I moot the discussion now! Thanks.

I am trying to minimize the overheads and keep the needs of a Class object separate from those
of an Instance object. The simplest yet not the most speedy of implementations would be a single
Map.

-- |0|0|

JONNALAGADDA Srinivas

Re: A few thoughts

On Monday, 31 December 2012 02:36:22 UTC+5:30, jamesl wrote:

Note, currently there is not a 1-to-1 mapping of a Java class to Smalltalk class.
This is because a Smalltalk class can change its shape at runtime. Changing both
methods, variables and even hierarchy.

In my limited experience, I have seen that - in practice - dynamic addition of variables and methods is a relatively infrequent occurrence. I acknowledge that there exist classes of problems (such as ORMs) where that capability can be central. The cost can be higher for infrequent operations, should it help lower the costs for frequent cases.

As an example, please look at the approach taken by Pharo. Please look at ClassBuilder's mechanisms for an illustration of the ``higher cost for infrequent operations philosophy"! [In particular, the class is not modified in-place, and hence there is no provision for in-place extensions.] I am not necessarily arguing that it is a better approach; just tabling the topic! Thanks.

-- |0|0|

James Ladd

Re: A few thoughts

Thanks for the reference - I want to get Redline out and in use before optimising - I hope you are still interested when that happens as I like your ideas

- James

Sent from Hyperspace.

On 31/12/2012, at 2:03 PM, JONNALAGADDA Srinivas <[hidden email]> wrote:

On Monday, 31 December 2012 02:36:22 UTC+5:30, jamesl wrote:
Note, currently there is not a 1-to-1 mapping of a Java class to Smalltalk class.
This is because a Smalltalk class can change its shape at runtime. Changing both
methods, variables and even hierarchy.

In my limited experience, I have seen that - in practice - dynamic addition of variables and methods is a relatively infrequent occurrence. I acknowledge that there exist classes of problems (such as ORMs) where that capability can be central. The cost can be higher for infrequent operations, should it help lower the costs for frequent cases.

As an example, please look at the approach taken by Pharo. Please look at ClassBuilder's mechanisms for an illustration of the ``higher cost for infrequent operations philosophy"! [In particular, the class is not modified in-place, and hence there is no provision for in-place extensions.] I am not necessarily arguing that it is a better approach; just tabling the topic! Thanks.

-- |0|0|

JONNALAGADDA Srinivas

Re: A few thoughts

On Monday, 31 December 2012 09:18:16 UTC+5:30, jamesl wrote:

Thanks for the reference - I want to get Redline out and in use before optimising

Sure, James, I agree!

- I hope you are still interested when that happens

Of course :-).

as I like your ideas

Thank you!

-- |0|0|