And CASCON can also be interesting for us to attend (depending on the final program).

Indeed. I'm up for going, and participating, if we can make it in. Would you come with us :D

- Maxime

Hello Tachyon,

I will probably not be able to make it to our Monday meeting. Would it be possible for us to meet on Wednesday instead?

- Maxime

Works for me too

Erick

Le 10-08-11 11:02 , Bruno Dufour a écrit :

On 2010-08-11, at 10:58 , chevalma@iro.umontreal.ca wrote:

...

Hello Tachyon,

I will probably not be able to make it to our Monday meeting. Would it be possible for us to meet on Wednesday instead?

Wednesday works for me.

Bruno _______________________________________________ Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list

Je suis désolé mais je dois changer le rendez-vous (problèmes de voiture/garagiste). Est-ce qu'on peut se rencontrer en après-midi? Disons 15h?

Marc

On 2010-08-11, at 3:55 PM, Marc Feeley wrote:

Wednesday 18 Aug, 10AM is ok with me too.

Marc

On 2010-08-11, at 11:56 AM, Erick Lavoie wrote:

...

Works for me too

Erick

Le 10-08-11 11:02 , Bruno Dufour a écrit :

...

On 2010-08-11, at 10:58 , chevalma@iro.umontreal.ca wrote:

...

Hello Tachyon,

I will probably not be able to make it to our Monday meeting. Would it be possible for us to meet on Wednesday instead?

Wednesday works for me.

Bruno _______________________________________________ Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list

---

Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list

---

Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list

Ok for me.

- Maxime

On 10-08-17 01:00 PM, Bruno Dufour wrote:

On 2010-08-17, at 12:45 , Marc Feeley wrote:

...

Je suis désolé mais je dois changer le rendez-vous (problèmes de voiture/garagiste). Est-ce qu'on peut se rencontrer en après-midi? Disons 15h?

Fine by me.

Bruno _______________________________________________ Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list

Voici un premier jet pour la proposition à soumettre:

We would like to submit a talk proposal for the Compiler-Driven Performance Workshop.

Talk title: Tachyon: a Meta-circular Optimizing JavaScript Virtual Machine

Author list: Maxime Chevalier-Boisvert Erick Lavoie Marc Feeley Bruno Dufour

Speaker: Maxime Chevalier-Boisvert

Abstract:

JavaScript is now the most widely supported dynamic programming language in existence; it is the language that powers the client-side of the web, and large companies such as Google and Microsoft have clearly stated their intent to build web applications intended to replace current desktop software based on this technology. Finding ways to get better performance out of JavaScript code and to improve support for the language have become foremost concerns.

The Tachyon project is a research initiative involving the creation of a meta-circular JavaScript virtual machine. This virtual machine is meta-circular because it is itself written in JavaScript and intended to compile and optimize itself just-in-time, along with client code, to platform-specific machine code. This project was officially started this year, and while still in early stages, offers the potential to offer researchers a simpler and more powerful alternative to explore novel dynamic language optimization techniques and study the behavior or dynamic languages.

At this stage, we intend to use this project to demonstrate the potential performance and design benefits of meta-circularity, to explore novel optimization techniques based on dynamic analysis, dynamic recompilation and on-stack replacement and to experiment with the idea of a virtual machine capable of serializing its own state. We intend to integrate Tachyon in a real web browser so as to test and demonstrate its capabilities in real-world situations, on non-synthetic JavaScript code. We further intend to make our system open source and available to other researchers.

...

Par 1: What do you mean by 'improve support for the language'?

Make it more easily portable. Our implementation will hopefully be more cross-platform or more easily ported than others.

- Maxime

Bruno

...

We would like to submit a talk proposal for the Compiler-Driven Performance Workshop.

Talk title: Tachyon: a Meta-circular Optimizing JavaScript Virtual Machine

Author list: Maxime Chevalier-Boisvert Erick Lavoie Marc Feeley Bruno Dufour

Speaker: Maxime Chevalier-Boisvert

Abstract:

JavaScript is now the most widely supported dynamic programming language in existence; it is the language that powers the client-side of the web, and large companies such as Google and Microsoft have clearly stated their intent to build web applications intended to replace current desktop software based on this technology. Finding ways to get better performance out of JavaScript code and to improve support for the language have become foremost concerns.

The Tachyon project is a research initiative involving the creation of a meta-circular JavaScript virtual machine. This virtual machine is meta-circular because it is itself written in JavaScript and intended to compile and optimize itself just-in-time, along with client code, to platform-specific machine code. This project was officially started this year, and while still in early stages, offers the potential to offer researchers a simpler and more powerful alternative to explore novel dynamic language optimization techniques and study the behavior or dynamic languages.

