Vm-dev April 2018

vm-dev@lists.squeakfoundation.org

43 participants
235 discussions

[cfp] COP 2018
by Fabio Niephaus 23 Apr '18

23 Apr '18

*** COP 2018: 10th International Workshop on Context-Oriented Programming *** July 16th, 2018 Co-located with ECOOP/ISSTA 2018 in Amsterdam, Netherlands === Advanced Modularity for Run-time Composition === Contextual information is playing an ever-increasing role in our information-centric world. Current-day software systems need to adapt continuously to changing execution and usage contexts, even while they are running. Unfortunately, mainstream programming languages and development environments still do not support this level of dynamic adaptivity very well, leading developers to implement complex designs to anticipate various dimensions of variability. Context-Oriented Programming directly supports variability at the programming level, featuring dedicated programming abstractions enabling programmers to write software applications that adapt dynamically to a wide range of dynamic attributes. It enables run-time behaviour to be dispatched directly on any detected properties of the execution or user context. Since more than a decade, several researchers have been working on a variety of notions approaching that idea. Implementations ranging from first prototypes to mature platform extensions used in commercial deployments have illustrated how multidimensional dispatch can be supported effectively to achieve expressive run-time variation in behavior. Our series of International Workshops on Context-Oriented Programming (COP) at ECOOP since 2009 have shown to be well-received, each attracting around 30 participants. Also in 2018 we hope to advance this vibrant research domain at ECOOP in the beautiful and lively city of Amsterdam. === Topics === Topics of interest to the workshop include, but are not limited to: - Interesting application domains and scenarios for COP - Programming language abstractions for COP (e.g. dynamic scoping, roles, traits, prototype-based extensions) - Implementation techniques and mechanisms for COP (e.g. different kinds of dynamic, contextual, and multi-dimensional dispatch or pre-dispatch) - Implementation issues for COP such as optimization, VM support, JIT compilation etc. - Implemented use-cases, case studies, or prototypes of COP - Theoretical foundations for COP (e.g., semantics, type systems) - Configuration languages (e.g. feature description interpreters, transformational approaches) - Interaction between non-functional programming concerns and COP (e.g. security, persistence, concurrency, distribution) - Modularization approaches for COP (e.g. modules, aspects, features, layers, plugins) - Guidelines to apply COP (e.g. best practices, idioms, patterns) - Run-time support for COP (e.g. reflection, dynamic binding) - Tool support (e.g. design tools, IDEs, debuggers) - Support for COP at the modeling level - Beyond context-oriented behavior adaptation (e.g., UI adaptation, DB adaptation). === Submission guidelines === COP invites submissions of high-quality papers reporting original research, or describing innovative contributions to, or experience with context-oriented programming, its implementation, and application. Papers that depart significantly from established ideas and practices are particularly welcome. Submissions must not have been published previously and must not be under review for any other refereed event or publication. The program committee will evaluate each contributed paper based on its relevance, significance, clarity, and originality. Papers are to be submitted via EasyChair (https://easychair.org/conferences/?conf=cop2018). They must be written in English, provided as PDF documents, and follow the new ACM Master Article Template with the sigconf option (https://www.acm.org/publications/proceedings-template). They should not exceed 8 pages. Accepted papers will be published in the ACM Digital Library. === Important dates === Submission deadline: May 18th, 2018 (AoE) Notifications: June 8th, 2018 Final version: June 29th, 2018 === Program committee === Tomoyuki Aotani, Tokyo Institute of Technology, Japan Nicolás Cardozo, Universidad de los Andes, Colombia Coen De Roover, Vrije Universiteit Brussel, Belgium Elisa Gonzalez Boix, Vrije Universiteit Brussel, Belgium David H. Lorenz, Technion IIT, Israel Gorel Hedin, Lund University, Sweden Stefan Marr, University of Kent, UK Kim Mens, Université Catholique de Louvain, Belgium Stefan Ramson, Hasso Plattner Institute, Germany Guido Salvaneschi, TU Darmstadt, Germany Matthias Springer, Tokyo Institute of Technology, Japan Mario Südholt, IMT Atlantique, France Naoyasu Ubayashi, Kyushu University, Japan Didier Verna, EPITA / LRDE, France Harumi Watanabe, Tokai University, Japan Tijs van der Storm, CWI, Netherlands === Organizing committee === Robert Hirschfeld, HPI, Germany Atsushi Igarashi, Kyoto University, Japan Tetsuo Kamina, Ritsumeikan University, Japan Jens Lincke, Hasso Plattner Institute, Germany Hidehiko Masuhara, Tokyo Institute of Technology, Japan

1 0

Primitives, interpreterProxy, function calls, lto
by Levente Uzonyi 20 Apr '18

20 Apr '18

Hi All, I'm in the progress of rewriting the primitives of MiscPrimitivePlugin (mostly done, I'm stuck with the tests). My main goal was to add the necessary checks to make these primitives safer. But while I was doing that, I decided to optimize the code a bit by getting rid of a few repeated function calls, notably stackValue() calls, because those are pretty much the only ones that are called more than once with the same argument from these primitives. This kind of rewrite resulted in small, but measurable speedup (~5-15%), despite of the new checks being in place. Unfortunately, the generated assembly code for almost all interpeterProxy methods will be a function call (callq). IMHO the best solution would be if these calls were just macros, so that the compiler could optimize them away, but I don't know how to achieve that. So, I decided to check if the C compiler could do that for us,m and yes, gcc starting from 4.5 supports link time optimization (lto)[1]. The results are promising, performance is better, but it still won't optimize everything it could[2]. I wrote a small benchmark to see how lto and my rewrite affects the overhead of primitive calls: | string collation | string := ''. collation := (0 to: 255) asByteArray. [ 1 to: 10000000 do: [ :i | ByteString compare: string with: string collated: collation ] ] timeToRun. The results on my machine were; original: 16 function calls - 795 ms rewrite-no lto: 13 function calls - 762 ms rewrite-with lto: 10 function calls - 674 ms So, for now, I suggest we try to add -flto to CFLAGS and LDFLAGS when compiling with gcc 4.5+ to see how stable it is. Also, I would be happy if someone could point me to the direction to generate macros and use them instead of the function calls for interpeterProxy functions. Levente [1] https://gcc.gnu.org/wiki/LinkTimeOptimization [2] Generated assembly code for comparison Without lto: 00000000004ed310 <primitiveCompareString>: 4ed310: 41 55 push %r13 4ed312: 31 ff xor %edi,%edi 4ed314: 41 54 push %r12 4ed316: 55 push %rbp 4ed317: 53 push %rbx 4ed318: 48 83 ec 08 sub $0x8,%rsp 4ed31c: e8 2f 19 f8 ff callq 46ec50 <stackValue> 4ed321: bf 01 00 00 00 mov $0x1,%edi 4ed326: 48 89 c3 mov %rax,%rbx 4ed329: e8 22 19 f8 ff callq 46ec50 <stackValue> 4ed32e: bf 02 00 00 00 mov $0x2,%edi 4ed333: 48 89 c5 mov %rax,%rbp 4ed336: e8 15 19 f8 ff callq 46ec50 <stackValue> 4ed33b: 48 89 df mov %rbx,%rdi 4ed33e: 49 89 c4 mov %rax,%r12 4ed341: e8 4a d4 f3 ff callq 42a790 <isBytes> 4ed346: 48 85 c0 test %rax,%rax 4ed349: 74 0d je 4ed358 <primitiveCompareString+0x48> ... With lto: 00000000004fe4f0 <primitiveCompareString.35928>: 4fe4f0: 41 55 push %r13 4fe4f2: 41 54 push %r12 4fe4f4: 55 push %rbp 4fe4f5: 53 push %rbx 4fe4f6: 48 83 ec 08 sub $0x8,%rsp 4fe4fa: 48 8b 05 77 6b 32 00 mov 0x326b77(%rip),%rax # 825078 <stackPointer.7294> 4fe501: 48 8b 18 mov (%rax),%rbx 4fe504: 48 8b 68 08 mov 0x8(%rax),%rbp 4fe508: 4c 8b 60 10 mov 0x10(%rax),%r12 4fe50c: 48 89 df mov %rbx,%rdi 4fe50f: e8 bc fe fb ff callq 4be3d0 <isBytes> 4fe514: 48 85 c0 test %rax,%rax 4fe517: 74 0d je 4fe526 <primitiveCompareString.35928+0x36> ... So, gcc could optimize away the three stackvalue calls with 4 mov instructions, but failed to inline isBytes() and the rest of the functions.

