Okay, let's get started. My name is Thakir. I'm an embedded platform engineer at Cisco Meraki and we are a cloud-based networking company based out of San Francisco. And I'm here to talk to you about migrating to Yachto and how you can migrate your build system over to Yachto. We as a company build a number of products that we sell, ranging from wireless access points to security appliances, layer two and layer three switches and security cameras. These products are built on a number of different hardware ranging from different CPU architectures to different SOC vendors that we use and a number of auxiliary chips like LTE modules and switching hardware. And we use a number of different kernels for these products ranging from 3.4 all the way up to 4.9. And for those of you wondering, these are actually the code names that Linux uses for their releases. Who comes up with these? Anyway, all these products are built out of a single repository we call router. This repository contains the main entry point, which is a make file to do all the builds. And this make file includes other product-specific make files and open-work make files and so on. This repository also contains all our kernel checkouts and all our user space apps and drivers and SDKs. Anything that goes into a build lives in this one large git repository. This legacy build system is built around an old checkout of open-work. And we have the single make file that I showed orchestrating the whole build. This make file is handwritten and that's never a good idea to do. It has 13 years of craft in it with people adding in all their changes however they want. And a typical build looks something like this. You specify the product you want to build for and you invoke make in that directory with that make file and it starts a build. So you might be wondering why am I here talking about Yachto? Why don't we just take the build system we have, improve it a bit, upgrade it and we'll be there, right? Well, to give an idea our open-work checkout is from 2006. And in the 13 years since then we have made a number of changes to this checkout of open-work. At the same time upstream Yachto has upstream open-work has continued to make their own changes to their own checkouts and we have diverged further and further from what upstream does. So at this point it's fairly difficult to pull in the new stuff they have been doing to pull in the improvements, fixes and so on into our build system if not impossible. Secondly, our legacy build system is very painful to use. Builds are super slow, like four hours for a clean build. And that's because of fun declared dependencies which means we have to build linearly. If you do not know whether package A can be built before package B, you cannot sort of penalize them for fears of race conditions and so on. And when we do a git pull it often breaks our builds because we might have left over artifacts in the source track trees and a package you depend on might not get rebuilt and so on. And this git clean thing is a real problem. Here are all the examples that I found in Slack where people have been suggesting git cleaning over and over. Here is me suggesting it. Here is my friend. Everyone suggests this every other day. All the way back to 2015 when we first started using Slack. Not only that, we also had an opportunity. We were working on a new product and because it's a new product we are going to get a lot of the testing for free. We are going to be testing things that are not even covered by automated tests, for example. And the vendor we were working with had good support on Yachto. So to summarize, we have a build system that's pretty unmaintainable at this point and it's slow. And we need something that's fast, more flexible, able to handle our complex use cases. So we thought, why not give Yachto a shot? It seems like a modern build system built on something called BitPake. And it seems like it's better equipped to handle our complex use cases. And it seems to have better vendor support. So we decided to do our first BitPake build. And we followed the Yachto Quick Start Guide to first check out some repositories that they suggest in the Quick Start Guide and then run these commands to do a build and run the image on KMU. And this only took about 10 minutes. And we already had an image that was able to get to the internet and run in KMU. And that was pretty nice. But we wanted to build our own image that is able to run on our own hardware, the new product that I was talking about. So we went again, went to the guides, which are pretty helpful, by the way, and decided the first thing we needed to do was add a new layer and a new distro and a new machine that maps to the hardware we were actually using for the new product. We then created a very minimal package group, which is just a collection of different packages that would help us get to the internet. And then we create an image that simply installs this group of packages and we get BitPaking again. This again just only takes about 10 minutes. And we already had something that was booting on real hardware. And this only took like a few days of work. And that was pretty nice to see that it's so easy and nice to work with. But, of course, it doesn't look much like our Meraki products, right? It doesn't have our proprietary stuff. It doesn't have our packet processing engine, all our packages. And the packages that are there might be configured differently, might be built differently. So they don't exactly work for us. So we decided the next thing to do is to port packages from our existing open world-based build system to our new build system. And what do I mean by that? Well, there are several packages that are missing in upstream Yachto. And that's because they might be proprietary, or maybe the community doesn't use them as often. And we also want to make sure that the recipes that are there are modified to our needs. And while we're in the migratory path, we also want to make sure that the delta between what our existing build system does and what our new build system does is kept to a minimum to avoid like confusing errors where it built from one, does something different or so on. But before I go into that, I want to give a quick crash course on BitPake for those of you who are not familiar with it. Starting with recipes. A recipe is a basic unit of input into a BitPake run. And it's a set of instructions that are passed by BitPake and then executed to produce something we call a package. And a recipe is written in the form of a BitPake file where it's something like the package name followed by an underscore followed by the version. And this version is passed into a variable called PV, short for package version. And that will be relevant in a little bit. We also have the concept of appends. And appends lets you modify an existing recipe without having to modify the existing recipe's BitPake file. That lets you keep your changes separate from upstream changes. And that's obviously very useful when you're trying to maintain things because you don't want to keep modifying upstream because mergers become a problem. Appends can be wildcarded. The second example where there's a percentage sign, that means that append applies to any version of the code recipe. They can also be version specific so the append only applies to that specific version of the recipe. And finally, we have layers. Layers let you sort of group recipes and modifications and classes into separate groups in a separate directory. So you can keep them contained and sort of define a logical group around them. So back to porting packages from open world to Yachto. What do I mean by that? Well, we want to make sure that the same sources are used, the same package versions are used. We also want to make sure the same patches are applied and the packages are configured the same way and compiled the same way. So what does that look like? Well, we have on the left the original recipe provided by upstream Yachto at a specific version, let's say 1.4.31. And what we do as the first step to modify this existing recipe is to create a BB append in our own layer. And then we set BV to this new value. I mentioned earlier that BV is passed out of the filename, but you can actually override it in an append. And even though the append is wildcarded, it's sort of like changing the version number. It seems a bit hacky, but it works for us. And we're kind of okay with it. We also have to update the checksums because we're using different sources. We want to make sure our Meraki specific patches are applied or any other patches we might have, like security fixes and so on. We want to make sure the same configure options are used and the same compiler flags are used. And this seems fairly straightforward, but not all the packages were this straightforward to port. Some were actually fairly tricky, requiring several patches to the upstream sources to make them work for our thing. We would enable some configure flag, and now we have to patch the thing to make it work in the Yachter thing. And some of the packages were actually missing, like I mentioned. And we had a lot of these packages to port, about 50 of them. And we just didn't have enough time because, as I mentioned earlier, we're working on bringing up a new product that we had to launch at a given deadline and so on. So we decided to recruit help. We organized the Yachter porting day. We created a jurapic, added all the recipes that needed porting to it. And we did some prep work, like making sure all the recipes are labeled easy, medium, or hard. So when people are picking, they can decide what level of comfort they're at with it. We also asked everyone to do a build the day before to speed up the build on the day off. And we sent our invites with promise of snacks and boba. That always works. On the day off, and actually, this is the highest resolution image I could find out of the recording. So excuse the potato recording, but on the day off, I gave everyone a tutorial of BitPake and showed them how to port a recipe. And I asked everyone to go and assign themselves a recipe to port so that we don't have multiple people working on the same recipe. We also asked everyone to use Slack so that if someone has seen a problem and solved it, maybe others can benefit from it too, rather than having to ask me and a couple of other people who need Yachter. And this turned out to be a huge success. We started at like around noon, and by the end of the day, we had 35 recipes ported out of the 50. And a lot of the difficult ones were ported too, which was pretty impressive. But I think most importantly, it helped get people on board. It helped them get a taste of Yachter and how it's fast and easy to work with. And that was really helpful in the long run. So as a tip, if you're working on some similar migration, doesn't have to be the build system, get people on board early, address their concerns, and it will also help you achieve your objectives faster, like it did ours. Also want to talk about how we extended Yachter for our needs at Meraki. Yachter might not have everything you want for exactly the use cases you have, but Yachter is super flexible. It lets you build things on top and it provides all the building blocks to build those features that you want for your specific use cases. Our specific use cases were building out of disk because we had that one large repository that people check out and build out of and make modifications to. And also enabling features and disabling features for a on a per product basis. And these are the two I'll go into, but there were several other things we added as well. So starting from building from disk, the first thing we tried was something called external source. To use it, you simply inherit this class, which basically gives you all the functionality implemented by this feature. And you set this variable to point to your sources. The problem, however, is this class makes it directly point to the sources on disk rather than copying the sources over into the Yachter staging directory. And what that does is if you have a broken package that, for example, creates artifacts in the source directory, you end up polluting your whole repository. And then you have to go clean again to produce a clean build. And then we're back to the get clean problem, which we really didn't want. It also cannot handle multiple sources, which we had to do for a few packages. And if anything changes, so let's say you change a C file, it will go configure again and compile again and so on. And that also isn't great. So to address the multiple source problem, we tried using source URI directly. Source URI lets you specify all the sources that go into your build, including patches. So we tried this. We tried the file type source URI, which lets you specify a path on local disk. But the annoying thing is we have to set S ourselves. It copies things over, but it doesn't change S to point to this new path. So it handles multiple sources, but there's this annoying thing of having to set S manually, which is where it builds out of. And it also doesn't address the problem of rebuilds if any of the sources change. So we wrote something we call morocchi source. It's very loosely based on external source. And to use it, you simply inherit morocchi source and you set morocchi sources to point to all the directories you want copied over. But more interestingly, you can specify patterns of files which this task tracks. So what you can do is say, hey, my configure task should only be rerun if any of the auto make files or any of the C make files change. Similarly for compilation, if any of the C and C++ files change, do rebuild. So if let's say you're working with a package, you only change a C file, you don't need to reconfigure. You can just go straight to compilation again unless any of the auto make files change or any of the make files change or something like that. So this clearly handles multiple sources because you can define as many sources as you want in morocchi sources. You can also, this also copy source is over. So it doesn't pollute the source track trace. And steps are only rerun if the set of files that are tracking changes. And this is all built using fundamental primitives that Yachto provides. We didn't build estate caching or file check sums or prefunks. These are all cool concepts provided by Yachto for you to build on top. And we should all take advantage of it if we have specific use cases. So that helped us do nice clean external form disk builds. And now I want to talk about picking and choosing features based on a specific product. Some of you might be familiar with machine features and distro features. And what that lets you do is say, hey, for my product or my distro or this image, I want PPP enabled or I want Bluetooth enabled or something like that. But of course our features were much different. We wanted, for example, LEDs enabled or we wanted the LTE drivers installed or something like that. So they didn't quite map. So we took inspiration from it and we wrote something called morocchi features. It's simply a global variable and you set to it in your machine config or wherever you want to set the value of it. And it lets you, for example, pick which packages you want to install or configure a package differently or something like that.  So, for example, we want the bird feature. And in your package group you can simply say, hey, if this bird feature is in morocchi features, install all the related dependencies. And we can do all sorts of cool things with it just like machine features and distro features. So far I've talked about all the things, all the places where Yachto really shines. Extensibility, flexibility, speed. But I also want to talk a bit more about room for improvement in Yachto. Of course there's always room for improvement, but I've picked two things I want to talk about specifically. And the first one is the problem of mismatched C library headers. Some of you might have seen this recipe called Linux Lib C headers. If you have ever wondered how the C library itself gets compiled, it starts with kernel sources itself. You essentially run make headers install on your kernel sources for a specific version, let's say kernel 4.1, Linux kernel 4.1. It spits out a bunch of headers that you then use for Lib C's own build. Then the C library gets built, spits out its own headers which are then used for an actual application that you might want to run on an actual machine. Our problem was we were building a different kernel, Linux 3.1.4, which was running on a machine and we wanted to run ETH tool on this specific machine. But the problem is ETH tool is one of those applications that talks directly to the kernel via the netlink API. There are several other such user space applications that need to know exactly how to talk to the kernel over iOcto's or anything like that. But this is currently not possible. And that is because of this disjoint view of build time and run time environment that it has. At build time it sees a header saying this is the API to talk to the kernel. At run time it tries to use it and maybe it's not the same. And the way I ran into it was I was doing my usual builds and this package started running on a machine. And there was this constant speed underscore 5,000, now undefined. So I did some digging through the Git history and I saw that a colleague of mine had made this change. She had added the use of speed 5,000 into the program, into the C++ file. So I did some more digging, see where it's defined and turns out she had actually patched the kernel. But this is all legit. She had actually patched the kernel 4 into 3.14. And this is totally legitimate. Even upstream kernel has this patch. So we simply are back porting the patch. But again, we just weren't able to compile because we wrote an application that was meant to run against this specific set of kernels that were either patched or were new enough to have this patch in it. But we just couldn't because of this disjoint view of the kernel. Our solution was to write our own recipe of Linux Lipsy headers. I know there's a big fat like 50 line comment in the open source Yachto Linux Lipsy headers recipe saying you must use this recipe and nothing else. But I think it's incorrect and we can talk about it if you want to talk about it later. So what we do is we write our own recipe which always matches the kernel and that way the compile time and run time view of the world is coherent. It's built against the exact same headers that the kernel is going to be built against.  On the left we have a version recipe at 4.1 let's say and it fetches those exact sources of the kernel. What we do is set pv ourselves and it always points to the version that the actual kernel being built is built out of. We also change s to point to the exact sources that the kernel is using itself. That way we know that there's literally no difference in the headers or in anything else that might go into the build. And the rest of the recipe is fairly similar except like a few minor caveats but the rest of the recipe is fairly similar. And this solved our problem even though it's a little bit hacky. So the lesson we learned from this exercise was some hacks are okay if they help you move forward and unblock here. But of course in the long run we would love to work with the community to actually find a middle ground where the community is happy other users of this recipe are happy and we are happy. I also want to talk a bit more about layers and how they can be so much more than they are today. I touched on BB layers earlier and how you can pick and choose layers using that variable. But what I did not mention is that layers cannot actually be programmatically selected. They're sort of statically built into this one file and I'll go into that a little bit. So let's say you have your open source yachter provided layers that you use if you're doing a build. Pretty much that's these layers. Then we have our Meraki specific layer. This contains all our modifications, all our recipes. And let's say we start a build for our particular machine. What we would have liked is for some way to conditionally programmatically insert a new layer for this specific machine. That way we could keep all the changes and modifications for this one machine in its own layer like keep it segregated, keep it clean. But as we know it's layers are selected through a variable called BB layers. And this lives inside a file called BBLayers.conf which lives inside the build directory. So every time you create a new build directory this file is sort of statically put in there and if you want to choose different set of layers you have to go modify this file. You cannot sort of like conditionally select BB layers because that's the thing we were really missing. Sure we could have written tooling around it but that seemed like even more hacky than it's worth and we talked to some people in the community and they seem to have run into problems trying to do that. So we stayed away from it. Similarly if you want to do a build for a different machine we would have liked a new set of layers to be picked for that particular build. But again this is not possible because you have to go modify this file before you can start the build. So if you're working with two machines you have to kind of go back and forth and take Meraki for example we're working with like 10 machines 15 machines and that becomes a real headache. But layers are still very useful. Everyone should use them as long as you don't have to switch them in and out often enough. So let's say we have our same set of layers. We use layers for something we call back ports layers. So we have our own set of layers the same set and the open source layers are checked out at version 2.5. And let's say they contain a recipe for curl at version 1.4.1 but we find a security vulnerability in 1.4.1 and we have to upgrade it as soon as possible to address the security vulnerability. So we decide we need to upgrade to 1.5 and we see that upstream Yachter the next version perhaps already has a recipe for 1.5. But we don't want to just blindly download that recipe and add it to our own layer because we'll end up with like these tons of recipes that we'll have duplicates for once we go to the next version anyway. So what we do is we create a new layer called the back ports 2.6 layer and this layer contains all the back ports from 2.6. That way the changes are kept in their own thing and we know where they came from. They came from the next version of Yachter. At some point of course we're going to upgrade our own Yachter to 2.6 and now we have two copies of this recipe but this is all totally fine because we can just simply get rid of the back ports layer and we have this single coherent view of the world again and it's basically a no op to remove that layer at that point and that sort of gives you a nice clean path to upgrade and your own checkout of Yachter without having to stick to the upstream releases and you can upgrade at your own cadence, you can decide when to upgrade and so on. All of this work that went into Yachter and all the people who helped with it led to a number of successes. The biggest one was of course the build times and this is a super exaggerated diagram or a chart but it actually gave us a 16x speed up over the existing build system. We went from literally 4 hours to 15 minutes and that's a huge gain in developer time. We no longer have to start a build and just go home, you know. So that's the real win for us. We save a lot of developer time, we save a lot of frustration around like waiting for builds and then if it fails you have to clean and start all over again. Most of our products are also now on Yachter and that means we gain more and more benefit from it as more and more products move to Yachter at Meraki. You might see this like sort of this jumps in the number of products ported and that's because let's say you have a certain class of products let's say our wireless access points. The first one might take a long time to port because you have to test it and think about all the base but after that all the other wireless access points are very similar to each other. So the next few just take you know like a week to port two or three at a time. So that's how we get this like sort of and that's an important thing to remember like if you're porting the first one will be difficult it will take a lot of time but the ones after will sort of come for free. And finally working with Yachter has been a pleasure it's super easy to maintain, super easy to upgrade and we don't have to write recipes often times by the time we need a recipe upstream Yachter already has a recipe for it and if we do write our recipes first upstream Yachter we like open sourcing them so that the community can take advantage of it. And I want to close with a few thoughts. I really can't stress enough how great Yachter has been to work with the community has really put a lot of thought into designing it making it flexible sort of giving us a general purpose build system and not just specific to one use case and that has helped us build a lot of features on top of Yachter and we would love to open source all those features there's nothing proprietary and we have taken a lot from the Yachter community and we would love to give back and while I'm here I also would like to propose a more of a modern RFC process rather than perhaps using mailing lists I'm not the biggest fan of mailing lists and something like what the Rust community uses like GitHub or GitLab or any other modern tool or platform I think it would really help drive input into new features that get design and get more participation from the corporate and the open source and the community and so on I also really want to stress how important it is to get people on board early it will help you achieve your objectives faster like I mentioned but it also helps reduce friction listen to what the people have to say in different sense show them that you care what they think otherwise by the time you introduce the change there will be a lot of friction and pushback and it's too much to deal with at once I want to close by thanking Ram who was the other main person who worked with me on Yachter to make it the reality it is at Meraki today and Matt Prokos at Meraki who did the initial proof of concept and helped us realize we can actually do it at Meraki of course everyone will help me prepare the presentation and the amazing Yachter community over the last year or so I have had a bunch of dumb questions to ask on the IRC and always met with good useful responses that I have been able to work with and also I want to thank everyone at the Yachter Dev Days last year who also answered a bunch of our dumb questions and helped us think through some of the problems we were facing and decided to present here this year if you want to reach me that's my email address you can also come find me if you see me and ask me any questions you might have and if anyone has questions I can take them now so using core image install also to decide which packages go into the thing right we did think about that but that feature specifically addresses what things get installed a lot of the times let's say we enable some feature we have to configure a number of packages differently we have to compile them differently we have to do all sorts of other things besides just installing a different set of packages so that's why we decided to use that good question yeah right so we did look into BSP layers quite a bit and that's exactly sort of the thing we want to do but I wasn't aware that they were dynamically selectable do you still have to go edit bblays.com to do that right so we looked into that the second option you mentioned but we sort of decided not to do that because we talked to some people at the yachter depth this last year and they had done something similar but they want huge fans of it so I would love to hear more about it and maybe we can actually fix that issue okay cool thank you I'll definitely look into that other questions so the new product we started working on was towards the end of 2017 we launched in 2018 and from then on we started porting all our existing products and today we are at 60-70% done right we were like we're going to launch the new product on yachter exclusively and then move everything over we haven't been working on it like full time but as we get time and resources we try to port them nothing really except resources and time we would we would love to start as soon as possible there's like we could make the Maraki source generic and let the community use it and stuff like that so definitely we want to contribute that's not in question but just you know the timing and resources to do it right so do you mean to ask if we were starting from scratch and we didn't already have existing products there's a tough question to ask or to answer rather because I mean if you have a very simple use case maybe build root would be fine for you if you don't like make files then maybe build root is not fine for you depends I think as you scale if you predict your number of products going up and your use case is kind of specializing go with something that's more you know complex and helps you deal with the complexity if you just only have one product and you are doing minimal modifications to upstream then and anything works really they're both equivalent in terms of you know build times and features and so on but just how flexible they are and whether you like make files I really don't like make files anything else thank you very much