At this stage, we intend to use this project to demonstrate the potential performance and design benefits of meta-circularity, to explore novel optimization techniques based on dynamic analysis, dynamic recompilation and on-stack replacement and to experiment with the idea of a virtual machine capable of serializing its own state. We intend to integrate Tachyon in a real web browser so as to test and demonstrate its capabilities in real-world situations, on non-synthetic JavaScript code. We further intend to make our system open source and available to other researchers.

---

Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list

---

Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list

Here is the revised version:

JavaScript is now the most widely supported dynamic programming language in existence; it is the language that powers the client-side of the web, and large companies such as Google and Microsoft have clearly stated their intent to build web applications intended to replace current desktop software based on this technology. Finding ways to get better performance out of JavaScript code and to provide more portable implementations of the language have become foremost concerns.

The Tachyon project is a research initiative involving the creation of a meta-circular JavaScript virtual machine. This virtual machine is meta-circular because it is itself written in JavaScript and intended to compile and optimize itself just-in-time, along with client code, to platform-specific machine code. This project was officially started this year, and while still in early stages, has the potential to offer researchers a simpler and powerful alternative to explore novel dynamic language optimization techniques and study the behavior or dynamic languages.

We intend to use this project to demonstrate the potential performance and design benefits of meta-circularity, to explore novel optimization techniques based on dynamic analysis, dynamic recompilation and on-stack replacement and to experiment with the idea of a virtual machine capable of serializing its own state. We plan to integrate Tachyon in a real web browser so as to test and demonstrate its capabilities in real-world situations, on non-synthetic JavaScript code. We further intend to make our system open source and available to other researchers.

Sorry for the late reply. The abstract sounds good.

Marc

On 2010-08-23, at 10:55 AM, Maxime Chevalier-Boisvert wrote:

The submission date is tomorrow. Do we all agree on this revised version of the abstract?

• Maxime

On 10-08-20 11:57 AM, Maxime Chevalier-Boisvert wrote:

...

Here is the revised version:

JavaScript is now the most widely supported dynamic programming language in existence; it is the language that powers the client-side of the web, and large companies such as Google and Microsoft have clearly stated their intent to build web applications intended to replace current desktop software based on this technology. Finding ways to get better performance out of JavaScript code and to provide more portable implementations of the language have become foremost concerns.

The Tachyon project is a research initiative involving the creation of a meta-circular JavaScript virtual machine. This virtual machine is meta-circular because it is itself written in JavaScript and intended to compile and optimize itself just-in-time, along with client code, to platform-specific machine code. This project was officially started this year, and while still in early stages, has the potential to offer researchers a simpler and powerful alternative to explore novel dynamic language optimization techniques and study the behavior or dynamic languages.

We intend to use this project to demonstrate the potential performance and design benefits of meta-circularity, to explore novel optimization techniques based on dynamic analysis, dynamic recompilation and on-stack replacement and to experiment with the idea of a virtual machine capable of serializing its own state. We plan to integrate Tachyon in a real web browser so as to test and demonstrate its capabilities in real-world situations, on non-synthetic JavaScript code. We further intend to make our system open source and available to other researchers.

---

Tachyon-list mailing list

Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list

---

Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list

Following our discussion, we were thinking that we may want two pointer types in the IR: - pointers to objects with built-in offsets (to facilitate GC) - raw pointers to anywhere in memory (ignored by GC)

However, I have been wondering how efficient this would be in terms of performance, because pointers with offsets are bigger (up to twice as big) and the offset must be considered by many instruction operating on those pointers, adding extra overhead to these instructions. There is also the issue of extra GC concerns being mixed in with the IR.

I have been thinking that instead, a better solution might be to have only two pointer types in the IR: - Pointers to the start address of an object (directly usable by GC) - Raw pointers

Instead of passing an offset along, I am thinking of simply modifying the load and store instructions to take an offset along with an object pointer. This way, the backend can generate optimized code for those cases where we want to load and store at an offset, but the IR never sees anything but pointers to the start of an object.

Code that needs to iterate over addresses in an object would simply maintain the offset on its own, in a separate temporary. In addition, this may have the benefit of allowing a simple load with a immediate offset when the offset passed is a constant value.

- Maxime

I was thinking of only having pointer + offset, where both of these are SSA temporaries, and so the offset can either be a constant or a variable. The point is really to allow our object pointers to remain unchanged and safe for the GC to collect/modify while still allowing us to read and write in the middle of an object.

Optimizations that are specific to x86, such as those involving having the load/store instructions doing the actual pointer/offset arithmetic, should probably be done in the backend. LLVM seems to do it that way.

