JerryScript

Video in TIB AV-Portal: JerryScript

Formal Metadata

Title
JerryScript
Subtitle
An ultra-lightweight JavaScript engine for the Internet of Things
Title of Series
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
2018
Language
English
Production Year
2017

Content Metadata

Subject Area
Abstract
JerryScript is a lightweight JavaScript engine designed to bring the successof JavaScript to small IoT devices like lamps, thermometers, switches andsensors. This class of devices tends to use resource-constrainedmicrocontrollers which are too small to fit a large JavaScript engine like V8or JavaScriptCore. JerryScript is heavily optimized for low memory consumptionand runs on platforms with less than 64KB of RAM and less than 200KB of flashmemory. Despite the low footprint, JerryScript is a full-featured JavaScriptengine implementing the entire ECMAScript 5.1 standard. It is actively used inproduction and already runs on more than one million smartwatches! JerryScriptis an open source project and has been released under the Apache License 2.0.The talk will include a demo showing JavaScript code executing on top ofJerryScript on a resource-constrained microcontroller.
Loading...
Dynamical system Group action Just-in-Time-Compiler Code Multiplication sign Computer programming Formal language Web 2.0 Semiconductor memory Computer configuration Atomic number Different (Kate Ryan album) Core dump Damping Extension (kinesiology) Data compression Scripting language Compact space Software developer Constructor (object-oriented programming) Bit Maxima and minima Connected space Abstract syntax tree Message passing Spacetime Bytecode Game controller Overhead (computing) Open source Characteristic polynomial Translation (relic) Microcontroller Web browser Peripheral Natural number Term (mathematics) Operator (mathematics) Representation (politics) Energy level Data structure Address space Mathematical optimization Task (computing) Key (cryptography) Demo (music) Projective plane Memory management Cartesian coordinate system Pointer (computer programming) Software Personal digital assistant Interpreter (computing) Video game Object (grammar) Table (information)
Suite (music) Machine code Run time (program lifecycle phase) Code Multiplication sign Source code Real-time operating system Order of magnitude Formal language Different (Kate Ryan album) Semiconductor memory Cuboid Extension (kinesiology) Thumbnail Scripting language Compact space File format Bit Benchmark Measurement Process (computing) Whiteboard Conformal map Resultant Bytecode Slide rule Trail Functional (mathematics) Overhead (computing) Open source Robot Flash memory Tape drive Microcontroller Portable communications device Number Profil (magazine) Term (mathematics) Computer hardware Operating system Software testing Address space Computing platform Mathematical optimization Standard deviation Demo (music) Line (geometry) Cartesian coordinate system Compiler Personal digital assistant Mixed reality Library (computing)
Implementation Code Telecommunication Matrix (mathematics) Game theory Whiteboard Quicksort Computer Field (computer science) Asynchronous Transfer Mode
Software Personal digital assistant Bit Communications protocol Asynchronous Transfer Mode
Point (geometry) Building Code Multiplication sign Direction (geometry) 40 (number) Mereology Product (business) Revision control Mathematics Latent heat Term (mathematics) Semiconductor memory Different (Kate Ryan album) Linear programming Core dump Energy level Software framework Software testing 9 (number) Computer architecture Scripting language Smoothing Software developer Projective plane Moment (mathematics) Planning Bit Software maintenance Measurement Process (computing) Personal digital assistant Musical ensemble Reading (process)
almost he can give us okay yeah so uh hi my
name is Tillman chela I work in the Samsung open source group and I'm here today to talk about Jerry script so I'll start off just talking a little bit about JavaScript what it does how it works and so on and then I'll show you a quick demo data set up on the table there in front already and then we'll have time for a couple of questions so yeah essentially what is Jerry script Jerry script is a really lightweight JavaScript engine so we developed that from scratch and really with the goal of having an engine that can run on really resource constrained microcontrollers so devices let's say I think like 32k of RAM is is what you need to do something which is not just a hello world so for a hello world you right now you need 3k of RAM so that's basically the bare minimum of memory that you need on the device and yeah as I said originally it was developed by Samsung but now we have a small community around it various different companies contributing and it's an open source project so it's released under the Apache License 2.0 and you can find it on github and yeah so yeah one of the first questions usually we get when we talk about Jerry script is that people ask why do you even want to run JavaScript on a microcontroller why not just use C and the motivation for that is that javascript is such a popular language and it's really easy to you to use and to learn and there so many developers out there that we just want to give them a way to develop for small low-end IOT devices in the languages they used to and and yeah with the tools that they used to so that's kind of our core motivation for doing this and the other thing is that in this segment like small IOT connected is running on a microcontroller that you typically are not really you don't really run performance critical code there is more like control tasks pulling some sense or sending some Network messages and so there you can also at least to a certain extent get away with the inherent performance overhead a JavaScript engine always has and the the other thing is that or the hope is that JavaScript being a higher level language then see you you can be more productive you can write a code faster develop your application faster and also your products and get them shipped faster so that's kind of the the hope there and another interesting aspect is that with JavaScript it's also really easy to just load some code over the web and so you could think for example you have a small microcontroller and then run an webserver on that like a really really simple light white one and connect with a web browser and enter some JavaScript code executed life on the device and maybe interact with some peripherals connected to the microcontroller so that's something especially for prototyping I think that's would be an interesting use case and that's very easy to do with JavaScript but if you want to do this with C this will be much more complicated so that's that's kind of one the dynamic nature of JavaScript helps a bit there so yeah just a couple of like kind of the key characteristics of JavaScript to give you a better idea essentially the single most optimal single most important optimization goal is to have a low memory footprint because that's typically the resource you are the most constrained on the device we also care a lot about performance and the code size of the engine itself but a lot of the optimizations are really targeted to keeping the memory usage as low as possible and that's also why we do things like so we don't do any just-in-time compilation we just don't have enough space for that so we we just have an a classic interpreter which executes the javascript bytecode and all those things and to achieve the the low memory footprint we do various different things so one thing is that we have a very compact object representation so all the the data structures that we need in the engine to represent a JavaScript object so that is very much optimized to be as compact as possible and then we we also do things like pointer compression so internally on our heap we use 16-bit pointers even though we typically execute on a 32-bit host so that way especially for pointer heavy programs we we save a lot of memory because essentially our pointers are half the size than they would would be regularly so obviously that you have to pay the price in terms of whenever there is a access to memory you have to compress or decompress the pointer but what from what we've seen is still the trade-off is still if you are on a constrained device to still pays off over all and for people who who don't want to use compressed pointers we also have an option to turn that off and that also gives you a larger address space so right now with pointer compression turned on you can just address 512k of memory which is for most of the really small devices just fine but yeah if you have a device with two megabytes and you really want to use that then you you can also turn it off in terms of translation from the sources to the byte code that we actually execute there's we try to be as lightweight as possible so we go while we are passing we are already creating the bytecode instructions and we are not having any intermediate representations in between so we don't even construct an AST so a C stands for abstract syntax tree so we go straight while we pass we already create the code and at the at the very core of the engine is the compact bytecode of Terry scripts so that's also what one of the key features that makes JavaScript successful so this is essentially we have like I think like two or three hundred different byte code operations that represent common constructs in JavaScript and then we don't execute them directly we have we decompose them into up to five kind of atomic operations which are much more simple and those are implemented by the interpreter and yeah this this whole setup gives us a very very compact representation on the bytecode level
couple more things about javascript so it's it's written in pure c 99 so we really try to keep it that way and not use any new extensions just to make it as portable as possible so that as long as your platform has a see 99 compliant compiler that you can just build it and and it will work just fine it's code size right no the source code we are currently at 91 thousand lines of code so we're getting close to a hundred thousand lines of code there and the code size so the size of the JavaScript binary itself that is at 133 K right now on thumb 2 and this is with the full profile so the whole language standard if we we also offer a minimal profile where some of the features are dropped and then you can even get below 100 K and this number is important because that's essentially the amount of flesh that you need on the device to get there script running and it's also in a way the the overhead in terms of flash memory that you have to pay for using javascript versus a native c application one important thing to mention is that JavaScript really implements the full ACMA script 5.1 so not so we implement love that and we also have the corresponding test 262 results so this really works we passed the conformance test suite and the another thing is the our C API so if you have an existing application and you want to add some scripting capabilities to it then you can use the C API for that or the other way around if you have a JavaScript application and you want to invoke some native code then you can also do this through the C API and another feature is the bytecode snapshot feature so that one is allows you to essentially pre-compiled your JavaScript sources into the compact bytecode format and you could even just deploy the bytecode rather than even the sources and this has a couple of advantages so one of them is that you the whole process is a bit faster because you don't need to pass the code again you can do that offline essentially but that's usually not almost not even noticeable the difference the the other benefit is that you can if you pre compile the bytecode you can off load it into flash memory and this is very useful because if you have let's say you have some library code written in JavaScript that is not changing very often then you can just pre compile it to the compact bytecode and you can put it into flash memory and you can execute it directly from flash and that way you reduce the pressure of on the on the overall main main memory so yeah that's quite a nice feature and yeah portability so this is also very important so we try to be as portable as possible so JavaScript can run on all different platforms and ports and so the the engine is designed to be fully self-contained so we don't even have dependencies on the C standard library we have our own really small cisterna Larissa's really just some essential functions that we have in there and because of that you can also just run it bare metal you don't need any operating system or runtime support from the from the operating system and out of the box we support a couple of different BOTS so the first one that we supported was the stm32f4 but we have a couple more so for example the arena 101 that's an x86 base board inter contributed that port and maintains it and then we have also the freedom freedom bought from an XP and photon board so a bit more about that in a couple of slides and we also have an experimental port for the esp8266 and for in terms of real-time operating systems we have support for not x4z fear embed OS and riot and if you want you can run it on on a desktop operating system as well and it's particularly useful if you want for example you want to debug an issue in Jerry's trip then on the desktop you have usually better debugging capabilities than on this more microcontroller especially things like warrant or address sanitize if you want to track memory corruption box then it's much easier to do on the desktop then on the on the small devices yeah so just to get an idea what kind of hardware we're targeting so they the photon board is essentially 20 Wi-Fi enabled IOT board and that one has 100 and coax and free clocked at 120 megahertz has a megabyte of RAM and 128 K of when I go to flash one or 28k of ram so that on that board you can already do quite a lot with javascript so it won on 28 K you can run substantial amount of JavaScript so in the demo I also using the photon so I can show it to you there as well so yeah just to give you an idea of how memory it consumes in practice I want to show some slides about measurement results so this is the yeah should be readable I guess so for the so this is memory consumption for the SunSpider benchmark and we are comparing Jerry script versus duct tape duct tape is another open source light wide JavaScript engine so in a way it's a competitor to Jerry script and what you can see here is essentially so that the red bars are the memory consumption of duct tape the blue bars are the bars represent Jerry script memory consumption and you can see that we fairly consistently significantly below what duct tape consumes so that was not always the case like that but we spent pretty much the whole last year we spent a lot of optimization so we optimized for memory consumption and also performance you will see that next slide so yeah right now we are we are doing significantly better and it if you look at cases like this here the date format benchmark we are really easily in order of magnitude better and performance wise it looks quite similar it's the difference is not as big as on the memory consumption side but yeah there's even one benchmark here where we are pretty close but on average we're like two times faster than duct tape so you can see we spent a lot of time on that so demo so I have set up a small demo day and I'll just explain you a little bit what's what devices are there
so essentially it's multiplayer pong implementation so very classic game and we have two devices so we have the Raspberry Pi here and we have a photon board and each of them is connected to an LED matrix connected by I squared C so you can see that they're all ready and then we run so all of all of the code that's running is JavaScript and we on on the PI we run just Linux and then JavaScript on top of it and on the photon we run JavaScript on top of riots and we're using riot because for the communication we're using 6lowpan so riot has a very good stack for that and that's why we're going with riot here and and the other thing to mention is that each of the device can so it can be controlled by a human player that's why we have the keypad on the PI and switches on the on the photon but you can also run it in AI mode where the just the computer opponent is playing so yeah so maybe I'll just show it to you
if it still works yeah so now basically both devices in AI mode and you can see that this is the sort of AI is not perfect so sometimes what you guys wins and so this is a photon board so you can see it's really small the flashing LED means that whenever there's a 6lowpan packet being transferred the the LED gets toggled and since the board just has Wi-Fi built-in we have to use an 802 54 transceiver for the yeah for the communication and that one is just this is just a regular open labs 802 54 field so the same one that we're using on the on the PI and this one is just hooked up wire spi and that works actually quite well yeah it's just regular PI so maybe I'll just stop playing myself lost okay I need to practice more
yeah and you see so the ball essentially passes over the network and it's very smooth so obviously it since it's okay now I turn on the air mode again so obviously since it's 6lowpan is a lossy protocols or maybe not the perfect protocol for this kind of use case but it works quite well in practice actually and ya can play a little bit more yeah yep that's it very much for my thank you
so it looks like we have still seven minutes for questions yeah yes after your talk last year yeah vn I miss Peter we we tried okay I think we got to the point where it's we try to arrive second things we try to contribute very simple things like keeps a little bit of the readme things like that the request was like for a simple reading course it will change like I think it was three nines of changes was was horrible discussion one thing we and I think have we mentioned it in my talk this evening he was very frustrated about this merging process that got some kind of lengthy debated by musical employees of Samsung so yeah I think there is no problem with you our contribution policy I mean you know the simple simple example on how to run it so we don't create you too yeah yes I'll just repeat the questions so just the short summary he tried to contribute some small changes to Jerry script and it didn't work as smooth as expected so yeah essentially I guess that was still very much in the beginning of the year right so so we have improved a lot I think on on the overall contribution process and also how the things get merged and we I think at that time we didn't even have any contribution guidelines or anything so if you look at it now you can see that we actually have quite a good throughput and also the time between poor request being sent and getting much obviously depends on the size of the change but now I think if you would do the same again now probably will be merged in here in a day or two so oh yeah all right so the other question was that JavaScript didn't work on MIPS so that's pretty much still the case so no one has really I mean we haven't gotten really any interest in in MIPS specific ports so at least from Samsung side we're not working on that and also from community we haven't really seen any further steps in the direction but we would obviously be open to that so I wanted to Jerry Street and open the Realty for all the different architectures okay 97 yeah we don't really test on MIPS or even build yeah ok next question who was for I don't know maybe you've yeah we so the question was whether we did any memory consumption or performance measurements against the established desktop engines like v8 or spider monkey or JavaScript core and we have done some measurements a while ago on memory consumption and they are typically the minimum footprint you have is like eight megabyte so there's no way you can scale that down and performance wise I think we are at least I would say like a hundred times slower or something like that so on the desktop I would only recommend usage if performance is not your primary goal okay next [Music] yeah so so the question was that javascript is a lot about the ecosystem and the question is whether we it's easy for us to use existing code or like NPM packages things like that so we essentially we've been pretty much focusing on getting the engine to a level where it's competitive against the other engines out there and so on we we also have a framework called I Peter J's which essentially is like a light wired version of nodejs for for running on top of JavaScript but that's still so development last year was not really going strong so it's so I would say still kind of in the early stages but framework which is which is a bit more mature is Zephie ajs so internal developed basically or yeah jsapi for Sofia and they've been working got on that quite a lot last year so so that definitely works but I think there's still still kind of early days in terms of JavaScript frameworks targeted at really those low-end devices yeah okay one more minutes one minute forty yeah one more custom know that before so meet the questions what is what is exactly at the moment the community center is it like what is the governance process I am part of a foundation yeah okay so so the question was in terms of like governance of the project or how the project is organized and essentially so we just in September last year we moved our script over to the J's foundation so the Jazz foundation is it's also a relatively new foundation covering kind of all the different JavaScript projects and it came out of the jQuery foundation and in terms of governance we we have contributors from various different companies so Intel is a strong contributor the Naro pebble was a big use of JavaScript unfortunately they got acquired by Fitbit but they were actually using javascript already in production on their smartwatches so that was quite interesting but yeah in terms of governance we have we we're kind of growing and right now still a lot of the core maintainer czar employed by Samsung but we are slowly getting more appointing more people to from other companies and kind of diversifying the community and the D code I mean it's Apache 2.0 and it has been all the RP has been transferred to the J's foundation so this is not not really a Samsung project anymore okay okay I think we're done okay so yep sure yeah so the question is if there are any plans to work on es6 features so we actually have started already or not Samsung but people from Intel have contributed some some early es6 features already so we are certainly open to contributions in that area and and we've also been working on support for promises so yeah that's definitely something we are interested in and also the community seems to be quite interested in [Applause]
Loading...
Feedback

Timings

  530 ms - page object

Version

AV-Portal 3.21.3 (19e43a18c8aa08bcbdf3e35b975c18acb737c630)
hidden