New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

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

New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

Eliot Miranda-2
Hi All,

    first of all, apologies for the long wait for new VMs.  I know there are bugs that these VMs address and that it's been 5 months since VMs were last made is something I regret.  The wait was due to my developing the 64-bit Spur Cog JIT VM which required surgery not just to the Cogit but also to Slang.  I beg your forgiveness.

   Secondly, the Mac VMs are much changed, using John McIntosh's Cocoa support libraries.  The old Carbon UI VMs are history.  That means that Cog supports building on contemporary Mac OS releases.  These VMs were built on 10.9; I like the 3D look much more than the 10.10 one ;-).  The VMs are also signed, so installing them should be easier.

  Thirdly, these VMs include 64-bit JIT support.  There is an updated squeak trunk image at http://www.mirandabanda.org/files/Cog/SpurImages for you to try.  As yet the 64-bit Vms do not include an FFI plugin.  I hope to rectify this soon.

   Finally I have included Pharo Mac VMs, not to displace the official Pharo VMs, but to test my build process.  I hope that in very few months the svn repository will be moed to githup and that Esteban and I will build official VMs from the same repository.




CogVM binaries as per VMMaker.oscog-eem.1679/r3602

Include 64-bit Spur VMs for Mac OS X x64 and Linux x64. N.B. As yet these VMs
lack FFI support.

Move all Mac OS X VMs to the Cocoa libraries.  Minimum supported version should
be 10.6.x.  The Mac OS X VMs are signed and so should install properly without
having to disable the launch security checks.


Bug Fixes and Improvements:

General:
Add vmParameter 20 to answer the utc microseconds at startup.


CoInterpreter:
Remove the atCache from the CoInterpreter.  It's of little benefit given the
Cogit.

ceSend: et al need to add looked up methods to the method cache, otherwise
methods only found through machine code sends will not be jitted.

Fix slip in maybeSelectorOfMethod: which will improve back traces
including methods containing pragmas (including primitives).

Modify secret primtiive 161, primitiveSetIdentityHash so that with 0 args it
answers whether an object has an identity hash.  This is vacuously true for V3,
but is meaningful in Spur.


Cogit:
Fix /horrible/ bug with primitive error codes and fixups.  The adjustment of the
initialPC to skip the primitive and error code, if any, was done after
generating fixups for backward branches, and hence these branches were bogus.
Object>>shallowCopy in Spur is subject to this, but amazingly enough it has not
surfaced before now.  Fix this by adjusting the initialPC before scanMethod
scans for fixups.

Fix bug in Spur machine-code at:put: on 32-bit bits objects; method failed to
fail for negative values.

Fill unused portions of methods with the stop instruction, not nop.

Explicitly initialize the code zone with stops. Explicitly clear the
reclaimed portion of the method zone after a compaction.

Include the reclaimed portion of the method zone in the I-cache flush
after a compaction: no point in leaving it in cache since it isn't a
valid call/jump target.


Spur:
Maintain the survivor count on scavenge.

Fix start up of images containing >= 16 segments.  The old code assumed
numSegments < 16 and failed to grow the segment records, resulting in objects
in segments greater than 15 to not be swizzled, and a resulting crash.

Spur Cogit: Support CompiledMethod indexing in genPrimitiveAt[Put].  Hence fix
the regression in at:[put:] whereby in Spur one could access the literals part
of a method as bytes.
Add a machine-code primitive for objectAt: to provide fast literal and header
access on Spur.

Add 16-bit indexability to Spur.  Generate slimmer code for
positive32BitValueOf: on 64-bit Spur.

Fix a bug with out-of-place two-way become, which got the hash copy the wrong
way round.  By default, the hash stays with the reference in two-way become.

Fix what appears to be a compiler bug with in-place two-way-become by treating
the headers to be swapped so that remembered flags are swapped and hash bits
are swapped if required. This fixes a bug with in-place two-way become of
objects that are the same size on the heap.  One object's contents would not
be updated correctly.

Implement ephemeron queue primitive.  Add an image flag that controls the
finalization support (StackInterpreter instVar newFinalization).  If unset,
finalization is as currently expected; WeakArray finalizes all WeakArrays in
its registries on each finalization (which does not scale!).  If set, then both
fired ephemerons and bereaved weak arrays are added to the finalization queue
and the finalization semaphore is signalled.  In this regime the image is
expected to send mourn to each element of the queue, and weak arrays will send
themselves finalize in mourn, side-stepping the finalizeValues steps and
rendering WeakArray's FinalizationDependents and WeakRegistry obsolete.
The bit is set via
    Smalltalk vmParameterAt: 48
              put: ((Smalltalk vmParameterAt: 48) bitOr: 64).


Slang:
Fix bad regression in type inference from VMMaker.oscog-eem.1587.
returnTypeForSend:in: can only default return types to sqInt for unknown
selectors.  The rewrite in VMMaker.oscog-eem.1587 inadvertently defaulted the
return type of known methods whose return type was yet to be determined to
sqInt.  The fix is to only default to sqInt if there is no known method for the
given selector.  This fixes, for instance, the weird flipping of the type of
32-bit Spur's headerWhileForwardingOf:,which should always be #sqLong.