2 1

VM debugging - breakpoint issue on Windows
by Vincent.Blondeau＠lamresearch.com 20 Apr '18

20 Apr '18

Hi, I would like to set up a breakpoint in the VM but I got this error when running: Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error. For this, I am using gdb under Cygwin (same issue with powershell) and invoque the primitive I want to test: pharo.cog.spur/builddbg/vm $ gdb --args ./Pharo.exe -headless ../..somewhereOnMyDisk.../Pharo.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY." I get these results: GNU gdb (GDB) 7.6.1 Reading symbols from C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm\Pharo.exe...done. Next, I set a breakpoint in the primitive C method I created and run the app: (gdb) br sqStdioDescriptorIsATTY Breakpoint 1 at 0x509cb6: file ../../platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c, line 337. (gdb) r Starting program: C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm/./Pharo.exe --headless ../../../../../../../../..temp/logoVM/logoVM.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY." [New Thread 27416.0x95bc] [New Thread 27416.0xa1d0] [New Thread 27416.0x3aa4] [New Thread 27416.0x88bc] (gdb) Warning: Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error. What should I do to set the breakpoint correctly? Thanks in advance, Vincent Blondeau

5 13

VM Maker: VMMaker.oscog-eem.2368.mcz
by commits＠source.squeak.org 20 Apr '18

