gmane.comp.lang.smalltalk.squeak.vm.devel

Re: [Vm-beginners] About Primitives

Sean P. DeNigris — 2012-05-26T01:21:36

 

Mariano Martinez Peck wrote
plus self is passed implicitly first, right?


Mariano Martinez Peck wrote
How did you "browse the image" for the primitive? I ended up searching
sources for "<primitive: 249>". Is there a better/faster way?


Mariano Martinez Peck wrote
That's what it looked like to me.

--
View this message in context: http://forum.world.st/About-Primitives-tp4631848p4631889.html
Sent from the Squeak VM mailing list archive at Nabble.com.

Re: Re: OSProcess chdir

David T. Lewis — 2012-05-26T00:09:42

 
On Fri, May 25, 2012 at 04:08:49PM -0700, Sean P. DeNigris wrote:

You can send it to me and/or squeak-dev and/or vm-dev. I try to keep an
eye on pharo lists also. Eliot has developer access to the repository in
case I get run over by a truck, and I'll be happy to add you also if you
have updates to post (but realistically OSPP is very stable, the main
need for updates would be for the Windows OSPP plugin, which I have not
gotten around to writing in lo these many years).

Dave

Re: OSProcess chdir

Sean P. DeNigris — 2012-05-25T23:08:49

 

David T. Lewis wrote

Okay, great... where should the cs be sent (for next time)?

--
View this message in context: http://forum.world.st/OSProcess-chdir-tp4631844p4631880.html
Sent from the Squeak VM mailing list archive at Nabble.com.

Re: Re: [Pharo-project] VM problem?

Igor Stasenko — 2012-05-25T20:07:15

 
On 25 May 2012 20:39, Eliot Miranda <eliot.miranda< at >gmail.com> wrote:

Yes, this is reasonable. But the more cases like this we find, the
more i feel that we need better format for compiled methods, to keep
its bytecode in a separate plain bytearray, to be able to
reshape/modify the method's state and access it in convenient manner.
A bytecode could be held in a first ivar of compiled method.
Yes, we will have 4-8 more bytes per method in image (a ByteArray
instance header).. but at the same time,
we can save our brain cells as well as save bytes of implementation in
both image and vm sides:
  - no need to deduce initialPc/end pc , because it is always 1...bytearray size
  - simpler method header (no need to count method's literals)
  - no need for a method trailer crap, any additional state can be
held in own ivar.
  - we can simplify implementation
  -  free the placeholders in object format for something else, now
12..15 (4 values) is for CompiledMethod, we may need only 1.
  - i would even make an extra

Re: [Vm-beginners] About Primitives

Santiago Bragagnolo — 2012-05-25T19:08:17

 Thanks Mariano! :)

2012/5/25 Mariano Martinez Peck <marianopeck< at >gmail.com>

Re: OSProcess chdir

David T. Lewis — 2012-05-25T19:04:42

 
On Fri, May 25, 2012 at 11:33:17AM -0700, Sean P. DeNigris wrote:

Yes this is a bug.


Just a change set is usually the easiest thing, although in this case
the bug is already fixed in the sources (Damien Cassou spotted the same
thing recently).

The fixed version is OSProcessPlugin versionString 4.4.11 in
VMConstruction-Plugins-OSProcessPlugin-dtl.35.mcz on SqueakSource/OSProcessPlugin.
And Eliot picked up the fix for Cog in VMConstruction-Plugins-OSProcessPlugin.oscog-eem.35.mcz.

Thanks!
Dave

Re: [Vm-beginners] About Primitives

Mariano Martinez Peck — 2012-05-25T19:04:07

 On Fri, May 25, 2012 at 8:46 PM, Santiago Bragagnolo <
santiagobragagnolo< at >gmail.com> wrote:



yes it receieves! two arguments indeed
if you see #initializePrimitiveTable you see the number of this primitive
is 249. So if you browse your iamge, you find:

Array >> #elementsForwardIdentityTo: otherArray copyHash: copyHash
    "This primitive performs a bulk mutation, causing all pointers to the
elements of this array to be replaced by pointers to the corresponding
elements of otherArray.  The identityHashes remain with the pointers rather
than with the objects so that the objects in this array should still be
properly indexed in any existing hashed structures after the mutation."
    <primitive: 249>
    self primitiveFailed


so poping 2 means you will let "self" in the top, so it will actually be
the return value.
the last time I was hacking in this side of the moon was one year ago...so
some validation from someone else would be nice :)


The rule is that you have to always take care of balance the stack.

About Primitives

Santiago Bragagnolo — 2012-05-25T18:46:40

 Hi All

Im analyzing primtives to use them for the concrete type inference project.

Im currently working with primitiveArrayBecomeOneWayCopyHash


primitiveArrayBecomeOneWayCopyHash
      "Similar to primitiveArrayBecomeOneWay but accepts a third argument
