[Vm-dev] SqueakCogSpur32x86.xcworkspace

johnmci at smalltalkconsulting.com johnmci at smalltalkconsulting.com
Mon Sep 28 02:19:01 UTC 2015



Sent from my iPhone

> On Sep 27, 2015, at 6:51 PM, Ben Coman <btc at openinworld.com> wrote:
> 
> 
> On Mon, Sep 28, 2015 at 3:25 AM, John McIntosh
> <johnmci at smalltalkconsulting.com> wrote:
>> 
>> Yes, I have to go back and re-introduce something that lets us build a non-arc version for 32bit, and a arc aware version for os-x 64bit, an iOS 32/64bit
> 
> This is the first I heard of ARC, so I've read a bit and now I'm just
> curious about a few things mentioned at [1].
> 
> Will you have one vm "platform" with #ifdefs for different ARC &
> non-ARC code paths, or is it better to treat ARC and non-ARC code as
> two separate platforms?  It seems part of the arc advantage of concise
> code is negated by additional #ifdefs.  This is maybe suggested by [1]
> (but I don't know if "separate xcodeproj" implies a "separate
> platform" for us)

Only a few percentages of the code base require something to deal with arc/non-arc so there will only be one source file, not two 


> 
> ARC seems ObjC based? Is the os-x vm code written in ObjC rather than C?

The OS X VM code is mostly all objective-c with some C code, for example the sound plugin is objective-c, but for sockets we just use the UNIX C code 

> 
> Does the vm code use Core Foundation much?  [1] implies there are
> added complications.

There is a bit of that, and yes you have be careful, less so for non-arc 

> 
> Does the vm code do math on pointers?  [1] implies there are added
> complications.

No we don't do that 

> 
> With the ARC-vm code doing reference counted garbage collection, does
> this encompass the memory the vm allocates to objects inside the
> Image?  Can we forgo our traditional scanning garbage collection?  Or
> do you opt out of ARC for the code that hands memory to the Image so
> there are not two layers of garbage collection?

The Squeak VM is an implementation that requires a hosting environment that supports various services which are mostly documented at https://isqueak.org/PlatformVMAPI

You can compile the VM code then start adding the various C calls that turn up as unimplemented.

When we start up the VM with a targeted image, the image header/meta data is read, the amount of memory needed to run the image is allocated, then the image file is read or mapped into that memory space and the VM code is called to swizzle pointers, fix endian changes and the like.  Then VM state data is loaded and the VM continues from the execution point of the saved snapshot. 

Squeak objects aren't managed by the operating system memory management excluding specific mallocs needed for direct API calls for FFI for example.  

> 
> Someone's comment [1] from 2012 "There is one serious downside that
> wasn't mentioned: cross-compatibility. For us brave and foolish souls
> that face the wastelands known as cross-platform programming, ARC
> simply isn't an option, at least not until GNU expand upon their ObjC
> runtime and compiler features again (they say more is on the way)."
> Is this now covered in gcc?  Or is different complier used?
> 

GCC is dead, long live LLVM


> 
> [1] http://stackoverflow.com/questions/8760431/to-arc-or-not-to-arc-what-are-the-pros-and-cons
> 
> cheers -ben
> 
> 
>> 
>>> On Sun, Sep 27, 2015 at 1:19 AM, Colin Putney <colin at wiresong.com> wrote:
>>> 
>>> 
>>> 
>>> 
>>>> On Sun, Sep 27, 2015 at 1:02 AM, <johnmci at smalltalkconsulting.com> wrote:
>>>> 
>>>> 
>>>> 99.5% is the code I wrote a number of years back. Earlier this year I took the Pharo code, code from minor squeak updates and code from Pyonkee to consolidate and convert into an ARC aware base.  This makes iOS and 64bit OS X base happy, the legacy  32bit obj-c kernel not so much.
>>>> 
>>>> Now I have to backport the code to a format that works in both environments.
>>> 
>>> 
>>> IIUC, that means the Pharo VM is *not* ARC-aware, which is why it doesn't leak memory. What you've posted now is a step forward from all that, but not yet complete. Is that right?
>>> 
>>> -Colin
>> 
>> 
>> 
>> --
>> ===========================================================================
>> John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
>> ===========================================================================
>> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2647 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150927/b4471574/smime.bin


More information about the Vm-dev mailing list