Plugging Bee JIT and Compiler

This post should have been written long time ago. By now I already forgot many of the difficulties I found when plugging the JIT and Smalltalk compiler to Bee, but on the upside I now have a much bigger picture of the system so I can describe more things with more details than before. Where can we start? A good place can be to compare our self-hosted runtime against the host VM. What are the differences between the JIT in Bee and the host VM? To answer that, we have to understand what a JIT is, what it is made of, and how it is plugged to the system. Good! now we have some concrete things we can describe. What is a JIT compiler Just-in-time compiler. Well, the last word tells most: it is a compiler, and the JIT part refers to the fact that it is thought for working simultaneously with the program being run, unlike things like GCC to mention some compiler, which are used to compile programs before they are run. Smalltalk code, in most implementations is compiled to bytecode

The paper from ESUG '14

As I've been really busy lately and didn't find time write any new post yet, I thought that at least I could put here the paper from ESUG '14 for people that didn't see it. You may find it interesting. Many things were improved in the last two years (specially performance and completeness), but I still find the paper nice and come back to read it when I have to explain some part of the system and I don't know how. So, without further ado,  here it is .

Blogging back

Wow, one blink of an eye and around a year passes! It's been a long time since the last post... you'll have to excuse me, but I find it very hard to make a pause to write here when at the same time I'm facing amazing problems such as the ones Bee poses. I'll try writing here more frequently, I hope I'll have the needed will power to keep doing the exercise. Anyway, in case you were wondering, yes! there's been a whole lot of work done since last year and I'm going show some of the advances in the Smalltalks, which happens to be hosted in Buenos Aires this year. For a while I've been rounding corners of the self-hosted system, implementing missing primitives, working in the debugger, user interface, garbage collection and more. The next posts will describe some of that work, hope to see you soon!

Pre-releasing Bee Smalltalk

Today marks a key milestone in Bee project: we are realizing Bee main sources and libraries to the public sphere ! Do not get too excited yet. This is stated as a pre-release, because many things are yet missing and as the license is CC-BY-NC (for now). Also, there's no way to browse code like in a complete smalltalk environment, nor to rebuild the kernel. You can consider this as just a small preview of what the system is going to be like internally. There are two kinds of files: SLLs are the binary smalltalk libraries, SMLs contain the source code of their respective libraries. bee.sll is the main executable (it is just an .exe file, you can rename and double-click). In case no arguments are passed, a *REALLY* basic command line interface is shown, where you can enter some Smalltalk code: $> bee Welcome to bee. command line interface is waiting for you > 3+4+5 12 > 3 class SmallInteger > | o | o := Object new. o size 0 If you pass a file, like this:

Working on multithreading

A Smalltalk runtime that is able to execute concurrent sequences of code would be very useful. Seeing the rise of multicore/multiprocessor hardware and the direction the industry is taking, increasing the amount of cores in processors each year, makes us think we should be prepared. The simplest way of making use of multiple cores is to just avoid threads and directly work on multiple processes, connected by some kind of IPC. This is easier because different processes share nothing, except what you explicitly choose. Isolation helps program safety concurrency wise, as two fully separated processes cannot have race conditions between them. Then you would ask, why not just use processes? The main reason is that threads can be lighter and, in some way, more straightforward (as different threads share all their memory and resources). But also the question can be stated conversely, why not threads? Giving the option of using threads would be nice, so why not? There are lots of VMs wand

Bee performance and lookup strategies

It's been quite some time since last post, we'be been really busy cooking Bee Smalltalk. You wouldn't believe how much work is needed in order to connect the dots! We continued trying to make libraries load in bee, but we felt that performance was abysmal, library loading was taking ages and tests were ran so slow that they were slowing down the whole development process. In order to measure performance, we ported a bunch of benchmarks to bee. Bee nchmarks The first benchmark we took was the simplest we know: tinyBenchmarks. It consists of a rather simple pair of metrics. The first one estimates bytecode speed and the second one dispatch speed. The bytecode test does a lot of arithmetic (which is executed directly without message sends) and sends only few messages: #new: , #at: , #at:put: . On the other hand, the dispatch test calculates Fibonacci recursively: ^self < 2 ifTrue: [1] ifFalse: [(self - 1) fibonacchi + (self - 2) fibonacchi +

Connecting the dots

We've been working very hard this year. The seed that was planted years ago has been growing underground and we are now starting to see the first leaves pop out. After Smalltalks 2013 we had the chance to stop the ball, have an overview and open to wider perspectives. After some time, we got back to daily work and thought about the current situation and the next steps. We opened this blog to let people know about both the progress of this project and the ideas around it. Now that the year is gone, we'd like to share some overview and vision of the future. We have lot's of stuff going on here and many things almost working that need a last push to get integrated. You know, that 1% boring stuff. We now have this small kernel working with libraries which is the base of the system. We also have a jitter, a garbage collector, and a starting point of a debugger all of them written in Smalltalk , but none of them is plugged yet. So we are asking ourselves, what do we do next,