Fix bad bug in type inferrence.  Avoid computing variable and return types
prematurely i.e. don't derive types from as-yet-untyped methods.

Fix baaaad bug in node:typeCompatibleWith:inliningInto:in: which was looking
up the type of the formal parameter in inlining in the target method, not the
method being inlined!


Newspeak:
Fix bug in MNU for cogged dynamic super sends - should start looking for
#doesNotUnderstand: in the superclass not the receiver class. Unify MNU
lookup between absent and present receiver sends as a result.

Further fix outer send MNU by not confusing lkupClass and lkupClassTag.
Push setting lkupClassTag down to clarify it is for new cache entries.


Plugins:
Fix the FilePlugin's unnecessary fullGC on Spur.
Include the file sync prim in the FilePrims plugin.

ThreadedFFIPlugin:
- ExternalAddress now are taken correctly (nor as ByteArray or Alien, because
  they are different beasts).  
- allow pushing of pointers to any type (into a ByteArray, an ExternalAddress
  or an Alien), to allow passing parameters style int*, float*, etc.
- allow reading in memory to allow read chunks of ByteArray

Added ThreadedFFIPlugin>>#primitiveLoadSymbolFromModule (copy and adapt from
IA32ABIPlugin).

Fix coercion problems on FFI plugin (IA32 & ARM)
- character were not correctly mapped back
- floats were not being well checked
- external addressed needs to be treated as aliens for the purpose of coercing
  them as pointers (bad regression by Eliot)

Alien Plugins:
Fix missing primitive failure for Alien typeAt: 0 [put:].
Add word accessors to Alien.

_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: [Vm-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

Eliot Miranda-2


On Mon, Feb 15, 2016 at 3:52 PM, Levente Uzonyi <[hidden email]> wrote:
Hi Eliot,

This is great. I couldn't find any 64-bit VMs for non-MacOS. Are they Mac only?

Oops.  Bugs in my upload scripts.  Adding the 64-bit linux VMs now.

Tobias, Marcel we should discuss building on WIN32 and WIN64, and how to build a 64-bit Spur Windows VM.

_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

Sean P. DeNigris
Administrator
In reply to this post by Eliot Miranda-2
Eliot Miranda-2 wrote
... Bug Fixes and Improvements...
Wow that was a long list of improvements, and exciting that 64-bit and one unified build process are so near! Thanks and congrats!!
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

Clément Béra
Hey Eliot,

the Pharo builds you have integrated, they have the exact same plugin as existing Pharo VM ? I am thinking of libgit, Cairo or SDL2 for example.

I am so happy to be able to build Pharo VM now. That would simplify so many things for me.

2016-02-16 3:32 GMT+01:00 Sean P. DeNigris <[hidden email]>:
Eliot Miranda-2 wrote
> ... Bug Fixes and Improvements...

Wow that was a long list of improvements, and exciting that 64-bit and one
unified build process are so near! Thanks and congrats!!



-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/New-Cog-VMs-available-as-per-VMMaker-oscog-eem-1679-r3602-tp4877685p4877734.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.


Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

Sven Van Caekenberghe-2
In reply to this post by Sean P. DeNigris

> On 16 Feb 2016, at 03:32, Sean P. DeNigris <[hidden email]> wrote:
>
> Eliot Miranda-2 wrote
>> ... Bug Fixes and Improvements...
>
> Wow that was a long list of improvements, and exciting that 64-bit and one
> unified build process are so near! Thanks and congrats!!

+100 Yeah!

> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/New-Cog-VMs-available-as-per-VMMaker-oscog-eem-1679-r3602-tp4877685p4877734.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

Eliot Miranda-2
In reply to this post by Clément Béra
Hi Clément,

On Feb 15, 2016, at 10:28 PM, Clément Bera <[hidden email]> wrote:

Hey Eliot,

the Pharo builds you have integrated, they have the exact same plugin as existing Pharo VM ? I am thinking of libgit, Cairo or SDL2 for example.

No, but I hope that people who know the Pharo VM can modify the build to make it the same.

Another thing that needs to be done is to merge in HPI's statically-linked SqueakSSL plugin build.


I am so happy to be able to build Pharo VM now. That would simplify so many things for me.

That's great!  I'm sure that in a month or two we will all be sharing a consistent VM build environment.  That'll make everyone's life easier.



2016-02-16 3:32 GMT+01:00 Sean P. DeNigris <[hidden email]>:
Eliot Miranda-2 wrote
> ... Bug Fixes and Improvements...

Wow that was a long list of improvements, and exciting that 64-bit and one
unified build process are so near! Thanks and congrats!!



-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/New-Cog-VMs-available-as-per-VMMaker-oscog-eem-1679-r3602-tp4877685p4877734.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.