20 Apr '18

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2368.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.2368 Author: eem Time: 20 April 2018, 9:42:35.891238 am UUID: aeb838a7-9c90-4db7-95a1-41a95014cee8 Ancestors: VMMaker.oscog-sk.2367 Check collation order byte array size in new string compare primitive as per Levente's suggestion. =============== Diff against VMMaker.oscog-sk.2367 =============== Item was changed: ----- Method: InterpreterPrimitives>>primitiveCompareWith (in category 'string primitives') ----- primitiveCompareWith "<string1> primitiveCompareWith: string2 [collated: order] " <export: true> | string1 string2 order strLength1 strLength2 result | "1 - fetch the parameters from the stack" + argumentCount = 1 ifFalse: + [argumentCount ~= 2 ifTrue: + [^self primitiveFailFor: PrimErrBadNumArgs]. + order := self stackTop. + ((objectMemory isBytes: order) + and: [(objectMemory numBytesOfBytes: order) = 256]) ifFalse: + [^self primitiveFailFor: PrimErrBadArgument]]. - (argumentCount = 0 or: [argumentCount > 2]) ifTrue: - [^self primitiveFailFor: PrimErrBadNumArgs]. - argumentCount = 1 - ifFalse: "argCount must be 2" - [order := self stackTop. - (objectMemory isBytes: order) ifFalse: [^self primitiveFailFor: PrimErrBadArgument]]. string1 := self stackValue: argumentCount. string2 := self stackValue: argumentCount - 1. "2 - check their types - all parameters are ByteObject" ((objectMemory isBytes: string1) + and: [objectMemory isBytes: string2]) ifFalse: + [^self primitiveFailFor: PrimErrBadArgument]. - and: [objectMemory isBytes: string2 ]) - ifFalse: - [^self primitiveFailFor: PrimErrBadArgument]. "3 - compare the strings" strLength1 := objectMemory numBytesOfBytes: string1. strLength2 := objectMemory numBytesOfBytes: string2. result := order + ifNil: [self rawCompare: string1 length: strLength1 with: string2 length: strLength2 accessBlock: + [:str :index | objectMemory fetchByte: index ofObject: str ]] - ifNil: [self rawCompare: string1 length: strLength1 with: string2 length: strLength2 accessBlock: [:str :index | objectMemory fetchByte: index ofObject: str ]] ifNotNil: + [self rawCompare: string1 length: strLength1 with: string2 length: strLength2 accessBlock: + [:str :index | objectMemory fetchByte: (objectMemory fetchByte: index ofObject: str) + 1 ofObject: order ]]. - [self rawCompare: string1 length: strLength1 with: string2 length: strLength2 accessBlock: [:str :index | objectMemory fetchByte: (objectMemory fetchByte: index ofObject: str) +1 ofObject: order ]]. - self pop: argumentCount + 1 thenPush: (objectMemory integerObjectOf: result) - + self methodReturnInteger: result !

1 0

Re: [Vm-dev] VM debugging - breakpoint issue on Windows
by David T. Lewis 19 Apr '18

19 Apr '18