whether to copy
      the receiver's identity hash over the argument's identity hash."

      | copyHashFlag arg rcvr |
      copyHashFlag := self booleanValueOf: (self stackTop).
      arg := self stackValue: 1.
      rcvr := self stackValue: 2.
      self success: (self become: rcvr with: arg twoWay: false copyHash:
copyHashFlag).
      successFlag ifTrue: [ self pop: 2 ].


Well, i'm seeing that pop:2, in a method which don't receive any argument.
If pop was 1, i could think in self, but is 2, so the questions are:

1) what is pop:2 in this context
2) why? there's any generalization or rules for understand the stack manage?

Thanks!

Santiago.

Re: [Pharo-project] VM problem?

Eliot Miranda — 2012-05-25T18:39:51

 On Fri, May 25, 2012 at 12:57 AM, Fabrizio Perin
<fabrizio.perin< at >gmail.com>wrote:


I changed the definition of at: for CompiledMethod to prevent it accessing
bytes outside of the bytecodes part of a compiled method.  What's happening
here is that a hash is being derived form the compiled method by looking at
the pointers part of the compiled method (i.e. bytes < aMethod initialPC).
 But it is wrong to try and derive a hash from these bytes.  Since the GC
can move objects these bytes can change as the GC moves the literals a
method references (unlike the bytes between: aMethod initialPC and: aMethod
size).

Two conclusions:

The solution is to define CompiledMethod>hash such that it does not access
bytes < initialPC.  The hash it is inheriting from ByteArray is fine for
ByteArray but not at all OK for CompiledMethod.

The VM is revealing a latent bug, i.e. that on older VMs the system could
be computing a variable hash, and hence result in not-found errors in
certain circumstances, hence the VM is right to

OSProcess chdir

Sean P. DeNigris — 2012-05-25T18:33:17

 
UnixOSProcessPlugin>>primitiveChdir
...
(self chdir: path)
ifTrue: [interpreterProxy pop: 2; push: interpreterProxy nilObject]
ifFalse: [interpreterProxy pop: 2; pushInteger: errno].

Shouldn't the conditional branches be reversed (or the test be "(self chdir:
path) == 0" - however you would write that in Slang)? chdir returns 0 on
success and -1 on error. In c, the above becomes:
if (chdir(path))
{...interpreterProxy->push(interpreterProxy->nilObject());}
else {...interpreterProxy->pushInteger(errno);}
So success takes the else branch and returns the irrelevant errno, which I
guess is why I'm getting confusing error codes in Pharo 2.0 even though the
chdir has taken effect.

b.t.w. if the above is correct, how would I submit a patch (i.e. changes to
the UnixOSProcessPlugin class)? 

Thanks,
Sean

--
View this message in context: http://forum.world.st/OSProcess-chdir-tp4631844.html
Sent from the Squeak VM mailing list archive at Nabble.com.

VM Maker: VMMaker-dtl.272.mcz

2012-05-23T00:00:00

 
David T. Lewis uploaded a new version of VMMaker to project VM Maker:
http://source.squeak.org/VMMaker/VMMaker-dtl.272.mcz

==================== Summary ====================

Name: VMMaker-dtl.272
Author: dtl
Time: 22 May 2012, 11:29:58.621 pm
UUID: 5eeb4798-b79f-4599-aa4e-eaa57e32b4a2
Ancestors: VMMaker-dtl.271

VMMaker 4.9.2

Fix slang browsing for inlined methods in ObjectMemory. The interpreter now collaborates with an object memory, so arrange for Interpreter methods that are inlined into ObjectMemory methods to be properly inlined for #asInlinedCString: code generation.

=============== Diff against VMMaker-dtl.271 ===============

Item was added:
+ ----- Method: Interpreter class>>initializeCodeGenerator: (in category 'translation') -----
+ initializeCodeGenerator: cg
+ "Load a code generator with classes in a manner suitable for generating
+ code for this class."
+ 
+ super initializeCodeGenerator: cg.
+ ^ self initializeClassicObjectMemoryInCodeGenerator: cg
+ "^ self initializeNewObjectMemor

Re: StackVM on general Unix ARM

David T. Lewis — 2012-05-22T14:48:28

 
On Tue, May 22, 2012 at 12:54:29PM +0200, Pavel Krivanek wrote:

FYI, a standard interpreter VM may work on Raspberry Pi without modification,
as it does not require a timer pthread. I don't have a Raspberry Pi to confirm
it though. The unix build is described at <http://squeakvm.org/unix/devel.html>.

Dave

Re: StackVM on general Unix ARM

Igor Stasenko — 2012-05-22T14:00:48

 
On 22 May 2012 15:42, Dmitry Golubovsky <golubovsky< at >gmail.com> wrote:

Ah, great.
Actually i could check CMakeAndroidGenerator instead of asking :)
But i didn't because i had no chance to check if it works or not.

StackVM on general Unix ARM

Dmitry Golubovsky — 2012-05-22T13:32:08

 
Hi,

Igor Stasenko wrote:



