[ANN] Hydra VM: A multi-core capable Croquet VM

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] for the *hard* way [was: [ANN] Hydra VM: A multi-core capable Croquet VM]

Klaus D. Witzel
On Fri, 22 Feb 2008 18:43:37 +0100, Andreas wrote:

> Igor Stasenko wrote:
>> Well, there is people who wish to see such capabilities, and if Spoon
>> features orthogonal to your approach, then why not include them?
>
> Because there is cost associated with it. Probably some runtime cost  
> (which I haven't measured) but definitely cost in terms of added  
> complexity in the VM.
>
>> In this case both camps will feel suited with new VM and can use it in
>> one way or another.
>
> My problem with this is that I cannot see any situation in which someone  
> would really want to rely on that mechanism. It seems to me that the  
> approach is (as you said in an earlier email) a way to create smaller  
> images "without much effort". I'm interested in the *hard* way of doing  
> this (i.e., by going in and refactoring and removing things manually)  
> because I think this is the only way in which it can be done in practice.

As an example, in the 3.9 stock .image there are some 434 methods in just  
49 classes which have directly to do (sending messages to one another)  
with compilation, class building, decompilation and context (#fork etc).

Some 73 "system,kernel" classes (from magnitude, collection, stream,  
exception, traits) and some 21 supportive global instances (+classes for  
source code support and text/style support, +"misc") are referenced  
directly (by name) by the methods of the above.

Lists with details are at the bottom. The references to #(PopupMenu,  
FileDirectory, FileStream, text/style support, SecurityManager, Sensor)  
can be moved out of the way of classes responsible for compilation, class  
building, decompilation and context, by refactoring and removing things  
manually.

I could do the same analysis+report, with other details and/or constraints  
(I'm using my datalog query tool in Squeak) for the next layer, and  
between layers (example: the above 49 classes' methods v.s. collections,  
streams, magnitudes), for any reasonable .image, if that's interesting for  
Squeakers.

/Klaus

> But be that as it may - the real question is this: Let's assume we have  
> a tiny kernel image that is about 100k in size and that we can build up  
> from. What good is the mechanism at this point? It seems to me that it  
> is only useful to get to a small image but once this is achieved it's  
> basically obsolete.

Right. That's why I'm doing analysis+report in a workspace and not in a  
fancy new UI :)

> And I'm definitely not in favor to modify the VM for something that will  
> only have a very short window of usefulness.
>
> Cheers,
>    - Andreas
>

List of the 21 global instances (+source code support +text/style support  
+"misc"):
#(#ColoredCodeStream #FileDirectory #FileStream #FullVocabulary #PopUpMenu  
#PrimitiveNode #Processor #RemoteString #ScreenedVocabulary  
#SecurityManager #Sensor #Smalltalk #SourceFiles #SyntaxError  
#SystemOrganization #TextConstants #TextMorphEditor #TextStyle #Transcript  
#UIManager #Undeclared)

List of the 73 "system,kernel" classes, used by name by the classes at the  
bottom:
#(#Array #Association #AttemptToWriteReadOnlyGlobal #Bag #Beeper  
#BlockCannotReturn #BreakpointManager #ByteArray #ByteString #ChangeSet  
#Character #ClassCategoryReader #ClassCommentReader #Date #Dictionary  
#DiskProxy #Duration #Error #ExceptionAboutToReturn  
#FileDoesNotExistException #Float #IdentityDictionary #IdentitySet  
#ImageSegment #ImageSegmentRootStub #InMidstOfFileinNotification  
#InstVarRefLocator #InstructionPrinter #LargeNegativeInteger  
#LargePositiveInteger #LocalSends #Message #MessageCatcher  
#MessageNotUnderstood #MethodDictionary #MethodReference #Number #Object  
#OrderedCollection #OutOfScopeNotification #ParserRemovedUnusedTemps  
#PositionableStream #Preferences #Process #ProtoObject  
#ProvideAnswerNotification #ProvidedSelectors #ReadStream #ReadWriteStream  
#Semaphore #SendInfo #SequenceableCollection #Set #SharedPool  
#SmalltalkImage #SortedCollection #String #Symbol #SyntaxErrorNotification  
#SystemChangeNotifier #SystemNavigation #SystemVersion #Time #TimedOut  
#ToolSet #TraitComposition #TraitCompositionException #UndefinedObject  
#UnhandledError #Utilities #WeakArray #WeakKeyToCollectionDictionary  
#WriteStream)

List of the 49 classes which have directly to do with compilation, class  
building, decompilation and context:
#(#AssignmentNode #BasicClassOrganizer #Behavior #BlockArgsNode  
#BlockClosure #BlockContext #BlockNode #BraceNode #CascadeNode  
#Categorizer #Class #ClassBuilder #ClassDescription #ClassOrganizer  
#CommentNode #CompiledMethod #CompiledMethodWithNode #Compiler  
#ContextPart #Decompiler #DecompilerConstructor #DecompilerConstructor  
#Encoder #Encoder #InstructionStream #KeyWordNode #LeafNode  
#LiteralDictionary #LiteralNode #LiteralVariableNode #MessageAsTempNode  
#MessageNode #MessagePartNode #Metaclass #MethodContext #MethodNode  
#MethodProperties #MethodTempsNode #ParseNode #ParseStack #Parser #Pragma  
#ReturnNode #Scanner #SelectorNode #SystemOrganizer #TempVariableNode  
#TileMessageNode #VariableNode)


123