So let's think about those tape diagrams and see how it can use them to solve algebraic problems. So the basic problem with algebra is to find an unknown number given some fact about it, given some factor set of facts about it. So for example I might want to find a number given that I know that x plus 11 equals 20. Or maybe I want to find a number given that I know that 15 minus y is equal to 8. Or again maybe I want to find the unknown number given that z minus 8 is equal to 12. And you might think for a minute, when you were first introduced to algebraic problems like this, once upon a time, really only about 150 years ago, these were college level problems. You didn't see algebra until you were in college and by college we are talking about places like Yale, Harvard, all of the major universities. College was the time that you first got introduced to algebraic problems like this. Well, more recently the algebra has been moving earlier and earlier in the curriculum. At one point it was a high school topic. Most of us were probably introduced to algebra in the middle school, but recent research shows that provided that children have an understanding of the basic concepts of arithmetic, and that means not that they know how to do arithmetic, but they actually understand what it is they're doing. If they have this basic understanding of arithmetic, you can start to introduce algebraic problems like this as early as the first or second grade. Now there's a proviso here. You can introduce problems like this. You can have them solve problems like this, but you can't teach them the same way that we were taught algebra by following a sequence of steps. That doesn't do any good. Instead the solutions to these rely on an understanding of the basic concepts of arithmetic. And a little bit of help here is going to be gained if we use a tape diagram. So let's consider that problem, x plus 11 equals 20. And we want to solve this problem using a tape diagram. Tape diagrams, the key to using them is to remember three things. Every time I write down an equation, so there's an equal sign, an equation is something equals something else. Every time I write down an equation, that corresponds to the idea that something and something else are the same thing. And with a tape diagram, what that means is that the equation is a claim that two tapes have the same length. Now those tapes are going to be the expressions on either side of the equal sign. And so sometimes I might only have one thing, so here's a 20. And on the other side I have this x plus 11. And the expression I have here, well, every term is then going to be some component of the tape. So here I have two terms x and 11. And the tape itself is going to be the result of the arithmetic operations in the expression that I have. So here I have some arithmetic operation that gives me a tape corresponding to x plus 11. I have a tape that has length 20. Let's go ahead and set that up. So again, my algebraic equation corresponds to two tapes of equal length. There they are. And one of my tapes has length 20. Again, one side of the equation is 20, so one of the tapes is length 20. And the other side is going to correspond to this expression x plus 11. So let's invoke our understanding of the basic concepts of arithmetic. When I add my set theoretic definition, my understanding of arithmetic is that I'm combining two things. And in this particular case, what I seem to be combining is a thing of length x and a thing of length 11. Now, since this x plus 11 has to be the same as 20, that means that this tape here has to be formed by putting together x and 11. So this remainder here has to be my 11. And so there's my tape diagram representation of the equation 20. 20 is equal to x plus 11. And at this point, it's logic. It's not even algebra. Well, we have to do a little bit of arithmetic. But the idea is I have this thing of length 20. And it's the same length as this. Now, I know this part's 11. So what's this part? Here's what I'm looking for. And so what I might do is I might remove 11 from both of these. It's gone. And this used to be 20. Well, this thing left over here must be 9. It's the same size as this piece over here. So that tells me that x and 9 have to be the same thing. And there's my solution to the algebra problem. And you'll note I didn't do anything with this equation that corresponds to what you might think about as the standard rules for algebra. I drew the tape diagram and I used a little bit of logic. Now, this is actually a good one to illustrate some of the advantages of this. So here's a problem 15 minus y equals 8. And this is a problem that most beginning algebra students at the middle school, high school, and college level actually struggle with because this is a problem. This is not an easy problem. And many people get this one wrong. But a second grader can do it if they understand what subtraction means. So let's go ahead and think about this is our tape diagram. So again, an equation can be represented by two tapes of equal length. And one of those tapes has length 8. And the other tape is going to correspond to 15 minus y. Well, let's think about that. 15 minus y. Well, when I'm subtracting, what I'm doing is I'm removing an amount from something else. So this 15 minus y sounds like I started with a tape of length 15. Well, if this is 8, 15's got to be bigger. I must have started with a bigger tape. And then I've removed a portion of length y. So I'm going to take my bigger tape. I'm going to hack off a section of length y. That's gone. And what's left is my 15 minus y. And again, there's an equality there. So that says the tape of length 8 has the same length as the tape of length 15 minus y right there. And again, same question as before. What did I take away? What did I remove here? Well, if I know this whole thing is 15 and this whole thing is 8, I can count up from 8 to 15 to figure out what's left. And so I can count up by 7. And that's going to take me to 8 plus 7, 15. And again, this 7 and this y are the same size. So that tells me that y is equal to 7. How about that third problem, z minus 8 equals 12. And again, we can represent our equation using two tapes of equal length. Let's go ahead and build that tape. This is z minus 8. So again, that's a subtraction. That is, we're removing some amount. And so maybe I'll start with a tape of length z. Don't know what it is. And then minus subtract a bit of length 8. So I'll hack that portion off. And here's my 8. Got rid of it. What's left over is z take away 8. And again, the tape diagram corresponds to the equality in length of two tapes. z minus 8, here it is. And 12 must be a tape of the same length. So I'll put that in there. And well, I want to find what z is. Well, I should be able to see that here, this whole thing, z, is tape of length 12 plus that last bit, tape of length 8. And so my entire tape, 12 plus 8, is going to be 20. And there's my solution.