Because of Android build system (NDK) - a thing very much unto itself
;) The way they use regular Make is rather contrived; having CMake
adopted for that seemed an unnecessary trouble.

Re: StackVM on general Unix ARM

Igor Stasenko — 2012-05-22T13:03:58

 
On 22 May 2012 14:55, Dmitry Golubovsky <golubovsky< at >gmail.com> wrote:

I remember you mentioned that, but don't remember the details.
Can you please tell, why you decided to do that?

The main point why i started with cmake is to be able to generate "makefiles"
by image.
Like that we can create/reuse/mix&match configurations which is
smalltalk classes
and much easier to operate with than plain text files.

Even if you can't use cmake for building stuff, i think it is still
much better if
we could have config which produces makefile rather than just makefile.

Re: StackVM on general Unix ARM

Esteban Lorenzano — 2012-05-22T13:03:44

 
I just used sqUnixHeartbeat.c instead... in a long way, maybe Dimitri path is better :)

cheers,
Esteban

On May 22, 2012, at 2:55 PM, Dmitry Golubovsky wrote:

StackVM on general Unix ARM

Dmitry Golubovsky — 2012-05-22T12:55:23

 
Pavel,

Pavel Krivanek wrote:


By eliminating all asynchronicity from Cog and turning it into an
event-driven VM.

See this for the general discussion:

http://permalink.gmane.org/gmane.comp.lang.smalltalk.squeak.vm.devel/6910

The message referred mentions StackEvtUnixConfig which may be your
starting point.

You may follow the recommendations from

http://lists.squeakfoundation.org/pipermail/vm-dev/2012-May/010632.html

where your last (per these recommendations) step will be

sh ./generate.sh -headless StackEvtUnixConfig ### (instead of AndroidConfig)

I never polished this configuration, however it somehow ran on Linux.
I believe it is still a CMake project (as opposed to the Android build
where CMake stuff was eliminated).

You may also find this helpful:

http://lists.squeakfoundation.org/pipermail/vm-dev/2011-August/009209.html

which discusses some aspects of Morphic algorithms suitability for
event driven VMs (although some of them may have been already fixed).

Hope this helps. Feel free to ask

VM Maker: CMakeVMMaker-EstebanLorenzano.160.mcz

2012-05-22T00:00:00

 
Esteban Lorenzano uploaded a new version of CMakeVMMaker to project VM Maker:
http://source.squeak.org/VMMaker/CMakeVMMaker-EstebanLorenzano.160.mcz

==================== Summary ====================

Name: CMakeVMMaker-EstebanLorenzano.160
Author: EstebanLorenzano
Time: 22 May 2012, 2:47:17.738 pm
UUID: 37450971-39f9-4ead-86bc-e8c0522383f5
Ancestors: CMakeVMMaker-EstebanLorenzano.159

-added some flags for iphone
-added force gcc-4.2 to mac builds

=============== Diff against CMakeVMMaker-EstebanLorenzano.159 ===============

Item was changed:
  ----- Method: CogFamilyCocoaIOSConfig>>setExtraTargetProperties: (in category 'settings') -----
  setExtraTargetProperties: maker
  | plist |
  
  maker addFrameworks: self frameworks.
  
  " generated and add Info.plist file "
  plist := self plistFile.
  
  (maker buildDir forceNewFileNamed: 'Info.plist') 
  nextPutAll: plist; 
  close.
  
  maker 
  addProperty: 'MACOSX_BUNDLE_INFO_PLIST' 
  value: '${buildDir}/Info.plist'.  
  
  (maker buildDi

StackVM on general Unix ARM

Pavel Krivanek — 2012-05-22T10:54:29

 Hi,

I'm trying to compile StackVM for Raspberry Pi but I face some problems.
The biggest one seems to be the absence of High Res Timer Ticker. CogDroid
and iOS builds are for ARM too. How did you solve this?

Cheers,

Re: Linux 4.4.7.2357 VM crash under memory pressure

Bert Freudenberg — 2012-05-21T09:14:39

 

On 21.05.2012, at 04:32, David T. Lewis wrote:


Reportedly Pharo 1.3 works fine. Only Pharo 1.4 has been seen crashing so far:

http://lists.sugarlabs.org/archive/sugar-devel/2012-May/037490.html

And I just tried Squeak 4.3. No problem.

- Bert -

Re: Linux 4.4.7.2357 VM crash under memory pressure

David T. Lewis — 2012-05-21T02:32:04

 
On Sun, May 20, 2012 at 08:55:18PM +0200, Bert Freudenberg wrote:

I don't see any obvious reason why the small memory would make a difference
either. I'm really just trying to think of things that might be different in
this case. The failure seems to be happening in GC code that has not changed
in recent years, but it's happening after calling a method that depends on
object header format (#lastPointerWhileForwarding:), and it is happening in
code the iterates over the fields of an object. Beyond that I'm just totally
guessing.

Dumb question - do you know if any other closure-enabled images have this
problem on small memory systems? I'd have thought someone would have noticed
by now, but maybe not.

Dave