I don't have the code in front of me, but look for configuration files called "plugins.int" and "plugins.ext" that specify plugins to be built either as internal or external. IIRC, the mvm scripts might clobber your local edits so you may have to play around with which files to edit where. Dave > > Hi Dave, > > The optimization options are already disabled in the debug build and > -ggdb2 is used. So, the real code is used. > > How do I change the build in a way that the plugin is external? > > Any experience is always welcome! Thanks! > > Vincent > > > -----Original Message----- > From: Vm-dev [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf > Of David T. Lewis > Sent: Wednesday, April 18, 2018 17:35 > To: Open Smalltalk Virtual Machine Development Discussion > <vm-dev(a)lists.squeakfoundation.org> > Subject: Re: [Vm-dev] VM debugging - breakpoint issue on Windows > > > Hi Vincent, > > I am not a Windows user so this may be completely wrong, but one thing I > have found in debugging plugins on Linux is that it is often necessary to > compile with optimization turned off so that the debugger is dealing with > the "real" code. > > I am guessing that perhaps your debugger is trying to use the C source > code to locate something that got optimized away by the compiler. > > Sometimes it is helpful to compile the plugin as an external plugin (a > DLL). You can compile it with zero optimization and compiler flags set > (-O0 -g or similar), and the resulting plugun should be visible to the > debugger. The plugin that you compile this way should work with any VM > (optimized or not) and the debugger should still be able to see it. > > I have not done this on Windows, but that is my experience on Linux so > maybe it will help. > > Dave > > > On Wed, Apr 18, 2018 at 06:33:12PM +0000, Vincent.Blondeau(a)lamresearch.com > wrote: >> >> Hi, >> >> I would like to set up a breakpoint in the VM but I got this error when >> running: >> Cannot insert breakpoint 1. >> Error accessing memory address 0x509cad: Input/output error. >> >> For this, I am using gdb under Cygwin (same issue with powershell) and >> invoque the primitive I want to test: >> pharo.cog.spur/builddbg/vm $ gdb --args ./Pharo.exe -headless >> ../..somewhereOnMyDisk.../Pharo.image eval "FilePluginPrims new >> primitiveStdioDescriptorIsATTY." >> >> I get these results: >> GNU gdb (GDB) 7.6.1 >> Reading symbols from >> C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm\Pharo.exe...done. >> >> Next, I set a breakpoint in the primitive C method I created and run the >> app: >> >> (gdb) br sqStdioDescriptorIsATTY >> Breakpoint 1 at 0x509cb6: file >> ../../platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c, line 337. >> (gdb) r >> Starting program: >> C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm/./Pharo.exe >> --headless ../../../../../../../../..temp/logoVM/logoVM.image eval >> "FilePluginPrims new primitiveStdioDescriptorIsATTY." >> [New Thread 27416.0x95bc] >> [New Thread 27416.0xa1d0] >> [New Thread 27416.0x3aa4] >> [New Thread 27416.0x88bc] >> (gdb) Warning: >> Cannot insert breakpoint 1. >> Error accessing memory address 0x509cad: Input/output error. >> >> What should I do to set the breakpoint correctly? >> >> Thanks in advance, >> >> Vincent Blondeau >> > >

1 0

[CfP] ICOOOLPS 2018
by Tim Felgentreff 19 Apr '18

19 Apr '18

