digitalmars.D.announce - bugzilla 424 - Unexpected OPTLINK Termination - solved!
- Walter Bright <newshound1 digitalmars.com> Nov 03 2009
- Bill Baxter <wbaxter gmail.com> Nov 03 2009
- Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Nov 03 2009
- Walter Bright <newshound1 digitalmars.com> Nov 03 2009
- Tim Matthews <tim.matthews7 gmail.com> Nov 04 2009
- Franklin Minty <franmin gmail.com> Nov 04 2009
- "Nick Sabalausky" <a a.a> Nov 03 2009
- Tom S <h3r3tic remove.mat.uni.torun.pl> Nov 03 2009
- Eldar Insafutdinov <e.insafutdinov gmail.com> Nov 03 2009
- Walter Bright <newshound1 digitalmars.com> Nov 03 2009
- Eldar Insafutdinov <e.insafutdinov gmail.com> Nov 03 2009
- Yigal Chripun <yigal100 gmail.com> Nov 03 2009
- Walter Bright <newshound1 digitalmars.com> Nov 03 2009
- Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Nov 03 2009
- Yigal Chripun <yigal100 gmail.com> Nov 03 2009
- BLS <windevguy hotmail.de> Nov 04 2009
- grauzone <none example.net> Nov 04 2009
- Bill Baxter <wbaxter gmail.com> Nov 04 2009
- grauzone <none example.net> Nov 04 2009
- Walter Bright <newshound1 digitalmars.com> Nov 04 2009
- grauzone <none example.net> Nov 04 2009
- Tom S <h3r3tic remove.mat.uni.torun.pl> Nov 04 2009
- KennyTM~ <kennytm gmail.com> Nov 04 2009
- =?iso-8859-15?Q?Robert_M=2E_M=FCnch?= <robert.muench robertmuench.de> Nov 05 2009
- Bill Baxter <wbaxter gmail.com> Nov 04 2009
- Leandro Lucarella <llucax gmail.com> Nov 04 2009
- Leandro Lucarella <llucax gmail.com> Nov 04 2009
- Leandro Lucarella <llucax gmail.com> Nov 04 2009
- Sergey Gromov <snake.scaly gmail.com> Nov 26 2009
- Walter Bright <newshound1 digitalmars.com> Nov 26 2009
- Sergey Gromov <snake.scaly gmail.com> Nov 26 2009
- bearophile <bearophileHUGS lycos.com> Nov 27 2009
- Don <nospam nospam.com> Nov 26 2009
- Sergey Gromov <snake.scaly gmail.com> Nov 26 2009
Optlink is written entirely in rather impenetrable assembler code, and is resistant to understanding and modification. Hence, over the last few months I've been very slowly converting it to C, function by function. One might ask, why not convert it to D? The answer is that I don't have a good test suite for optlink, so I have to be very very careful to not make a mistake in the translation. That means do one function at a time, rebuild, and retest, which means the compiled C code has to match the segment, naming and calling conventions used in optlink. I made a custom version of the dmc compiler to do this. Also, C can be made to work without any runtime library support at all, and since optlink does not use the C runtime library, this is useful. Once it is in C and working, it will be trivial to translate it to D and start rewriting it. Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!). The fix will go out in the next update, if you need it sooner please email me.
Nov 03 2009
This is the too many fixups bug?! If so that's great news. So is it any slower now with things not in ASM? --bb On Tue, Nov 3, 2009 at 10:39 AM, Walter Bright <newshound1 digitalmars.com> wrote:Optlink is written entirely in rather impenetrable assembler code, and is resistant to understanding and modification. Hence, over the last few months I've been very slowly converting it to C, function by function. One might ask, why not convert it to D? The answer is that I don't have a good test suite for optlink, so I have to be very very careful to not make a mistake in the translation. That means do one function at a time, rebuild, and retest, which means the compiled C code has to match the segment, naming and calling conventions used in optlink. I made a custom version of the dmc compiler to do this. Also, C can be made to work without any runtime library support at all, and since optlink does not use the C runtime library, this is useful. Once it is in C and working, it will be trivial to translate it to D and start rewriting it. Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!). The fix will go out in the next update, if you need it sooner please email me.
Nov 03 2009
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Bill Baxter wrote:This is the too many fixups bug?! If so that's great news.
Yah. http://d.puremagic.com/issues/show_bug.cgi?id=424 Andrei
Nov 03 2009
Bill Baxter wrote:So is it any slower now with things not in ASM?
Haven't measured it, but I doubt it, as it's only about 5% in C now. Although asm code can be very small and fast, and optlink is the best of the best at that, it tends to be brittle (very hard to change the algorithm). The biggest speed gains are from algorithmic improvements.
Nov 03 2009
Bill Baxter wrote:So is it any slower now with things not in ASM? --bb
You are not serious are you? The linker not the linked? If it's functionally more correct, easier to understand and easier to implement link time optimizations then how can anyone justify asm to c transition (where asm is not required) as a disadvantage?
Nov 04 2009
Tim Matthews Wrote:Bill Baxter wrote:So is it any slower now with things not in ASM? --bb
You are not serious are you? The linker not the linked? If it's functionally more correct, easier to understand and easier to implement link time optimizations then how can anyone justify asm to c transition (where asm is not required) as a disadvantage?
it will be slower - I want my 100ms back.
Nov 04 2009
"Walter Bright" <newshound1 digitalmars.com> wrote in message news:hcptci$l06$1 digitalmars.com...[great optlink news]
That's great news!
Nov 03 2009
Am I dreaming? This is too good to be true :O Walter, have you been replaced by an alien or reprogrammed using some sci-fi device? I can't believe the MsgBox of death is going away! -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Nov 03 2009
Walter Bright Wrote:Optlink is written entirely in rather impenetrable assembler code, and is resistant to understanding and modification. Hence, over the last few months I've been very slowly converting it to C, function by function. One might ask, why not convert it to D? The answer is that I don't have a good test suite for optlink, so I have to be very very careful to not make a mistake in the translation. That means do one function at a time, rebuild, and retest, which means the compiled C code has to match the segment, naming and calling conventions used in optlink. I made a custom version of the dmc compiler to do this. Also, C can be made to work without any runtime library support at all, and since optlink does not use the C runtime library, this is useful. Once it is in C and working, it will be trivial to translate it to D and start rewriting it. Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!). The fix will go out in the next update, if you need it sooner please email me.
Why not changing object format instead and using format acceptable by the linker from MinGW suit? That could free you from rewriting the linker in C, then in D and then maintaining it. Are there any difficulties (technical or even licensing)?
Nov 03 2009
Eldar Insafutdinov wrote:Why not changing object format instead and using format acceptable by the linker from MinGW suit? That could free you from rewriting the linker in C, then in D and then maintaining it. Are there any difficulties (technical or even licensing)?
I'd have to give up the entire toolchain on windows to do that. Also, the gnu linker is dog slow.
Nov 03 2009
Walter Bright Wrote:Eldar Insafutdinov wrote:Why not changing object format instead and using format acceptable by the linker from MinGW suit? That could free you from rewriting the linker in C, then in D and then maintaining it. Are there any difficulties (technical or even licensing)?
I'd have to give up the entire toolchain on windows to do that. Also, the gnu linker is dog slow.
Ok, thank you for the answer and for fixing optlink!
Nov 03 2009
On 03/11/2009 20:39, Walter Bright wrote:Optlink is written entirely in rather impenetrable assembler code, and is resistant to understanding and modification. Hence, over the last few months I've been very slowly converting it to C, function by function. One might ask, why not convert it to D? The answer is that I don't have a good test suite for optlink, so I have to be very very careful to not make a mistake in the translation. That means do one function at a time, rebuild, and retest, which means the compiled C code has to match the segment, naming and calling conventions used in optlink. I made a custom version of the dmc compiler to do this. Also, C can be made to work without any runtime library support at all, and since optlink does not use the C runtime library, this is useful. Once it is in C and working, it will be trivial to translate it to D and start rewriting it. Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!). The fix will go out in the next update, if you need it sooner please email me.
awesome news! Once Optlink is moved to C and than D, it could grow new features like link-time optimizations.
Nov 03 2009
Yigal Chripun wrote:Once Optlink is moved to C and than D, it could grow new features like link-time optimizations.
It does open up a lot of possibilities. One I think would be of big benefit is for two COMDATs with different names, but the same contents, being merged. This would eliminate a lot of template bloat. Currently, COMDATs are merged if and only if their names match exactly. Another possibility is to merge the linker with dmd, so it can generate executables directly without having to go through an object file step.
Nov 03 2009
Walter Bright wrote:Yigal Chripun wrote:Once Optlink is moved to C and than D, it could grow new features like link-time optimizations.
It does open up a lot of possibilities. One I think would be of big benefit is for two COMDATs with different names, but the same contents, being merged. This would eliminate a lot of template bloat. Currently, COMDATs are merged if and only if their names match exactly. Another possibility is to merge the linker with dmd, so it can generate executables directly without having to go through an object file step.
Well it opens up a lot of possibilities *on Windows only*, which is liable to dampen some enthusiasm. Andrei
Nov 03 2009
On 04/11/2009 00:18, Walter Bright wrote:Yigal Chripun wrote:Once Optlink is moved to C and than D, it could grow new features like link-time optimizations.
It does open up a lot of possibilities. One I think would be of big benefit is for two COMDATs with different names, but the same contents, being merged. This would eliminate a lot of template bloat. Currently, COMDATs are merged if and only if their names match exactly. Another possibility is to merge the linker with dmd, so it can generate executables directly without having to go through an object file step.
Merging the linker with DMD is an excellent idea. There still should be a flag to generate object files, but in general there are only two useful artifacts the compiler should generate: executable and lib. I'd want to see also integration of DDL or something similar in concept so the libs generated by DMD could be used as shared libs. Another feature that would be nice to have is incremental compilation. each time you run dmd it would update the previous lib file with the delta of changes instead of regenerating it from scratch.
Nov 03 2009
On 03/11/2009 23:18, Walter Bright wrote:Yigal Chripun wrote:Once Optlink is moved to C and than D, it could grow new features like link-time optimizations.
It does open up a lot of possibilities. One I think would be of big benefit is for two COMDATs with different names, but the same contents, being merged. This would eliminate a lot of template bloat.
I think this could give DWT the necessary new breath...
Nov 04 2009
Walter Bright wrote:Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!).
And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows. And no, GNU ld is not too slow. The most time during building is wasted due to not having _working_ incremental building (Tom S discussed the issues about that with you). Additionally, I prefer a slow, working linker over a fast, crashing one.
Nov 04 2009
On Wed, Nov 4, 2009 at 10:21 AM, Leandro Lucarella <llucax gmail.com> wrote= :grauzone, el =A04 de noviembre a las 17:23 me escribiste:Walter Bright wrote:Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!).
And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows. And no, GNU ld is not too slow.
And if you really find it slow, GNU Gold (done by Google) is *much* faster.
Interesting. Detailed series of 20 blog posts by the author here: http://www.airs.com/blog/archives/38 http://www.airs.com/blog/archives/39 ... http://www.airs.com/blog/archives/57 Looks like interesting reading. --bb
Nov 04 2009
Leandro Lucarella wrote:grauzone, el 4 de noviembre a las 17:23 me escribiste:Walter Bright wrote:Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!).
without bugs! I had to add hacks to my code to make it linkable on Windows. And no, GNU ld is not too slow.
And if you really find it slow, GNU Gold (done by Google) is *much* faster.
Last I heard from it, Gold (or dmd?) had some bugs which made it unusable with dmd. Did that get fixed meanwhile?
Nov 04 2009
grauzone wrote:And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows.
I've spent many hours trying to find workarounds for ld problems and undocumented behaviors. The prime suspect in dmd not working on Snow Leopard is a change in the linker behavior.And no, GNU ld is not too slow. The most time during building is wasted due to not having _working_ incremental building (Tom S discussed the issues about that with you).
Do you mean incremental linking or incremental compiling?Additionally, I prefer a slow, working linker over a fast, crashing one.
Of course. No argument there.
Nov 04 2009
Walter Bright wrote:grauzone wrote:And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows.
I've spent many hours trying to find workarounds for ld problems and undocumented behaviors. The prime suspect in dmd not working on Snow Leopard is a change in the linker behavior.
I bet OPTLINK caused more work than ld for both you and your users in summary. Anyway, it's your software, your decisions etc...And no, GNU ld is not too slow. The most time during building is wasted due to not having _working_ incremental building (Tom S discussed the issues about that with you).
Do you mean incremental linking or incremental compiling?
Compiling. I think it had to do with emitting code for templates. DSSS (rebuild) had the same problem, and its author just gave up and called dmd once per source file, which made it awfully slow. xfbuild (Tom S is its author, isn't he?) incremental building still doesn't work for me because of the same issue.Additionally, I prefer a slow, working linker over a fast, crashing one.
Of course. No argument there.
Nov 04 2009
grauzone wrote:Walter Bright wrote:grauzone wrote:And no, GNU ld is not too slow. The most time during building is wasted due to not having _working_ incremental building (Tom S discussed the issues about that with you).
Do you mean incremental linking or incremental compiling?
Compiling. I think it had to do with emitting code for templates. DSSS (rebuild) had the same problem, and its author just gave up and called dmd once per source file, which made it awfully slow. xfbuild (Tom S is its author, isn't he?) incremental building still doesn't work for me because of the same issue.
The template emission method that DMD employs is a nice optimization, however until http://d.puremagic.com/issues/show_bug.cgi?id=3327 is fixed, incremental building may still be in trouble (and thus an option to control the emission might be useful). Additionally, http://d.puremagic.com/issues/show_bug.cgi?id=3328 is hindering the potential speed of an experimental incremental build tool I've created to work with the template emission optimization. The latter issue should be quite simple to to fix, but the former looks rather tricky and might be hitting some limitations of OMF. -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Nov 04 2009
On Nov 5, 09 02:21, Leandro Lucarella wrote:grauzone, el 4 de noviembre a las 17:23 me escribiste:Walter Bright wrote:Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!).
And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows. And no, GNU ld is not too slow.
And if you really find it slow, GNU Gold (done by Google) is *much* faster.
Nov 04 2009
Am 04.11.2009, 20:08 Uhr, schrieb Bill Baxter <wbaxter gmail.com>:Interesting. Detailed series of 20 blog posts by the author here: http://www.airs.com/blog/archives/38 http://www.airs.com/blog/archives/39 ... http://www.airs.com/blog/archives/57 Looks like interesting reading.
Hi, wow. Great stuff. Saved and put into my knowledge-base archive. Robert
Nov 05 2009
On Wed, Nov 4, 2009 at 12:28 AM, Tim Matthews <tim.matthews7 gmail.com> wrote:Bill Baxter wrote:So is it any slower now with things not in ASM? --bb
You are not serious are you? The linker not the linked? If it's functionally more correct, easier to understand and easier to implement link time optimizations then how can anyone justify asm to c transition (where asm is not required) as a disadvantage?
Walter often defends sticking with OPTLINK because it is fast. And the implication is that it is fast in part because it's all in hand-coded ASM. I was merely curious if that was holding up or not, or if in fact being in ASM was irrelevant to the speed. I would think linkers would be mostly IO bound since they do fairly simple things with large amounts of data, so that would argue that it shouldn't matter much whether it's in ASM or C. --bb
Nov 04 2009
grauzone, el 4 de noviembre a las 17:23 me escribiste:Walter Bright wrote:Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!).
And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows. And no, GNU ld is not too slow.
And if you really find it slow, GNU Gold (done by Google) is *much* faster. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Robar un alfajor es revolucionario, pues rompe con la idea de propiedad, incluso más que si se tratara de dinero. -- publikazion anarkista mdp (hablando de los destrozos de la Cumbre de las Americas en Mar del Plata, 2005)
Nov 04 2009
Bill Baxter, el 4 de noviembre a las 11:08 me escribiste:On Wed, Nov 4, 2009 at 10:21 AM, Leandro Lucarella <llucax gmail.com> wrote:grauzone, el 4 de noviembre a las 17:23 me escribiste:Walter Bright wrote:Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!).
And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows. And no, GNU ld is not too slow.
And if you really find it slow, GNU Gold (done by Google) is *much* faster.
Interesting. Detailed series of 20 blog posts by the author here:
BTW, Gold already support LTO (LInk Time Optimization) via plug-ins for both GCC (meaning GDC could use it in the future) and LLVM (meaning LDC could use it in the future, maybe even now, I didn't test it). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- CAYO HUGO CONZI --- TENIA PUESTA PELUCA -- Crónica TV
Nov 04 2009
grauzone, el 4 de noviembre a las 20:23 me escribiste:Leandro Lucarella wrote:grauzone, el 4 de noviembre a las 17:23 me escribiste:Walter Bright wrote:Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!).
without bugs! I had to add hacks to my code to make it linkable on Windows. And no, GNU ld is not too slow.
And if you really find it slow, GNU Gold (done by Google) is *much* faster.
Last I heard from it, Gold (or dmd?) had some bugs which made it unusable with dmd. Did that get fixed meanwhile?
Yes, I reported the bug[1] and it has been fixed in DMD 1.046 and 2.031. [1] http://d.puremagic.com/issues/show_bug.cgi?id=2932 -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- ... los cuales son susceptibles a una creciente variedad de ataques previsibles, tales como desbordamiento del tampón, falsificación de parámetros, ... -- Stealth - ISS LLC - Seguridad de IT
Nov 04 2009
Tue, 03 Nov 2009 10:39:13 -0800, Walter Bright wrote:Optlink is written entirely in rather impenetrable assembler code, and is resistant to understanding and modification. Hence, over the last few months I've been very slowly converting it to C, function by function. [...] Once it is in C and working, it will be trivial to translate it to D and start rewriting it. Anyhow, during this process I stumbled upon what the problem was.
That's definitely good news! Actually, I'm slowly working on a D linker myself. Writing it in D, from scratch. My goal is to allow linking a mix of OMF and COFF objects and libraries into the same executable, obviating the need for any conversion. I wonder if it's feasible to continue my work. I'm just a couple baby steps beyond the rough design stage. Well, probably I'll continue anyway, as long as I've got the courage. I like to re-invent wheels after all.
Nov 26 2009
Sergey Gromov wrote:Actually, I'm slowly working on a D linker myself. Writing it in D, from scratch. My goal is to allow linking a mix of OMF and COFF objects and libraries into the same executable, obviating the need for any conversion. I wonder if it's feasible to continue my work. I'm just a couple baby steps beyond the rough design stage. Well, probably I'll continue anyway, as long as I've got the courage. I like to re-invent wheels after all.
Building a linker itself is probably not too useful, given that it'll be hard to compete with optlink. What would be cool, though, is a linker that is able to do more advanced things - like organizing the code to minimize page loading, eliminating functions that are identical except for the name, etc.
Nov 26 2009
Thu, 26 Nov 2009 12:02:59 -0800, Walter Bright wrote:Sergey Gromov wrote:Actually, I'm slowly working on a D linker myself. Writing it in D, from scratch. My goal is to allow linking a mix of OMF and COFF objects and libraries into the same executable, obviating the need for any conversion. I wonder if it's feasible to continue my work. I'm just a couple baby steps beyond the rough design stage. Well, probably I'll continue anyway, as long as I've got the courage. I like to re-invent wheels after all.
Building a linker itself is probably not too useful, given that it'll be hard to compete with optlink. What would be cool, though, is a linker that is able to do more advanced things - like organizing the code to minimize page loading, eliminating functions that are identical except for the name, etc.
It's definitely possible to compete with optlink in maintainability and extensibility. :) As to the optimizations, we'll see if I can pull it off.
Nov 26 2009
Walter Bright:What would be cool, though, is a linker that is able to do more advanced things -
This may be useful as guide (not used by LDC yet): http://llvm.org/docs/GoldPlugin.html Bye, bearophile
Nov 27 2009
Sergey Gromov wrote:Tue, 03 Nov 2009 10:39:13 -0800, Walter Bright wrote:Optlink is written entirely in rather impenetrable assembler code, and is resistant to understanding and modification. Hence, over the last few months I've been very slowly converting it to C, function by function. [...] Once it is in C and working, it will be trivial to translate it to D and start rewriting it. Anyhow, during this process I stumbled upon what the problem was.
That's definitely good news! Actually, I'm slowly working on a D linker myself. Writing it in D, from scratch. My goal is to allow linking a mix of OMF and COFF objects and libraries into the same executable, obviating the need for any conversion. I wonder if it's feasible to continue my work. I'm just a couple baby steps beyond the rough design stage. Well, probably I'll continue anyway, as long as I've got the courage. I like to re-invent wheels after all.
I hope you're making use of pragma's DDL code. He did so much work in making sense of the object file formats.
Nov 26 2009
Fri, 27 Nov 2009 01:10:36 +0100, Don wrote:Sergey Gromov wrote:Actually, I'm slowly working on a D linker myself.
I hope you're making use of pragma's DDL code. He did so much work in making sense of the object file formats.
Good thing you told me. I'll definitely try to reuse as much of DDL code as possible. Thanks for the pointer.
Nov 26 2009