Vm-dev May 2011

vm-dev@lists.squeakfoundation.org

36 participants
89 discussions

Re: [Pharo-project] compiled VM with Alien for JNIPort
by Mariano Martinez Peck 12 May '11

12 May '11

No idea. Maybe cc'ing vm list may help. On Tue, May 10, 2011 at 10:27 PM, laurent laffont <laurent.laffont(a)gmail.com > wrote: > So following Mariano's blog and pharocasts I've built Cog with > IA32ABIPlugin (works, cool !) > > When starting the JVM following JNIPort instructions on SqueakSource wiki, > the VM crashes. > > GDB bt gives: > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 > 0x00000000 in ?? () > (gdb) bt > #0 0x00000000 in ?? () > #1 0x000d267a in primCallOutIntegralReturn () at > /Users/laurentlaffont/dev/pharo/vm/blessed/src/plugins/IA32ABI/IA32ABI.c:500 > #2 0x00023a3e in interpret () at > /Users/laurentlaffont/dev/pharo/vm/blessed/src/vm/gcc3x-cointerpmt.c:2037 > #3 0x962ede02 in __CFRunLoopDoObservers () > #4 0x962a9d8d in __CFRunLoopRun () > #5 0x962a9464 in CFRunLoopRunSpecific () > #6 0x962a9291 in CFRunLoopRunInMode () > #7 0x934dce04 in RunCurrentEventLoopInMode () > #8 0x934dcaf5 in ReceiveNextEventCommon () > #9 0x934dca3e in BlockUntilNextEventMatchingListInMode () > #10 0x9644778d in _DPSNextEvent () > #11 0x96446fce in -[NSApplication > nextEventMatchingMask:untilDate:inMode:dequeue:] () > #12 0x96409247 in -[NSApplication run] () > #13 0x964012d9 in NSApplicationMain () > #14 0x00078247 in main (argc=1, argv=0xbffff680, envp=0xbffff688) at > /Users/laurentlaffont/dev/pharo/vm/blessed/platforms/iOS/vm/Common/main.m:52 > (gdb) > > Any idea ? > > Laurent. > > > On Tue, May 10, 2011 at 12:37 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> >> >> On Mon, May 9, 2011 at 1:01 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> On 9 May 2011 21:23, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> > >>> > >>> > On Mon, May 9, 2011 at 11:27 AM, laurent laffont < >>> laurent.laffont(a)gmail.com> >>> > wrote: >>> >> >>> >> On Mon, May 9, 2011 at 4:02 PM, laurent laffont >>> >> <laurent.laffont(a)gmail.com> wrote: >>> >>> >>> >>> Hi, >>> >>> >>> >>> is there a compiled VM available with Alien for OSX ? I want to use >>> >>> JNIPort. >>> >> >>> >> >>> >> Second question, if I need to compile the VM, which one should I use >>> for >>> >> Alien ? Cog is OK ? >>> > >>> > Yes. Cog is OK. >>> >>> And what plugin? NewsqueakIA32ABIPlugin, right? >>> >> >> No, just IA32ABIPlugin. The difference between the two is only >> that NewsqueakIA32ABIPlugin implements immutability checks. >> >> >>> >>> > >>> >> >>> >> Laurent >>> > >>> > >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> >> > -- Mariano http://marianopeck.wordpress.com

1 0

debuggable win32 VM?
by Craig Latta 11 May '11

11 May '11

Hi-- For the next Spoon release I want debuggable VMs and plugins on all platforms. In 2007 for win32 I created a Microsoft Visual C "solution" for use with the free MSVC Express Edition (2008 or later). The debugger is decent. I scanned the current CMake-based stuff, but didn't see anything about MSVC (or win32 gdb for that matter). Is there a current route for debugging the win32 VM using MSVC or gdb (or anything more pleasant than printf)? Or should I update my MSVC stuff and contribute it somewhere? In 2007 I only gave it to Andreas (the win32 VM maintainer) and a few other folks who asked for it. thanks! -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547

6 10

Cog doesn't load anymore in PharoCore1.3 because of the removal of AbstractLauncher
by Mariano Martinez Peck 10 May '11

10 May '11