- Maxime

This sound fine. It keeps the IR simple and on the x86, our principal target, we can use the SIB addressing mode to combine the object reference with the offset (which can be a constant or in a register). By the way, you should support both constant offsets, register offsets, and a combination constant+register (as these are all useful and allowed by the x86, for example to implement the dynamic indexing of an array the reference to the object must be combined with an offset to cancel the tag and a register with the index). Perhaps you should also support a multiplier for the index... hmmm... that's pretty much the x86 addressing modes!

Marc

On 2010-08-25, at 1:52 PM, chevalma@iro.umontreal.ca wrote:

...

Following our discussion, we were thinking that we may want two pointer types in the IR:

• pointers to objects with built-in offsets (to facilitate GC)
• raw pointers to anywhere in memory (ignored by GC)

However, I have been wondering how efficient this would be in terms of performance, because pointers with offsets are bigger (up to twice as big) and the offset must be considered by many instruction operating on those pointers, adding extra overhead to these instructions. There is also the issue of extra GC concerns being mixed in with the IR.

I have been thinking that instead, a better solution might be to have only two pointer types in the IR:

• Pointers to the start address of an object (directly usable by GC)
• Raw pointers

Instead of passing an offset along, I am thinking of simply modifying the load and store instructions to take an offset along with an object pointer. This way, the backend can generate optimized code for those cases where we want to load and store at an offset, but the IR never sees anything but pointers to the start of an object.

Code that needs to iterate over addresses in an object would simply maintain the offset on its own, in a separate temporary. In addition, this may have the benefit of allowing a simple load with a immediate offset when the offset passed is a constant value.

• Maxime

---

Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list

---

Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list

I would like to propose two changes to the IR:

At the moment, I setup the MIR arithmetic and comparison instructions to mostly only allow pairs of arguments of the same type. For example, you can add a pair of 16 bit integers, or a pair of 32 bit integers, but not a 16 bit int and a 32 bit int.

Do you think it would make sense to always allow adding any two kinds of integers? Eg: an int64 could be added to either a 16, 32 or 64 bit integer. Would this complicate the back-end? What about adding signed and unsigned integer values together? I was thinking that should probably not be directly allowed, that it should require an explicit cast.

On another note, I currently have 3 of each add/mul/divide/modulo instructions (untyped, integer, and floating-point add/mul/divide/etc.) in the IR. I am considering combining all of these 3 (but not add/sub/mul with overflow) into one instruction, so as to make it easier to generate code for typed operations using standard arithmetic operators. That is, the front-end would try to use the same "add" instruction when generating code for the JavaScript operator "+", no matter the type of the operands. I would like your opinion on this as well.

- Maxime

I don't understand your point. Can you elaborate?

There are currently 4 add instructions in the IR (and 3 of each other arithmetic instruction). One for untyped values, one for integer values, one for floating-point, and one for integer add with overflow.

I am considering merging the untyped, integer and floating-point instructions (but not the add with overflow) into a single IR instruction. This would simplify the IR itself, and the production of IIR code.

- Maxime

...

So there will only be an "untyped add" instruction, and that

instruction will dispatch at runtime to do the right thing? That seems fine for the "high level" IR (because it directly corresponds to the JS semantics).

There would be only one add instruction, which would allow several different combinations of operand types, one of these being "all operands boxed", another being "two 16 bit integers", another being "two float64 values", etc. The instruction would also set its own output type based on the operand types.

When converting the AST, it only boxed adds would be produced. The semantics of the boxed add would be defined in terms of other instructions, including, say, 32 bit integer adds. So there would still be many different add instructions, just like now, but in terms of IR, all these instructions would be represented by the same class, with different input/output value types.

...

I have an unrelated question. What are the allowed operands of IR

operations like "add"? Is it always a temporary, or can it also be a constant? Anything else?

The operands are either SSA temporaries or a constant value. An SSA temporary is always the output of another instruction, which is why I introduced the "arg N" pseudo-instructions in the CFG, to have a way of referring to input arguments to a function as the output of some instruction. The IR is not low level enough to allow directly adding memory values. A value in memory has to be loaded into an SSA temporary before it can be added. This is also inspired by LLVM:

http://llvm.org/docs/LangRef.html#binaryops

- Maxime

I spent a few hours last night experimenting with the arguments object in v8, and trying to come up with some modifications in the IR code generation to emulate v8's behavior, but it seems not to be the right approach to this problem. I've discovered that the association between the arguments object and the formal parameter names is somewhat tricky to implement. Namely, you can pass the arguments object to sub-functions, and modifications to it will be reflected in the formal parameters, but you can also modify formal parameter values in closures, and this will modify the arguments object.