Call for Papers: ICOOOLPS'18 ============================ 13th Workshop on Implementation, Compilation, Optimization of Object- Oriented Languages, Programs and Systems Co-located with ECOOP 2018 held Mon 16 - Sun 22 July in Amsterdam, Netherlands Twitter: @ICOOOLPS URL: https://conf.researchr.org/track/ecoop-issta-2018/ICOOOLPS-2018-papers The ICOOOLPS workshop series brings together researchers and practitioners working in the field of language implementation and optimization. The goal of the workshop is to discuss emerging problems and research directions as well as new solutions to classic performance challenges. The topics of interest for the workshop include techniques for the implementation and optimization of a wide range of languages including but not limited to object-oriented ones. Furthermore, meta-compilation techniques or language-agnostic approaches are welcome, too. ### Topics of Interest A non-exclusive list of topics of interest for this workshop is: - Implementation and optimization of fundamental languages features (from automatic memory management to zero-overhead metaprogramming) - Runtime systems technology (libraries, virtual machines) - Static, adaptive, and speculative optimizations and compiler techniques - Meta-compilation techniques and language-agnostic approaches for the efficient implementation of languages - Compilers (intermediate representations, offline and online optimizations,…) - Empirical studies on language usage, benchmark design, and benchmarking methodology - Resource-sensitive systems (real-time, low power, mobile, cloud) - Studies on design choices and tradeoffs (dynamic vs. static compilation, heuristics vs. programmer input,…) - Tooling support, debuggability and observability of languages as well as their implementations ### Workshop Format and Submissions This workshop welcomes the presentation and discussion of new ideas and emerging problems that give a chance for interaction and exchange. More mature work is welcome as part of a mini-conference format, too. We aim to interleave interactive brainstorming and demonstration sessions between the formal presentations to foster an active exchange of ideas. The workshop papers will be published in ACM DL or an open archive (to be confirmed). Papers are to be submitted using the sigplanconf LaTeX template (http://www.sigplan.org/Resources/LaTeXClassFile/). Please submit contributions via EasyChair: https://easychair.org/conferences/submission_show_all.cgi?a=17114062 ### Important Dates Submissions: 18 May 2018 Author Notification: 8 June 2018 ### Program Committee The program committee consists of the organizers and the following reviewers: Nada Amin, University of Cambridge Clément Béra, RMOD - INRIA Lille Nord Europe Shigeru Chiba, University of Tokyo Benoit Daloze, JKU Linz Görel Hedin, Lund University Eric Jul, University of Oslo Stefan Marr, University of Kent Eliot Miranda, Cadence Design Systems Sarah Mount, King's College London Tobias Pape, Hasso Plattner Institute Jennifer Sartor, Vrije Universiteit Brussel + University Ghent ### Workshop Organizers Tim Felgentreff, Oracle Labs Potsdam Olivier Zendra, INRIA / LORIA

1 0

[OpenSmalltalk/opensmalltalk-vm]
by GitHub 19 Apr '18

19 Apr '18

Branch: refs/heads/SpurPlanningCompactor Home: https://github.com/OpenSmalltalk/opensmalltalk-vm

1 0

[OpenSmalltalk/opensmalltalk-vm] 42c2af: Point out that under Xcode 9 the 10.10 SDK is requ...
by GitHub 18 Apr '18

18 Apr '18

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 42c2af2d48381d35ec9f0ee4ccfdd0d12a91845d https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/42c2af2d48381d35ec… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2018-04-18 (Wed, 18 Apr 2018) Changed paths: M build.macos32x86/HowToBuild Log Message: ----------- Point out that under Xcode 9 the 10.10 SDK is required for 32-bit Mac OS X.

1 0

[OpenSmalltalk/opensmalltalk-vm] 8a833c: Check for finding an SDK (the compiler error messa...
by GitHub 18 Apr '18

18 Apr '18

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 8a833c8f22609f8e58ffea022d9dbde735269d16 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/8a833c8f22609f8e58… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2018-04-18 (Wed, 18 Apr 2018) Changed paths: M build.macos32x86/HowToBuild M build.macos32x86/common/Makefile.flags M build.macos64x64/HowToBuild M build.macos64x64/common/Makefile.flags Log Message: ----------- Check for finding an SDK (the compiler error message is cryptic when this happens). Inform of the git repositories of SDKs as a source for them.

2 2

[OpenSmalltalk/opensmalltalk-vm] There is no bound check when marshalling FFI atomic integer arguments (#251)
by Nicolas Cellier 18 Apr '18

18 Apr '18

When marshalling integer values, the value is first extracted from the Smalltalk oop via the method `ffiIntegerValueOf:` . - SmallInteger -> SmallInteger value (signed value on 31 or 61 bits on 32bits and 64bits VM) - false/true -> 0/1 - nil -> 0 - Character -> Character value (may be more than 8 bits long!) - LargePositiveInteger -> 32bits positive integer value (or fail) (or 64 bits if ThreadedFFIPlugin) - LargeNegativeInteger -> 32bits signed integer value (or fail) (or 64bits if ThreadedFFIPlugin) Then the value is cast to the expected value in `ffiArgByValue:` which will have the effect of silently masking potential errors... (`1<<31` could be passed to a signed int and re-interpreted as `-(1<<31)` for example). IMO we could enforce bound checks and raise an Error... We should at least do this in the debug version if ever there is a concern about speed (but I don't think so). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/251

1 2

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev April 2018