Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
http://source.squeak.org/VMMaker/VMMaker.oscog-eem.886.mcz
==================== Summary ====================
Name: VMMaker.oscog-eem.886
Author: eem
Time: 25 September 2014, 3:54:29.308 pm
UUID: fb69945a-ff92-425c-9f6e-e2d9bba462ac
Ancestors: VMMaker.oscog-eem.882
Fix regression in youngReferrers management in
V3 become introduced in VMMaker.oscog-eem.882.
We /must/ priune young referrers if
mapObjectReferencesInMachineCodeForBecome
removes a cog method from youngReferrers because
it may get added back and youngReferrers cannot
contain duplicates.
Commit this separate from VMMaker.oscog-eem.885
to have it separate from the flush caches on Spur
become changes from VMMaker.oscog-eem.883/884.
To be clear, this is a branch. The head is 885.
=============== Diff against VMMaker.oscog-eem.882 ===============
Item was changed:
----- Method: Cogit>>mapObjectReferencesInMachineCodeForBecome (in category 'garbage collection') -----
mapObjectReferencesInMachineCodeForBecome
"Update all references to objects in machine code for a become.
Unlike incrementalGC or fullGC a method that does not refer to young may
refer to young as a result of the become operation. Unlike incrementalGC
or fullGC the reference from a Cog method to its methodObject *must not*
change since the two are two halves of the same object."
| cogMethod hasYoungObj hasYoungObjPtr freedPIC |
<var: #cogMethod type: #'CogMethod *'>
hasYoungObj := false.
hasYoungObjPtr := (self addressOf: hasYoungObj put: [:val| hasYoungObj := val]) asInteger.
codeModified := freedPIC := false.
self mapObjectReferencesInGeneratedRuntime.
cogMethod := self cCoerceSimple: methodZoneBase to: #'CogMethod *'.
[cogMethod < methodZone limitZony] whileTrue:
[self assert: hasYoungObj not.
cogMethod cmType ~= CMFree ifTrue:
[self assert: (self cogMethodDoesntLookKosher: cogMethod) = 0.
cogMethod selector: (objectRepresentation remapOop: cogMethod selector).
cogMethod cmType = CMClosedPIC
ifTrue:
[((objectMemory isYoung: cogMethod selector)
or: [self mapObjectReferencesInClosedPIC: cogMethod]) ifTrue:
[freedPIC := true.
methodZone freeMethod: cogMethod]]
ifFalse:
[(objectMemory isYoung: cogMethod selector) ifTrue:
[hasYoungObj := true].
cogMethod cmType = CMMethod ifTrue:
[| remappedMethod |
self assert: cogMethod objectHeader = objectMemory nullHeaderForMachineCodeMethod.
remappedMethod := objectRepresentation remapOop: cogMethod methodObject.
remappedMethod ~= cogMethod methodObject ifTrue:
[(coInterpreter methodHasCogMethod: remappedMethod) ifTrue:
[self error: 'attempt to become two cogged methods'].
(objectMemory
withoutForwardingOn: cogMethod methodObject
and: remappedMethod
with: cogMethod cmUsesPenultimateLit
sendToCogit: #method:hasSameCodeAs:checkPenultimate:) ifFalse:
[self error: 'attempt to become cogged method into different method'].
"For non-Newspeak there should ne a one-to-one mapping between bytecoded and
cog methods. For Newspeak not necessarily, but only for anonymous accessors."
"Only reset the method object's header if it is referring to this CogMethod."
(coInterpreter rawHeaderOf: cogMethod methodObject) = cogMethod asInteger
ifTrue:
[coInterpreter
rawHeaderOf: cogMethod methodObject
put: cogMethod methodHeader.
cogMethod
methodHeader: (coInterpreter rawHeaderOf: remappedMethod);
methodObject: remappedMethod.
coInterpreter
rawHeaderOf: remappedMethod
put: cogMethod asInteger]
ifFalse:
[self assert: (self noAssertMethodClassAssociationOf: cogMethod methodObject)
= objectMemory nilObject.
cogMethod
methodHeader: (coInterpreter rawHeaderOf: remappedMethod);
methodObject: remappedMethod]].
(objectMemory isYoung: cogMethod methodObject) ifTrue:
[hasYoungObj := true]].
self mapFor: cogMethod
performUntil: #remapIfObjectRef:pc:hasYoung:
arg: hasYoungObjPtr.
hasYoungObj
ifTrue:
[methodZone ensureInYoungReferrers: cogMethod.
hasYoungObj := false]
ifFalse:
[cogMethod cmRefersToYoung: false]]].
cogMethod := methodZone methodAfter: cogMethod].
+ "we /must/ prune youngReferrers here because a) the [cogMethod cmRefersToYoung: false]
+ block could have removed a method and subsequently it could be added back, and b) we
+ can not tolerate duplicates in the youngReferrers list."
+ methodZone pruneYoungReferrers.
freedPIC ifTrue:
[self unlinkSendsToFree].
codeModified ifTrue: "After updating oops in inline caches we need to flush the icache."
[processor flushICacheFrom: codeBase to: methodZone limitZony asInteger]!
Eliot Miranda uploaded a new version of BytecodeSets to project VM Maker:
http://source.squeak.org/VMMaker/BytecodeSets.spur-eem.14.mcz
==================== Summary ====================
Name: BytecodeSets.spur-eem.14
Author: eem
Time: 24 September 2014, 6:40:01.581 pm
UUID: 2a61031e-3b83-4b95-a486-b6a3ce885c90
Ancestors: BytecodeSets.spur-eem.13
FIx EncoderForSistaV1's comment defining in-line
unchecked at: primitives 2064 through 2069.
=============== Diff against BytecodeSets.spur-eem.13 ===============
Item was changed:
BytecodeEncoder subclass: #EncoderForSistaV1
(excessive size, no diff calculated)
...at http://www.mirandabanda.org/files/Cog/VM/VM.r3072.
CogVM binaries as per VMMaker.oscog-eem.876/r3072
Fix bad regression in FilePlugin>>primitiveFileSetPosition introduces around
r2797 that breaks > 1Gb file access.
Change manifest files on Windows to make app HIGHDPIAWARE. Create a
manifest for the consolevm and include it in the archive.
Fix bug with become where duplicate entries in the input
array would crash the system (thanks Igor).
Make nameOfClass: more robust, in both the real and simulated VMs.
Regenerate sources after refactoring Slang code to ask classes what methods
they want to include based on their initializationOptions inst var instead
of the centralized VMMaker.
Generate Spur Newspeak VMs with the new CompiledMethod header format. This
will
break the Newspeak Spur bootstrap until NOF generation and/or loading is
fixed.
--
best,
Eliot
Craig Latta wrote:
>Right, there's no need for anyone to use UUIDs when referring to
>classes in Smalltalk expressions.
Yes, exactly this. We still use regular names for the classes - but for the tools
they have a distinguishable ID.
Best is to use a UUID for the ID as it is unique from the beginning. So if you
create a class "Foo" and I create one both are unqique by ID - even when using
the same name.
The "rest" is implemeting tooling support. When you write "Foo" in a workspace
then the workspace either already has a naming context to resolve the name (see [1]
or could provide you with a selection if there is more than one. Internally you could
bind to the right class by using the ID.
I hate prefixing the classes as we now do, I want to name the classes "Instruction"
not "IRInstruction" in Opal or "AJInstruction" in AsmJIT, especially since "IR" and "AJ"
do not really tell you anything. Smalltalk names should be understandable. Additionally
we should have meaningfull (and also unique) names also for namespaces.
Also the current three/two letter prefixing of classes that is used in Squeak or Pharo
only scales well for small communities...
When there are things I like in Java then it is the fact to use reverse domains
for namespaces. It is easy, understandable and I could also easily check if there
is a web location.
This way a namespace "org.apache.maven" gives you something meaningful, I can even
visit http://maven.apache.org/. Allows the community to easily scale with thousands of
classes without having clashes.
Think of "org.pharo.asmjit.Instruction" vs "org.pharo.opal.Instruction"
So you additionally need better and meaningful namespaces THAT SCALE AND ARE EASY TO UNDERSTAND
combined with real packages (as objects, as Pharo already has).
Then we also need ABIA (Around, beginner, inner, after messages), multiple method
categories, selector namespaces, possibility for visibility (like private methods, see [2]),
unified annotations for classes/methods/variables and a few other ingredients from my
personal wishlist and it may shape a different new future...
The interesting part is not to add all kind of stuff to Smalltalk - the interesting
part is what is the most minimalistic system to allow for something extensible
and still flexible (even within the meta-system) so that one can bootstrap things on top.
Bye
T.
[1] http://vimeo.com/75391990
[2] http://smalltalkhub.com/#!/~CamilleTeruel/PrivateMethods
On Mon, Sep 22, 2014 at 5:10 AM, Max Leske <maxleske(a)gmail.com> wrote:
>
> On 19.09.2014, at 21:45, Eliot Miranda <eliot.miranda(a)gmail.com> wrote:
>
>
>
> On Fri, Sep 19, 2014 at 2:35 AM, Max Leske <maxleske(a)gmail.com> wrote:
>
>> I’ve written an implementation of lazily initialized expandable
>> collections (for OrderedCollection and subclasses only for now), inspired
>> by Alexandre’s talk at ESUG (
>> http://www.youtube.com/watch?v=x0YJ2dsZdKg&list=UUO-vBhaKVZf0al-ISMMPvRw).
>> The implementation is pretty much straight forward but there are a couple
>> of culprits I want to point out in case anybody else wants to do this:
>>
>> - my implementation requires an extra instance variable in
>> OrderedCollection to store the requested size. This extra instance variable
>> will break Monticello (and possibly other tools) because Monticello uses
>> OrderedCollections to load code and the particular way it uses them makes
>> it impossible to change the number of instance variables on
>> OrderedCollection. Also, all .mcz files written after the change will not
>> be loadable by images without the new instance variable (same reason).
>> - the above means that you have to modify the code in the image manually
>> and save a new “base image"
>> - read only messages should obviously not initialize the array. The
>> ‘firstIndex’ and ‘lastIndex’ variables are quite handy for that. I
>> initialize those variables to 1 and 0 respectively which makes most things
>> work already (e.g. #size, #isEmpty etc.).
>> - when trying to implement the same for HashedCollection I couldn’t. The
>> image didn’t just stop working, there was no output at all on the console,
>> not even when using a debug VM. The problem seems to be MethodDictionary,
>> at least that’s the only subclass of Dictionary for which adding an
>> instance variable doesn’t work.
>>
>
> Yes, alas the shape of MethodDIctionary is baked into the VM's method
> lookup code. It would be straight-forward to fix it, but it is still work
> and one would have to wait for people to update their VMs.
>
>
> When you say “fix”, do you mean a hard coded change of the number of
> fields in MethodDictionary or do you mean a change that would allow one to
> change the number of fields in the future? In the former case someone wiser
> than me will have to make a decision, in the latter I would promote that
> change (if it doesn’t affect performance of course).
>
The latter. It does make accessing method dictionaries on lookup slightly
slower but lookups are rare in both the interpreter and the JIT.
Max
>
> I’ll share some memory monitoring as soon as I have something significant
>> (only just rolled it out).
>>
>>
>> Big thanks to Alex for his talk and the cool work he and his students did!
>>
>> Cheers,
>> Max
>
> --
> best,
> Eliot
>
> --
best,
Eliot