Abstract CUNP2S6, CIPPS, is a promising material for applications such as ferroelectrics and thermoelectrics. SIPPS exhibits a large remnant polarization at ambient conditions, but this value decreases significantly when subjected to hydrostatic pressure. We investigated the effect of pressure on the structural and electronic properties of CIPPS and found that the initial decrease in polarization is caused by the suppression of the crystalline distortions of the Cucat ions. This is followed by a gradual increase in polarization due to the condensation of Cucat ions into the interlayer sites, which is further enhanced by the cell volume reduction. At higher pressures, the migration of Cucat ions to the center of the S octahedra causes a decrease in polarization. Our results provide insight into the mechanism behind the pressure-induced changes in the structural and electronic properties of CIPPS and suggest strategies to optimize its performance. This article was offered by Xiaodong Yao, Yinxin Bai, Cheng Jin, and others. We are article.tv, links in the description below.


Live from Orlando, Florida, it's theCUBE! Covering Enterprise Connect 2019, brought to you by 5ix9ine. Hello from Orlando, Lisa Martin with Stu Miniman. theCUBE, we are live day three at Enterprise Connect 2019. We have been in 5ix9ine's booth all week and we're very excited to welcome to the program for the first time Harry Mosley, the CIO of Zoom Video Communications. Harry, thank you so much for joining Stu and me on theCUBE today. Lisa, Stu, it's a pleasure to be here. Thank you for having me.  You have been inducted into the CIO magazine's Hall of Fame and recognized as one of the world's top 100 CIOs by Computer World. So we're in the presence of a VIP. Well, thank you for that. It's, as I say, it's all credit back to the wonderful people that have supported me throughout my career and I work with some amazing people and leaders and who have supported me in the visions that I've created for their organizations. And so it's, I understand it's about me but it's also about the great teams that I've worked with in my past. It's like, you can't make this stuff up. Yeah. Harry, we love talking to CIOs, especially one with such a distinguished career as yours because the role of CIO has gone through a lot of changes. IT has gone through a lot of changes.  Not just IT, the business, the relationship. Maybe give us a little bit of your viewpoint as to, you know, the role of the CIO and technology at a show like this, we hear about, you know, the CMO and the business and IT all working together. Yeah, so it's actually, in my opinion, it's never been a better time to be a CIO irrespective of the company you're in, whether it's a tech company like where I'm, you know, Zoom video communications or any of one of the prior companies I worked with, professional services, financial services. But even when you think about like trucking, you think about trucking as an industry, you think about trucking as a company, as like it was a very sort of brick and mortar, but now it's all about digital, right? A friend of mine runs a shipping container company and you know, the thing that they load five miles of wagons every day. And so I said to him, it was like how long does it take to load a wagon on a truck? It takes four minutes. You know what, Harry, we're working that down to three and that'll increase our revenue by 20, 25%. And so it's just fantastic. And the pace of change, you know, it's just growing exponentially. It's just fascinating. The things that we can actually do today, we only dreamed about them a year ago. You know, and you think about sort of, it's like, I can't wait to be back here next year. It's like, because it's like, we're just going to lift the roof off this place in terms of the capabilities. And so it's fantastic. Yeah, it's just absolutely fantastic. So looking at a lot of us know Zoom from video conferencing and different things like that, but you said something very interesting in your fireside chat this morning that I hadn't thought about. And that is when, you know, going from audio to video, when you're on a video chat, you really can't or shouldn't multitask. So in terms of capturing people's attention, enabling meetings to happen, maybe more on time, faster, more productive, I thought that was an interesting realization that you're right. It just clicks, it just works, you know, mobile. Hi, you know, when I go back to my, you know, sort of going back and again, thank you for the recognition from the keynote. But it's like when I go back in my earlier careers, like dialing that number, dialing that 10 digit number, mis-dialing that number, what happened? I got to hang up, I got to get a dial tone, I got to dial the numbers again. Now I'm like two minutes late. And it's like, you know, I know I'm late more often than I'd like, but when it's late because of something like that, that's frustrating. That's really frustrating. And so the notion that you can just click on your mobile device, you can click on your laptop, I have no stress anymore in joining meetings anywhere. I love telling the story about how I had a client meeting, I was in O'Hare Airport, and I joined the client prospect meeting, I joined the prospect meeting on my phone, using the free wifi service at O'Hare Airport, put up my virtual background on my phone, I just showed you that stew with their logo, shared the content off of my phone. 18 minutes into this 30 minutes call, that the person I was talking to, the CIO for this firm called a halt to the meeting. This is what exactly what happened. Enough, I've heard enough. Keep going. Enough, I was like, I didn't know what enough meant. And so I was like a little spooked by that, if you will. He goes, you're on a phone, you're in O'Hare Airport, you got a virtual background, you're sharing content, it's all flawless, it's like, this is an amazing experience that we can't get from all the technology investments we've done in this space for our company. So guys, enough, we're starting a proof of concept on Monday, no more discussion about it, how are you looking forward to being a business partner? It doesn't get better than that. It doesn't get better than that. It's like, you know, you hop through security, you get on a plane and it's like cruising all the way home. Yeah, I mean, Harry, I do have to say, disclaimer, we are Zoom customers, I'm actually a Zoom admin, and it's that simplicity that you've built into it, as the experience makes it easy. And then when you, and Stu, sorry to interrupt you, but I get really excited about this stuff, as you can tell, but it's like, then you look at the enterprise, so you're in, you get into the enterprise management portal, so like, Stu, I had a really bad experience.  Oh yeah, okay, where were you? You know, sort of, I was in outer Mongolia, okay, yeah, and about five minutes into the call, you had some packet losses, like, yeah, it wasn't, but it still maintains the connection, right? So you can access our enterprise management portal, it's awesome. Yeah, so that's actually where I was going with the question is, you know, I remember back, I actually, I worked for Lucent right after they spun out from AT&T and we had videos talking about pervasive video everywhere, in my home, in the business. It feels like we're almost there, but still even when I have a team get together, my folks that live in Silicon Valley, their connectivity's awful, you know, when they have there and it's like, oh well, my computer or my phone don't have the cycles to be able to run, maybe we have to turn off some of the video. Are we getting there? Will 5G solve some of these issues? Will the next generation of phones and computers keep up with it, because I'm sure you can guess, we're big fans of video, this is a lot of what we do, so what do you say? Well, the video is the new voice, right? It's like, we like video, why?   Again, it comes back to where were we a year ago, the capabilities we had, where will we be a year from today? Whether it's AI, whether it's the power in the device in front of us, whether it's the network, it's like 5G is becoming a reality, it's going to take some time to get there, but you've got sort of great technologies and capabilities that you look at the introduction of our real-time transcription services. I mean, how cool is that? I'm sure there's lots of questions, so lots of people would ask about that real-time transcription in terms of, well, what's next? I'm not going to talk about what's next, but as they say in life, watch the space. Yeah, just, you made some announcements at the show with some partners, I actually, I believe Otter AI is one of the ones you mentioned there, I got a demo of their thing, real-time, a little bit of AI built in there. Can you talk about some of those partnerships? Yeah, so we love our partnerships, right? Whether it's on the AI space with Apple and Siri and Amazon and Otter, we also love our partnerships with Crestron and Logitech and HP and Poly, of course. Again, it's the notion of we have terrific software. You guys realize that, right? It's terrific software, proprietary QoS, proprietary capabilities, just like it's a fantastic experience every time on our software. These partners have great technologies, too, but they're more on the hardware side. We are software engineers at our core. As Andreessen said, I think it was about 10 years ago, software is eating the world, so we are, you take terrific software, you embed it in terrific hardware with terrific partners, and what happens is you get exceptional experiences, and that's what we want to deliver to people. So it's not about the technology, it's about the people. It's about making people happy, making easy, taking stress off the table, you go to the meeting, you light it up, you share the content, you record it, you can watch it later, it's just terrific. So the people, the experience, as you talk about, we've been hearing that thematically for the last three days. As we know as consumers, the consumer behavior is driving so much of this change that has to happen for companies to not just digitally transform, but to be competitive. We're in five nines booth, and they mentioned they've got five billion minutes of recorded customer conversations. You guys can record, but it's not just about the recording of the voice and the video and the transcription, tell us about what you're doing to enable the context so that the data and the recordings have much more value. Yeah, so, I mean, it's the notion of being able to sort of rewind and replay. It's like, I'll give you really another example, if I may. Coming out of an office in Palo Alto, jumped in the Uber, going back to San Jose for a client meeting. I'm a New Yorker, as we talked about a few minutes ago, and I don't know the traffic patterns in Southern, you know, sort of in the valley. And it's about five o'clock, 5.15. San Jose meeting, 5.45. Normally, it would be fine, but it's rush hour. What do I know about rush hour? I know a lot more now than then. I realize I'm not going to be able to make it on time. Put up the client logo, virtual background on the phone in the Uber, client gets on the call, Harry, where are you? I'm in the back of an Uber. It's like, you know, again, the same sort of experience. Then he asks the question, well, you know, sort of with this recording capability, can I watch it at 35,000 feet? Of course you can. And it's like, that was the magic moment for this particular client because he said, I'm client-facing all the time. I don't get in time. I don't know where you meet my management meetings. So I won't have to ask my colleagues what happened and get their interpretation of the meeting. I can actually watch the meeting when I'm at 35,000 feet on a plane going to Europe. So that's what this is all about. All right. Well, Harry, obviously this space excites you a bunch. Can you bring us back a little bit? This brought you out of retirement and the space is changing so fast. We come a year from now. What kind of things do we think we'll be talking about and what's going to keep you excited going forward? So let's talk about the first part first and then sort of break it into two. So it's like, yes, I had a fantastic career and I retired. So when I met Eric and I met the leadership team at Zoom and I dug into the technology and understood sort of, A, the culture of the company which is amazing. When I understood the product capability and how this was built as video first and how we had this manical focus, if you will, on sort of being a software company at our core and how it was all about the people. That was sort of a very big part of my decision. So that was one. Two is, look, we have a labor shortage, right? You can't hire enough people. We can't hire the people. We have more jobs than we have people. And so sort of retaining talent is really important. So giving them the technology and the studies that have been done. If you make an investment in the technology that helps with retention, it helps with profit. It helps with sort of product innovation. So investment in the people. And then the ability to collaborate. It's very hard to work if you don't collaborate, right? It's like it just makes it really very sort of lumpy, if you will. So the ability to collaborate locally, nationally and globally. And people say, well, what's collaborating locally? It's kind of like we can just walk down the corridor. Yeah, well, if you're in two different buildings, how do you get there? And it gives us a foot of snow between you. It's like makes it really hot. So collaborating locally, nationally and globally is super important. So you put all that together.  Retirement, we're just going to put a pause button on that and we're going to have some fun over here. And it really has been. So over a year now, it's been absolutely amazing. So, yes, big advances, what's in the future? I think the future, it's like, you know, there's been a lot of discussion around sort of AI. We hear that, it's like all the time. And we've seen from a variety of different providers this week in terms of their thoughts around how they're going to leverage AI. It's not about the technology. It's about the user experience. And you look at sort of the things that we started to do. We talked about real-time transcriptions a few moments ago. You look at the partnership that we have with LinkedIn where you can hover over the name and the LinkedIn profile pops up. You're going to see this, I just see this as sort of exponential change in these abilities because it's like you have these building blocks today that you can grow on an exponential basis. So, the world as our oyster is how I fundamentally think about it and the art of the possible is now possible. And so, I think the future is going to be absolutely amazing. I mean, who would have thought a year ago you could get on a plane using facial recognition? Let me just throw that out there. I mean, that's pretty amazing. Who would have thought a year ago that when you rent a car, you can just look at the camera on the way out and you're approved to go? Who would have thought that? So, with that speed, I'm curious to get your take on how Zoom is facilitating adoption. You mentioned some great customer examples where your engagement with them via Zoom Video Conference basically sold the POC in and of itself with you at an airport. That's a great question. I guess O'Hare has pretty good Wi-Fi. What's that? O'Hare has pretty good Wi-Fi. A little choppy, but it worked. It worked. Because of our great software, yeah. There you go. But in terms of adoption, so as customers understand, all right, our consumers are so demanding, we have to be able to react and facilitate collaboration internally and externally. How, what are some of the tools and the techniques that Zoom delivers to enable those guys and go, I get it, I'm going to use it and I'm actually going to actually use it successfully? This is a question. I don't know how many clients, CIOs, CTOs, C-Suite execs I talk to. And they all ask me similar sorts of questions, like, we're not a video first culture. We're not, it's like video, it's kind of like we're a phone culture. And then I, so I throw that right back at them and I say, and why is that? Because we don't have a good video platform, aha. Now, when you have good video, when it just works, when it's easy, when it's seamless, when it's platform agnostic, iOS, Android, Mac, Windows, Linux, VDI, web, when you have this sort of platform, when you're agnostic to the platform and it's a consistent, high quality experience, you use it. So it's the notion of these, it's the notion of, would we rather get into a room and would we rather get into a room and sort of have a face-to-face meeting? Absolutely. So why would you get on a call and not like to see the people you're talking to? You like to see the people, why? Because it's a video first. Unless it's just one of those meetings that's on my calendar and I didn't want to be there and I'm not going to listen. But I totally agree with you, Harry. So another hot button topic that I think we're at the center of here and that I'm sure you have an opinion on, remote workers. So we've watched some really big companies, I think really got back in the dialogue a couple of years ago when Yahoo was like, okay, everybody's got to come in and work for us and we've seen some very large public companies that said you need to be in your workforce. And as I said, I'm sure you've got some pretty strong opinions on this. I don't know what's going on here quite honestly, Stu, but it's like, I think you're reading my brain because it's like these are things I love talking about. So yeah, it's, sorry, repeat the question? Remote workers. Remote workers, yeah. So first of all, I was at an event recently and we talked about remote work. We didn't like the term. It's a distributed workforce. Because if you say you're a remote worker, it's kind of like that doesn't give you that warm feeling of being part of the organization. So we said we should drop calling people remote workers and we should call them a distributed workforce. So that's one. Two is, I'm in New York. I'm in Orlando. I'm in Chicago. I'm in Atlanta. I'm in Denver. I'm on planes. I'm in Uber. I don't feel disconnected at all. Why? Because I can see my colleagues and it's immersive. They share content with me. I'm walking down Park Avenue and I've got my phone and it's like they're sharing content and I'm zooming in and I can see them and I can hear them and I give me feedback and I'm marking up on my phone as like as I'm walking. So I don't feel, and then when I go to, it's fascinating. And then I go to San Jose and I'm walking around the office and I'm seeing people like physically. It doesn't feel like I haven't seen them. It's like, you know, it's really funny. It's like, I was in San Jose last week, Wednesday and Thursday in San Jose. Took the red eye back. Hate the red eye, but it's like, I don't like flying during the day. I just think it's inefficient to waste the time. Took the red eye back. Now I'm on calls Friday morning from my office at home with my green screen zoom background and everybody's like, I'm talking to the same people I was talking to yesterday but they were in the flesh. Now they're on video. It's like, Harry, where are you? Why didn't you come to the room? Well, I'm back in New York. It's just, you know, it's just that simple. Yeah. That's simple and really it sounds like Harry, what Zim is delivering is a cultural transformation for some of these newer or older companies who there is no reason not to be a video culture. We thank you so much for taking some time to stop by theCUBE and chat with Stu and me about all of the exciting things that brought you back into tech. And I'm excited to dial up how I'm using Zoom. We can take five minutes after this and I can show you some cool tricks. Wow, from the CIO himself, Harry Mosley. Thank you so much for your time. Thank you. Great to have you on the program. For Stu Miniman, I'm Lisa Martin and you're watching theCUBE.