AbstractLauncher was removed in: http://code.google.com/p/pharo/issues/detail?id=4002 Cog has a subclass from AbstractLauncher called CommandLineLauncher, hence, it cannot be loaded anymore CommandLineLauncher has no class comment and no sender. So I have no idea what it does, nor if it can be removed from cog, nor how to solve this problem in Pharo. Cheers -- Mariano http://marianopeck.wordpress.com

3 4

VM Maker: CMakeVMMaker-IgorStasenko.104.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 10 May '11

10 May '11

Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-IgorStasenko.104.mcz ==================== Summary ==================== Name: CMakeVMMaker-IgorStasenko.104 Author: IgorStasenko Time: 10 May 2011, 2:14:47 pm UUID: 1e9b1b72-2342-45e7-8da3-13fbf904d043 Ancestors: CMakeVMMaker-IgorStasenko.103 - leaved only single configuration type, seen by cmake, named 'release' - added #generateVMOnlySources method to generate sources for VM classes only, without plugins. Useful for VM hackers to refresh source code of VM. Can be used like this: MyConfig new generateVMOnlySources

1 0

VM Maker: VMMaker-dtl.232.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 10 May '11

10 May '11

Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-dtl.232.mcz ==================== Summary ==================== Name: VMMaker-dtl.232 Author: dtl Time: 9 May 2011, 7:56:36 am UUID: 08000000-1508-d80c-1508-d80c14000000 Ancestors: VMMaker-dtl.231 VMMaker 4.4.19 Previous moves of class variables from ObjectMemory and and Interpreter into shared pools (as per oscog) requires a recompile, otherwise simulator does not work. Add VMConstantsTest to document the issue and put the recompile into VMConstantsTest class>>initialize such that an update from the configuration map will do the recompile. Implement methods in FilePluginSimulator to allow #primitiveFileStdioHandles to run in simulator. Add the inSmalltalk clauses to allow #signed64BitIntegerFor: and #signed64BitValueOf: to run in simulator. Increase byteCount max in #primitiveResume and #primitiveSuspend to allow larger images to run in simulator.

1 0

.. and evolving object format(s) (Was: Re: [Vm-dev] #becomeUncompact not longer works in Cog/Stack VMs)
by Igor Stasenko 09 May '11

09 May '11

On 8 May 2011 10:32, Andreas Raab <andreas.raab(a)gmx.de> wrote: > > On 5/7/2011 22:30, Igor Stasenko wrote: >> >> On 7 May 2011 16:15, Andreas Raab<andreas.raab(a)gmx.de> wrote: >>> >>> On 5/7/2011 9:25, Tobias Pape wrote: >>>>> >>>>> No. It does /not/ need to be fixed. As I said earlier it is *absurd* >>>>> to >>>>> throw away performance for the ability to change certain classes to >>>>> become >>>>> uncompact. >>>> >>>> When it worked in pre-cog VMs, why should it break in Cog? >>> >>> Because Cog is all about performance. And there's a big performance >>> difference for some classes when they are changed to be non-compact and >>> Eliot didn't want to add the complexity it would take to support both a >>> fast >>> compact, and a slow non-compact version of the code. >> >> Where is the metrics? >> I need to know what we lose if we do it one or another way. >> >> And since Cog don't allows me to turn compact class back to be normal >> class (simply crashing), i cannot measure it. > > Then write the code yourself. Why does Eliot have to do that? His metrics is > pretty simple, a comparison of the speed of the interpreter with the JIT. > The results (as you know) are impressive, but you can't realistically expect > Eliot to do the work for something he considers directly detrimental to the > goals of Cog. If you suspect that there's no difference, it's up to you to > prove that, not up to Eliot to disprove you. And unless you can show > differently, his claim stands unabated. > No problem. Of course i could write necessary code. I just expected it will be less work, if Cog would not nail down compactness. I understand the design decision and since future object format (tm) will unify this anyways, there's not much to worry about. >>> Therefore, some classes >>> cannot be made non-compact in Cog, and that is a perfectly good tradeoff. >> >> In theory. But you have no proof now. >> Why i should trust you/Eliot/anyone else, without being able to test it? > > You don't. But why must Eliot jump every time you have a hunch that > something can be done differently? Adding unneeded generality to a JIT just > to disprove your hunches is an amazingly pointless waste of time for him. > Unless you are intending to pay him for it, of course. Oh, you weren't... > I wouldn't say that its adding generality, i would call it 'inheriting' generality. I would like to squeeze some time to experiment with it and free those 5 bits for something else. One of applications, if you remember, i had an idea to be able to attach a variable number or key/value pair slots to objects. So, objects in addition to general layout could carry additional state, like bigger storage for identity hash value. A most interesting application for those dynamically added slots is Magma: - it could attach an unique ID per each object to identify them, instead of maintaining huge and ineffective id<->object dictionaries. But this scheme heavily depends on fast become. If you remember we had a discussion before, where i proposed to introduce a lazy become, i.e. object is marked as forwarded by setting a certain bit(s) in header, and points to its newer version. It will stay in such forms until GC will replace all references to old object with a new one. There of course many ways how to use extra bits freed in header: how about supporting multiple/segregated memory regions for heap? Eliot wants a non-movable memory region for FFI. And also, we could use a separate memory region for immutable objects. > Cheers, > - Andreas -- Best regards, Igor Stasenko AKA sig.

3 3

Immutability through hardware
by Igor Stasenko 09 May '11

09 May '11

Just a follow-up to recent thread. Suppose that we have new object format which supports multiple memory regions. I.e. eden space old space pinned space ... and immutable space so, instead of adding a flag per object whether its immutable or not, and then check this flag every time there is a write attempt, we could simply let hardware handle this. And immutable space is a memory region with read-only access, So once placed & sealed , any attempt to write, we lead to a hardware exception, which can be nicely handled :) So, we will have a single entry point for all write access , and don't need to spread an immutability logic all over the places. And of course hardware 'check if memory is writeable' is much faster than software one. What you think? -- Best regards, Igor Stasenko AKA sig.