It seems like the proper way to implement this would be through a code transformation. The arguments object should be assigned to a fresh temporary, and references to formal parameters should be transformed into references to indices in that object, even in nested functions. As an example:

Original code: -------------------------

function foo(a0, a1, a2) { function bar() { a0 = 5; }

function bif() { delete a0; }

bar();

print(arguments[0]);

bif();

print(arguments[0]); print(a0); }

foo();

Output: -------------------------

5 undefined undefined

Transformed code: -------------------------

function foo(a0, a1, a2) { var argsObj = arguments;

function bar() { argsObj[0] = 5; }

function bif() { delete argsObj[0] }

bar();

print(arguments[0]);

bif();

print(arguments[0]); print(argsObj[0]); }

foo();

Seeing Marc is busy, I will try to implement this myself. I need to be able to generate a "fresh" name that can't be accessed by the user (even through eval) for the arguments object alias. For this, I was thinking of prefixing the name with an illegal JS token, such as # or @.

- Maxime

On 10-08-07 11:24 AM, chevalma@iro.umontreal.ca wrote:

This would involve giving an oral presentation at a workshop? Out of curiosity, does that count as a peer-reviewed publication?

I think this is probably a good venue to present our project at. It's also conveniently close.

• Maxime

...

This would be a good workshop to present the Tachyon project. Let's talk about it at the next meeting (August 16).

Marc

Begin forwarded message:

...

From: clark verbruggeclump@cs.mcgill.ca Date: August 6, 2010 3:06:48 PM PDT To: undisclosed-recipients:; Subject: 9th Compiler-Driven Performance Workshop - CASCON 2010

            9th Compiler-Driven Performance Workshop
                     November 4, 2010 (Thursday)

           Hilton Suites Toronto/Markham Conference Centre
                   Associated with CASCON 2010
                 (http://www.cas.ibm.com/cascon)
                         (Nov 1-4 2010)

Dear Colleague:

We would like to invite you to participate in the 9th Compiler-Driven Performance Workshop (CDP10) which will be held during the IBM Center for Advanced Studies Conference (CASCON) 2010 in Markham, Ontario, Canada.

In the past seven years we had very successful one-day events in which faculty members, students and practitioners presented their recent work and research plans.

Topics to be discussed in the workshop include, but are not limited to:

• innovative analysis, transformation, and optimization techniques

• languages, compilers, and optimization techniques for multicore

processors and other parallel architectures

• compiling for streaming or heterogeneous hardware

• dynamic compilation for high-performance and real-time environments

• compilation and optimization for scripting languages

• compilation techniques for reducing power

• tools and infrastructure for compiler research

SUBMISSION:

NO LATER THAN WEDNESDAY AUGUST 24, we would like to hear from you if you ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ would like to give a talk about your research or to volunteer a student to do so. Please send, by email to clump@cs.mcgill.ca, your talk title, the author list, the name of the speaker, and a brief abstract.

Please note that the number of presentation slots is quite limited. Once we have a list of title/speakers, we will let you know if your presentation has been selected.

CDP does not publish proceedings. Presenters are required to provide an electronic copy of their slides. The slides will be available on a website soon after the workshop.

CASCON has a very well organized exhibit section that is an excellent forum to display students' current work and allow for discussions. We would like to suggest that you encourage some of your students to participate in the exhibit section.

We also would like to encourage all participants to gather during the lunch and coffee breaks for more informal interactions. The workshop does not have funds to defray the travel/lodging costs for participants/speakers. However registration for CASCON is free, and lunch is provided to all attendees.

We look forward to your participation in CDP10!

Steering Committee: Kit Barton - IBM Toronto Lab David Grove - IBM Watson Ondrej Lhotak - University of Waterloo J. Gregory Steffan - University of Toronto Mark Stoodley - IBM Toronto Lab Clark Verbrugge - McGill University

-- ttfn, clark clump@cs.mcgill.ca

---

Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list

---

Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list

...

That's a pretty common approach, we could have some prefix for all

generated vars (e.g. tachyon#).

Good idea. I'll write a genFreeId function. Right now I'm trying to find what Marc has in place to create id objects... Hopefully I'll find something in the scanner code.

...

I assume that you want to transform the code prior to building the IR

That's correct. I think it's best to keep the IR generation simpler and avoid having to deal with multiple levels of function nesting during the translation.

...

otherwise you could just reuse the same mechanism that is generates

temporary var names in your IR construction phase.

There are no real variable names in the IR. Since it's in SSA form, temporaries are direct references to the instruction that defines the value. I added a mechanism to assign unique variable names within a given CFG to make the output more readable.

- Maxime