Hello everybody. Good morning. All of you are excited for having a nice, wonderful day today. My name is Satyam. I've been working at Little I Labs. We build performance analysis tools for Android apps. I've been working on this tool since around last one and a half year. And I've been learning about Dalvik in the year I am to just share some of my learnings today with you. Just a small change in that name. It is supposed to be deep dive, but I won't do a deep dive, I'll just do a shallow dive. I don't want to make you uncomfortable. I wanted to make it a little easier. This is a quick slide, a small slide about the Android system architecture. If you look at it, these are all various parts of Android. So you would see that I highlighted the Dalvik one. The Dalvik one is like, otherwise I thought it would be a little difficult to search and find it. So there it is, just a small piece on many other things that are there. However, one thing to just kind of note it is the one that which runs your Android apps. So in a way, that is very important. Nevertheless, the others are also important. The Dalvik has been kind of designed to work with all the other parts as such and taking considerations about the complete Android motivation itself. The Android has been, if you look at it, the complete Android system has been designed, taking some of the constraints as follows. One of them is the memory. So it has to run with devices which has very low RAM. They didn't want to make use of any swap space, too. So they're supposed to work with the low memory. And CPU, they're supposed to work at low-end CPUs. And more importantly, it should be consuming much lesser battery. So these are the design constraints that Dalvik has been kind of based in. And we'll try to look at many of those things, how Dalvik has addressed many of these factors while we speak. If you look at it, what does the Dalvik VM really does? It is actually just like a JVM. Or in fact, maybe I'll just get in there a little bit. But you write your source code in Java. So that gets converted into Java bytecode. And that gets converted into Dalvik bytecode. And this Dalvik bytecode is the one that runs on Dalvik VM. The Dalvik VM just runs your Dalvik bytecode. Now, what does the Dalvik VM does? Yes, it works like the JVM itself. It loads the text files. And it has to interpret all those bytecodes and execute them on the hardware. And it also might have to do, just in time, compile some of this bytecode directly into the hardware code. And apart from this, it also just does some manages your memory, too. So before that, so we can actually just look at, start with trying to look at the Dalvik VM when it has to really load the text file. It needs to define a format on how the text file is. So Dalvik has tried to design even the files from the starting from how the file will be structured as, and when it's loaded, trying to optimize in terms of memory and all those things. So if you just look at this figure, so you can see that like all other files, it has an header. And then it's followed by string IDs. The string IDs are any strings that you use in your class source code. Everything will be part of the string IDs.  So that is also hello world is a string. That's how print a line. The methods are also strings. And the class names are strings, and all those things. Then that is followed by type IDs. Type IDs, any type references you do. Not only those type declarations that you do in your classes, but all the type references that you do in your classes. Also information about all those type IDs are there. And then prototype for prototypes. It is a prototype of all the methods that you use, the method signatures, and the field IDs, fields. Method IDs actually have a reference to the prototypes apart from trying to tell the type and the method name, et cetera, and the class definitions and the data. In fact, though all these are there, all of these, this is probably the correct figure in a way. See that all the references jump from here and there, everywhere, right? So basically, if you look at the type IDs, type ID will not really store the complete string. It will just tell that, hey, this type, the name of the type is the string ID. And the string ID would tell, OK, this string, whatever is being referenced, is actually in data. So everything is actually really speaking in data. These are all the real indexes. Everything are there in all other fields. So this is kind of meant to avoid many of the duplicacies. So if I look at it, if I go back and try to connect with Java as such, that is being that Talvik has been trying to follow with Java, trying to connect with Java a little bit. In Java, if you look at it, all the JAR files that which we generally build consist of many class files. And all the class files exist as it is in the JAR file. They are not kind of compressed. So if you look at it, this, sorry, it's a little harder. But if you can see on the left side, all the class files are there. Each class file has constant pools. And then the red, OK, thanks, OK, if I look at it. So here is the data. And these are the constant pools for all the classes. And if you look in the DEX file, DEX file is now kind of all the class files are combined, everything, into one particular file as such. So all the constant pools that are kind of separated separately are combined from all the class files into one file as such. And all the data has been filed in this. So just illustrate with a little example. So let's take a small example. So we have an interface. And we have this class plot. And then we have another class, JAPR. So there are three classes. One of them kind of implements the other one. The other one just uses the other class. And see how it looks like, for example, in a JAR file. The JAR file, if you see the number of strings that are there, you look at the class, JAPR. You would see that the strings, the JAPR, is there. The method signatures are there. And if you look at Bloat, the similar method signatures are there. And even the strings, again, JAPR and JAPR are there. So there's a lot of duplicacy of the strings. So if you look in the text file, this is how it looks. Well, it doesn't look so clean here. All references jumping here and around. But if you look at it, there's no duplicacy at all. So the file has been kind of compressed as if that there will be no more duplicacies. All strings point to only one particular string as such. All method IDs, everything will point out to the same thing. Prototypes, if there is a signature which is similar to another method, it will share the same signature, trying to kind of squeeze on every byte that it can really make it. So that's why the text file is kind of little compressed. So if you look at it, if I just try to compare the dot text versus the dot jar file, though it is actually just a, in terms of size, it is 50% of uncompressed jar files are printed. That's what I've been reading across. So though the jar file compressed is lesser, and so in a way, the shipping size may be a little different. But at the same time, when you load into the memory, it's probably when you expand your class files and all those things, it will, again, blow up. So in a way, the text uses lesser memory. But one thing that you need to really keep in mind is that a jar file, if it's a jar file, your class will be really loaded, or in fact, will be found only when you really use it. If you don't use it, it will never be created at all. So but in the text, it will be actually loaded. It will be there in the memory, though the class object will not be created, but it will be there in the memory. So if you kind of avoid really using any class files which you think are not necessary, avoid using it. Well, it doesn't save too much memory, because the class object is not created and all those things. So in a way, it doesn't really differ much. But yeah, you may just get some extra bytes free. Now, but there is also an advantage of using the textile, which I'll try to talk about right now. And before that, I just want to explain a little bit in the general if you go back with the process memory usage. If you just go back the way that things used to happen in the Windows or the UX worlds with your native applications there, but in the Java applications. So there, if you look at the shared libraries and the dynamic libraries, so many of the processes use Lipsy or the user sys.tll in the Windows side or Lipsy in the Windows unique side. So all applications use it. So now the way that they worked out on the operating system is that they try to share the text section of all these libraries on the memory. So basically, if program A on the program two, both of them load Lipsy, the Lipsy will be mapped into the process in the virtual memory, but in the real physical memory, it will be there, both of them will be sharing the same text size. So this is one thing that Java itself is actually missing. You have your class files, and if you're running multiple JVMs on your machine, there is actually not really a good way of sharing those text files. So in physical memory, they can just be shared, right? And it will just reduce your RAM uses of your application or your complete system as such, because there's nothing really different as such. So Android has kind of tried to solve this problem using this way of decks, as well as other things that I'm trying to go ahead. So one of them thing is the zygode, zygode, right? So zygode is a process that they kind of created when it kind of boots up. It is actually, if you look at it on your Android devices, there is slash system slash bin slash app process, if you look at it. It is the one that which really starts the zygode. If you just look at it, you know how to really start the zygode process as such. It comes up during the boot process. It loads all the framework classes and everything and it just waits for the socket request so that when any other app request comes onto that socket, it just forks this application. When you fork this application, it is easier for the operating system to create that application very fast. It's just how to just go and mark all the pages that this process has been able to read or write for the new processes. If it is text section, they'll be only read and for the data sections, what happened is they marked it something called copy on write. The copy on write does mean that if you are really trying to write into the data pages the other new process, then it'll actually create a separate page and continue. The same will happen for the existing process. So in that way, the launch of the application will be faster as at the same time, you can actually share the pages also. So this is one main reason that the zygode has gone. It just kind of illustrated a little bit about the application launched on the zygode. This is what happens, right? So when you kind of click your application in the beginning, it kind of gets us, sorry, I think it is a little unreadable, sorry for that. So you just click your application, so it kind of goes to the launcher. The launcher takes it, calls the activity manager that so on site activity needs to be launched and it sees if that is in memory or not. If it's in memory, it just kind of loads it back or otherwise it sends a message to zygode. Zygode in turn will create a process, return back the PID to this guy and the zygode then will just invoke the activity thread of the algorithm to get started with which will internally just load the classes and will get started. So this is how zygode will actually really start their application such. Now to get back to our other one that which we are talking about, the memory part. Just excuse me one minute. As I was saying, right? So on the Java side, we are not really sharing the classes. You're, now because the zygode is the one which gets started in the beginning and whenever any app that gets created, it just folks application. Now you get, not only get those pages, you also share those text reasons. You also share those data reasons or for example, all the text structures that gets created, you just share them. So though, you will be using up some virtual memory of your process as such, but at the same time, you'll not be occupying an extra physical memory on your application, on your system. Anyway, so your RAM is kind of protected. It's okay that your process will take probably more memory. If you actually look at mat, don't do anything, you just launch the application, you bring up mat, you'll see a 10 MB or something assigned to your process. That is just because it is coming from the zygode. It is getting all that memory kind of assigned to your app space. But so if you just look at it, right? So I'll just try, I will try to explain to you maybe in the next session, next slide. So this is kind of the various parts of the memory of an application as such. So starting with PSS. So PSS you can call is a proportional set size of your application as such. So where there is some pages kind of share, get shared across various apps. And now you have your own apps. So the one that which are kind of shared are called shared and those which are only for you are called private pages. And again, there is like different between shared and private. The shared has two modes. One of them is dirty, clean, private, dirty, clean. So the dirties are those which, for example, if you get modified or if you throw it out from memory, you can't restore them back. But if it is the clean, those are the one which can be restored back. The restored backs are simple like this text files, right? Because they are really stored in the files. If they throw that pages from the RAM, you can load them back from the files onto the RAM. And so those are clean. So they don't, so they can be thrown away so they are lesser in weight. But the dirty things should not be thrown away otherwise your app will not be working. Okay, so now using your apps, the proportional set size is calculated for all your processes such that it looks at all your private files. And the shared prices, it will look at how many apps has really been using it and just divide by N. And so that is the PSS that it kind of attributes to all your processes. So the advantage of these processes, I mean the PSS is very useful for the Android is that it uses this to figure out which service it should kind of actually knock out. Okay, if it thinks that it's running low on RAM, it will try to first remove all your cash processes. Then it will actually try to look at all the services or any bank row and apps that are running which has higher PSS, it'll try to first kill them. It'll rank out in various cases and it'll start killing all those processes to be able to make the foreground application or the priority processes do their tasks. So the PSS is the why, this is the reason why PSS is very important. And then comes the shared dirty. If you look at it, then there are two parts, the native and Dalvik. So just to kind of differentiate, the native is not the native apps that we talk about or the HTML apps. The native is that which uses the process memory as such, the one which is not really the Dalvik. When the Dalvik VM runs, it actually has two kind of heaps. One heap is to run the Dalvik heap is the one which all your applications run in it. So your applications, the Java code, the Java code that is allocated and everything runs as part of Java heap. And the code that which your shared libraries or any other things that really get created or itself, the memory of Dalvik VM itself, everything is actually goes into the native memory as such. That's how the native memory and Dalvik memory are kind of separated. And so if you just do ADP shell dumps is meminfo and just give the PID, you'll get all this information and you can use this information to actually look at the memory uses of your application at any point of time. So just move into the next talk. So the text after it loads these files, the one thing it has to do is it has to interpret the byte code. So to define the byte code, let's see how the byte code of the Dalvik looks like. I'll just not go deeper enough but I'll just go quick example. If you look at it, this is the Java code. This Java code does nothing. It just adds up the sum of the given array and just written soaps. Actually I should have written some very mistake. But otherwise, this is a quick, this is how the byte code looks like or the Dalvik byte code looks like. Just to kind of touch upon small, small things here, here the Dalvik byte code uses the restermation which is kind of a little different from Java byte code. I'll just touch upon that. And all instructions are like 16 bytes. And if you kind of go back to your microprocessor, whatever you learn with x86 in all those places, right? So you would see them, all the instructions are mostly loads, stores, add, and all those kind of instructions. Here the byte code actually doesn't, well they have such kind of similar outputs but otherwise they have different kind of, a little higher level of outputs too. Look at, for example, array length, right? So it is array length is one of the byte code wherein the byte code actually will map it to figure out that particular variable and kind of tries to run it. Just to run through you, maybe here it runs, the Dalvik byte code kind of assumes there are like infinity number of registers like what the traditional compiler does. They know that how many registers are there and they have to fix it for you, fix it for them. But here it doesn't have to be born with. The runtime interpretation will take care about all those things. But otherwise, here it assumes there are infinite number of registers and it will just try to allocate the message. The arguments that are passed are actually the last variables. If you look at it, the v3 here is the, sorry, v3 here is the one argument that is kind of passed to this method as such and this is how kind of it looks like. I'll just touch up on a little bit more later. And if you can just try to compare with the Java byte code itself, right? The Java byte code actually uses the stack machine. The stack machines would not really take any operators. If you go back and look at Dalvik one, all the operators are actually given as an arguments, right? But if you come back here, all the operators are assumed to be on the top of the stack. So some of the operators can be actually those variable names, local variable names and all those things. But by default, they are assumed to be on the stack and they operate. And if you try to compare the number of instructions for the same function, okay? It is just as how many instructions? 32, 46, or the number of bytes are 16, 22, and here I believe it is 23. The number of effective byte size is, this is little, just one more than that. But at the same time, if you look at it, the number of instructions are more. And this is simple, but that one actually, the Dalvik actually generates into this byte code, which is almost like how many of our machines are, all of machines are actually resturbaged machines. So it becomes easier to really translate them if you use a resturbation. And that's one reason why Dalvik has gone with the resturbation as such, okay? So to kind of just summarize about the Dalvik byte code, it uses a register machine, assumes unlimited number of registers. All instructions are 16-bit instructions, well, some of the operators can actually overflow to be the next set, okay? And the registers are assumed to be 32-bit size. And if you need to use 64-bits, it uses both the consecutive registers as such, and N arguments are in the N last registers as such, okay? For all the instance methods for the Java classes and all those things, which are non-static, right? One of the first argument will be this. So that will be also be one of those arguments as such. So moving across, so, well, I'm not touching about how it really interprets. It can just take that code, find out the relevant code and just execute that, okay? So, but now let me move towards verification. The one thing that the Java class loader does it, when you load your class, it actually needs to verify that the class is actually following the proper syntax. Is it like all the string IDs that we are talking about a few minutes back, right? All of them are in proper range or not. And many other cases, whether the classes defined are, actually, it can just load all its dependencies also. And it also needs to find out whether those classes are valid and it doesn't really crash the stack machine. So similarly, the Dalvik VM also has to do this verification for all these classes. But over the Android as such, kind of has a little more control than what a Java can do, the JVM can do, right? So basically it can control your installation. It controls, it knows when you install your app or et cetera. So when you install your app, it immediately takes the control and it tries to verify right then itself. It tries to verify during, just at the installation time itself. And there is this tool that's called Xopt. It's the one which actually really verifies and also does optimizations also, okay? And after it verifies, there is one folder that it calls Android data, data Dalvik cache. It tries to keep all those text files there. And to verify it, first it loads all the class files to verify. It actually just looks at your framework jars and et cetera to resolve all the classes and verifies that. And if it could not verify any class, if it could not find some class or if it finds something illegal, it just marks a flag in that particular class file telling that, hey, I could not verify this. This probably is not verified so that it probably will give an error at a runtime because during install time, it should not give a error message to the user at such time. When that class file is really used, okay? Note when this class is used, it's not the complete text, right? When this class is really used, then it's when it actually will throw an error at a runtime when you are really using that app. It doesn't do it during the install time, okay? So, text apart from doing the verification, it also does optimization. So that some of the optimizations can happen at the time itself rather than later. So one thing that you can probably ask is why can't I really optimize them during on my system itself? Why do I need to do it during install time? Here, the optimization that it really does are a little different, which probably cannot be, which can be actually platform dependent. So one of them is actually the bytes. So Dalvik assumes all the instructions, everything, all the data here in little Indian, okay? So many of the processors right now actually really allow both little Indian as well as big Indian, but there may be some processors which are strictly big Indian. So for if Dalvik is kind of putted on those processors, right? They ask to be swapped. The bytes have to be swapped. So it does those. There's one platform dependent. The other thing it also does is it also tries to inline some functions depending upon the platform. So some of the things it can inline some methods and it can also optimize some of the methods that it would figure out which are going into the framework jar and or et cetera. It can actually directly use the V table to really directly reference into them, okay? To just go back to an example of the inlining. This is a quick example of how we can inline, right? For example, some of the methods which are very used widely, like string.length or string.equals, right? That this, at the top, you see what your normal class file is. It just calls invoke virtual. Invoke virtual is a bytecode to tell, execute this particular function, okay? Here it's trying to tell execute string.length. And the next line you see is a one. Actually if you see slash data, Dalvik cache slash data, you would find this particular class file which will actually contain the optimized text file. It's actually called ODEX. And if you look at that, so that one actually has a line, execute inline, okay? So it also has some offset which tells this offset is for string.length. So this probably can be changing changed across various platforms. So that's the reason so it kind of does an optimizations on the platform itself. So one thing that it has to happen, for example, many of you would have got update for Android 4.4, right? So now when Android 4.4 gets downloaded, all this files, cache files need to be regenerated. So it will take a little while to actually install. So after this downloads, it has to go back and load all this, it has to keep your original class files or original text files and it has to run them again. The text art will just run all of those files again and generate once again, all this optimized text files flushing the cache. So your original text file also should be left even after you have this new files. So the next thing that the Dalif VM should be also doing is, should be probably doing just in time compilation to avoid interpretation every time. It was introduced with Android 2.2 actually. So before that or even after that also, if you have a very ICPU bound application, it is better that you write your application in SQL. That's because you will avoid those interpretations moving back and forth and all those things. That's what it's recommended. But to kind of reduce that usage, it's better to do some kind of a just in time compilation. So Android has introduced just in time with Android 2.2 and the goals that they add for like it has to become effectively. If you look on the Java on the server side or on your desktop and generally your applications there will be running for your time. So it's okay that it actually takes a while to warm up and then it starts trying to look at the caches, see which one it should really optimize and then continue. But here the applications that may be running, it has to just get optimized very quickly. So it has to start really, it cannot wait for warm up basically. And the memory is a constraint. It should not be using too much memory and of course they should not be constantly doing. They should be very careful in how much is really compiled into the native program as such. So when they decided, when they were trying to look at which JIT they should be using, they came out with, these are the two traditional JITs that are apparently used much. One of them is the trace method and the other one is the method JIT. In the method JIT is actually much simpler in a way is that you have your code and it'll just see the methods which are executed heavily and it will just compile for those methods. And if you look at it in this figure, the first box is showing you the full program parts. Those yellow pieces are the methods that which are really used. And if you just optimize them, you'll be using this much memory. Only you'll be really just in time. So that's what they kind of put it across is like only 10% of the code actually really excludes a lot. And then the next thing is you can just, doing a method JIT is very simple. It's just actually a method boundaries. You just need to find out and you do just sit for the particular methods. But one of the disadvantage is the method JIT as is that the complete flow in the, all the flows in the method are not really excluded every time, right? Because there may be some if-else ports which will never get excluded. So we are unnecessarily sometimes probably just doing JIT code for those codes which are never getting executed. So the trace JIT actually takes advantage of that. It will actually really just in time compile at the basic block levels. Or as n number of basic blocks, they can just do just on that rather than the complete method. So trying to reduce the instructions that which we do just in JIT or at the same time by just reducing that your cache will be less, your memory requirements will be less and the CPU that you spend cycles on trying to just do just in time compile will also reduce. So and if you look at in this figure, it tells that just 2% of the program is actually can be, is really generally optimized in this particular case. Just to have a quick flow about all the trace JIT works, when your application is actually running, it actually just updates a profile count for that location as such. When it reaches a threshold, it'll actually just look at whether that particular code is actually the translation for that already exists or not. If it just exists, it'll just use a translation. If it doesn't exist, it'll actually go, the interpreter will actually go and look at each byte code and see until when it probably can give it to the compiler thread to really exclude. Basically trying to see if the code is getting complex. Let me stop here kind of those things. It'll just try to figure out that and it'll give it to the compiler thread. And if you look at the number of threads that your application is running through DDMS or whatever, right? So you can actually see that there'll be one particular thread called compiler, which is actually occasionally doing just in time comparison. So when this gives a notice to the compiler thread to go and optimize, it'll try to take those pieces and it'll try to compile them and put them in a translation cache. The translation cache apparently is very small. They used to have just something like 200K or so. So less. And now once the code is translated, any exit points that are gone, that exit points will be bound back to the interpreter or if that translation for that other basic block also exists, it will be actually bound to that so that it doesn't have to use one of them. The small, small optimizations to make the most out of the just in time compilation. Okay, but is that enough? So but still there is a cost to the interpretation. It has to interpret every time. There's a cost. You optimize a little bit, but still there's a limit to that. So with Android 4.4, Android is kind of introduced or tried to preview with something called ART, the Android Run Time. It's what they call. So if you have got an update for 4.4, you can try it out in developer options. You can go and tell, we can just tell, include ART and just, it'll probably use those things I didn't try it out. But the way that I understand is that when you install, it'll do compilation at that point of time. It'll compile into almost nitty code at that time. So effectively the interpretation, the just in time, and all those things may not be necessary if you just do that. Well, so one question that you probably can be asking is that, hey, why can't I generate my executable directly on my desktop itself? Why should it do something here? So by just doing it at a system level, it can actually take advantage of the CPU that your current system is using. For example, if we, at little labs, actually have a nitty code as such, and we wanted to use one library, which heavily uses on the thumb instructions of ARM, we could not use it just because the Galaxy Y, the ARM chip that comes with Galaxy Y doesn't support the thumb instructions. So we could not really know. One thing for me to do is that either I support multiple shell libraries, I build for all of those, and depending upon the system, I load that, or otherwise don't take advantage of the thumb instructions. So to reduce the pain, currently, I'm not using the thumb instructions. But if I just outsource my job to somebody else, that would be better. And I can't keep multiple versions of my shell libraries and all those things. That will be painful for me to maintain. So by now pushing it to the runtime or to the install time, Dalvik is trying to give away, throw away your work from there, and they know, because they know the, they can know which Android processor it is, and they can optimize it better for that particular, and for that particular ARM chip or whatever chip it is. So that is the advantages that you can actually go when you move towards the Android runtime. So that's what happens at the just on time compilation and the runtime. Now, the other thing that what Android, okay, so I think I'll just finish. The memory is one main part that is the other thing that what Android Dalvik really manages. So just to, if you actually look at your locket, there are two main important things that really part. One of them is the GC concurrent and one of them is the GC for malloc. Before Android 2.3, they used to do only GC for mallocs, okay, wherein it just stops the complete world. If your memory are not regularly, but yeah, regularly it stops the complete, all the suspense, all the threads, and tries to garbage collector memory. With Android 2.3, they changed a little mode, wherein they call it this concurrent mode, what that will, which will just suspend for a few minutes, just do a marking and then it'll do a small sweeping, then again it'll try to lock, try to make sure that everything is fine and it'll kind of save and then it'll free the memory and it'll go. So it does almost everything, but it tries to stop the rest of the world only less time. However, at the time, if the memory allocation fails at the time and if the GC for concurrent is happening, the memory allocation will actually stop and will actually you'll see in the lock at, wait for, waiting for a concurrent allocation to finish kind of those messages, you'll be seeing those things. So you can just look at the lock at to figure out. So if you see at the last seconds, it is you have the time, okay, the pause times here, here is the pause time for this one. You have to just have a look at this to figure out how much pause time your application is kind of taking. So these are some of the references that you can go. I can probably share with you if you have anything and do you have time for questions? Okay, so any questions? Hi, my name is Garima. Hi. So I have a question for you. So what is the difference between using a jar file for library and referencing a library as, I mean referencing as a library project? Add the Dalek library. Okay, I'm trying to understand the hybrid application you're talking about is the HM. So if we are including external libraries, right? We can either include a jar file in our project, right? Or we can reference another project as a library project. So how, how are we going to do this? So all this jar files get converted into DEX as such, okay, even your hybrid programs will be just running those files in DEX and it'll just run them. The Dalvik doesn't know whether it is an hybrid or non-hybrid. It will just knows as DEX code and it'll just try to exclude them as such, okay? This is Saravanan. I said.  Okay. How does the Dalvik VM, you know, takes advantage of the multi-code? Okay, so the Android OS actually takes care of the multi-code places. The Dalvik just kind of tries to interpret it and it will just try to see that the number of reads, right, collisions, and all those things happen properly and all those things. But at the same time, I don't think it does anything special for it. It doesn't have to worry about it. I think it's the OS which will really take care of it. Thank you. This is Parkeer. Yeah. So my question is, how does it resolve conflicts between different jar files and different versions? Different jar files have different versions. So does it, I see classes? So yes, really speaking, the text will assume that there is only one class for, there is only one class for a particular complete seven name. It doesn't really allow two things to happen. So when you compile it, it will figure out in the class path which one comes first, and it will include only that particular class file in the text file. It doesn't include all the classes. This is a counter question here. So basically, so it'll just figure out which one is in the first in the class path that it can find, right? If there are two particular ones, it'll just figure out the first one. It will not. When you build, this happens during the build time itself, right? It's not at the run time, okay? But when the DX, which builds all your jar files and combines into a text file, that time itself, it'll actually look at, it'll figure out the class file which it really thinks is proper and which it finds first on the class path. We'll try to use that. So I think that in some cases, it'll find multiple text errors when there are similar names. I think maybe sometimes it'll use those warnings. Sometimes it can just choose not to use everything else and try to figure out. Hi, this is Ajay. With the introduction of ART, there is no interpreted code anymore, right? So it's all ahead of time combined. Yes. So it's a sunset for Dalvik or it's like... So I'll put this right. So Dalvik is doing kind of around three things, right? It is also doing the memory management for you, right? So the memory management, somebody should just be doing that. So such kind of components will still be there part of the head of compilation, sorry. It'll be there, still be there part of the ART as such. The memory garbage collection and everything will be there. So you can assume that the interpretation piece or the just-in-time compilation pieces, both of them probably may not be there, but there'll be some other pieces that which would probably still be there in Dalvik. In the run time library, which will be there. Can we say that ART... Which one? So I won't talk, ART will be part of the Dalvik VM. I think both of them will be probably be separate. It'll be, but still the various other pieces that what we discussed today, right? The text files and all those things will still continue. But at the same time, the interpretation and the just-in-time compilation will probably not be there. Hi. And it is still in preview. So I think they're just kind of testing to make sure that everything is fine. But yeah, maybe the next version will probably, they'll probably make that one preference to the Dalvik. Hello. Hi. Hi. With the introduction of ART, what implications does it have for garbage collection? Can we expect the pauses to be more deterministic or maybe take less time? I don't think there should be much difference in either way. I think it should be the same. I'm not expecting it to be different. Guys, just a couple of questions. That's it. I'll add, see, I'm in the cinema. Yeah. I'm from Hyderabad. I'll add the question what this question has asked about ART.  But according to the discussion what, for that question, ART is just a complement to Dalvik. Okay. Is it just a complement where it works in sync with Dalvik or does ART has really huge advantage in real-time scenario? Yeah, it has an advantage, right? It will try to, no longer interpretation will be necessary. So your applications probably will be faster a little bit. That's fine. But your installation time will be slower, but I think that's okay for people. Then in that case, will Zygote initiate the... The Zygote will still continue, right? So one of the issues that would be they need, they can just share this, all this code and everything. So it may just note the class files, but it'll be there so that your launch time will be faster. Yeah, absolutely. So will Zygote call Dalvik or will Zygote will let ART? Zygote will be using ART. Thanks. How will the Dalvik take advantage of the processor on which it is running? Because every processor has some special instructions, like maybe SIMD or maybe doing fast multiplication and all those stuff. How does Dalvik handle this? So the Dalvik is, you can actually, the Dalvik and every time you're on your Android machine, you build Dalvik depending upon the processor architecture, right? So it knows about how the processor architecture is. So it knows if it has to take advantage of the SIMD architectures or et cetera, depending upon the processor there, it will take advantage of them. So the code is almost similar, except there'll be some if-debs or whatever necessary, but at the same time, if the processor has SIMD, it will take advantage of them. Kind of. Yeah, hi, I'm Karan. With ART, you know, with ART, you can actually read the dot OAT files as opposed to the previous dot ODEX files. And I've heard that Android also includes OAT to ODEX converter. So like, do you think how, like using this, how will backward compatibility with previous apps be, you know, that can be managed? So I think it should be backward compatible. I don't think there should be any issues with the LBART being non-Dalvik, non-backward compatible. If you look at it, so the, so really speaking, Dalvik VM, what it does is it really executes the text code, right? The text code, if you look at the text byte code, I don't think it has changed a lot in the last few years. It can just run the whole code also, right? So ART should be able to run the new world code also, and I don't think that should be an issue. Okay? So there's a, at 12.30, there's a speaker console there. Like, I'll be there in that room. If you just take out and you take left, I'll be there in that room. If you have any further questions, you can meet me there. Okay? Thank you very much. Have a nice conference. Thank you.


Moqarba from Saminat Telecommunication Council, greetings to all of you. Connecting the other 50% is doable, achievable, great charge. Digitisation is very central to our future plan and progress for the future will depend on efficient collaboration and cooperation building mechanism. Policies that foster investment and innovation, social economy growth and regulatory framework that will enable private sector to be more engaged on most of those fronts will prove to be very critical for obtaining the results we aspire to achieve as a group. The Broadband Commission has a significant role in that regard to play and in conclusion I anticipate a bright future across most of these various areas and our collective endeavour within the industry and digital society. I wish the Commissioner much success and thanks for most of the leaders whose contribution are continually powering new ideas across the globe. Thank you very much.