5 5

#becomeUncompact not longer works in Cog/Stack VMs
by Igor Stasenko 09 May '11

09 May '11

Hi, i tried to do a simple: Smalltalk compactClassesArray do: [:each | each ifNotNil: [each becomeUncompact]] and it crashing the image. I tried to do this for individual classes. CompiledMethod, ByteString, BlockClosure, BlockContext , seems working ok. MethodContext, LargePositiveInteger, LargeNegativeInteger, Float crashes the image. i also tried following: [Smalltalk compactClassesArray do: [:each | each ifNotNil: [each becomeUncompact]] ] forkAt: Processor highestPriority but it didn't helped much. Also, i saved image after couple successfull #becomeUncompact steps.. and now VM cannot open image, most probably because it fails on 'assumptions check' defined in #checkAssumedCompactClasses -- Best regards, Igor Stasenko AKA sig.

10 34

Cannot abandon sources with CogVM
by Mariano Martinez Peck 09 May '11

09 May '11

Hi. If I take any PharoCore 1.3 image and evaluate: Smalltalk abandonSources I have two errors and the image is frozen. I cannot interrupt it and I have to force a quite. Two erros pops up: the first one says "computation has been terminated" and the second one is a stacktrace which message: "UndefinedObject(Object)>>doesNotUnderstand: #findNextHandlerContextStarting" This seems similar to the problem we have with the DebuggerMethodMap trying to build a dev image: http://code.google.com/p/pharo/issues/detail?id=4087 At least this time it is easier to reproduce ;) I attach PharoDebug.log. With the Interpreter VM it works correctly. Thanks -- Mariano http://marianopeck.wordpress.com

1 1

4.0.3.2196 for Unix
by Ian Piumarta 08 May '11

08 May '11

Folks, Source and binaries for Linux/i386, Darwin/i386 & Darwin/PPC now available. (Solaris, NetBSD and FreeBSD still at 3.11.3 until I get my kvm working again.) http://squeakvm.org/unix Enjoy! Ian Major changes since 3.11.3.2135: Generated sources rebuilt from VMMaker-dtl.169. Re-enabled MIDI support via ALSA on Linux. Broken locales should no longer cause line ends to go missing during copy and paste. Add support for "platform source version" primitive. Remove debugging beep on first clipboard copy under X11. Allow fully-qualified pathnames when loading modules. Bundle FreetypePlugin with source and binary releases. Various fixes for 64-bit cleanliness (many thanks to Dave Lewis). Add microsecond clock support. Fix launching from a menu under KDE. Fix --CFLAGS option in configure script. Serial plugin invalidates cached port names on close. Better handling of symlinks when looking for absolute path to VM binary.

5 12

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev May 2011