I would like to propose that we move to our interest speakers, and put this at a high time. We have a good discussion, but we move on to the main discussion now and to address the specific points that Paul has raised in the context of that wider discussion. I think that it might make sense as we address what works and what is missing to maybe divide it into the population variation and then the patient variation associated with benntyn. is it associated with phenotype, and maybe if we start with population variation. I think it would be good to get a sense of people's satisfaction with what's available in terms of population variation, both in terms of single nucleotide variants, but also actually all forms of genetic variation. Is it in the form that is dense as people would like? Is it in the form that people would like? Has it come associated with the annotations that people would like? I'm sure Steve would be very interested in what's the single thing that you would like to see that isn't there. So I just want to add an informatics comment that the NHLBI exome variant server that's hosted out of the University of Washington on the Seattle Seeks webpage has 5,200 exomes available for people to look at, to look for their variants. Nass. Hi, I'm Nass Rahman from the Institute of Cancer Research. Yes, sort of going on from that and this question of the things that we often think is known and robust but actually isn't. One of the things that I think often doesn't get talked about but I think is very important is that aspect of actually the annotation of what the actual variation is. So we increasingly talk about that it's going to be easy to detect these variants but what do we do about them? But actually the calling of those variants, the annotation of that variant says are really, really big problems. I'm sure anyone who's been doing exomes will see deciding which transcript to use, deciding how you're going to call it and then if you're historically going to try and get things out of the databases there's been quite a lot of changes in how we've defined those clinically which reference we've used so that if you look historically for a number of genes you'll see the same mutation called different things and that's obviously going to impede our ability to maximise the use of that information. I think there's been quite a lot of movement to try and standardise that and often that's with relevance relation to the genomic reference and I can see that that's probably the way it has to go but what it does mean is that you end up with very, very long strings like RS numbers that are impossible to keep in your mind in a clinical way so a mutation that you may feel quite comfortable about now it's some seven digit number and you can't remember it but I think this is a really important problem that if we can try and standardise now we're actually going to annotate variations that we're going to need if we're going to clinically interpret them. Just to follow up that point, is the HGVS nomenclature a comfortable system as an alternative to RS numbers? I mean it does give you some transcript contact. I mean yes, I mean I think, well in some ways I mean clinically I think most of us use that, that has changed a lot of things in that has changed over the years and I think there are a number of ways in which that doesn't naturally integrate very well with a genomic based system and I think there needs to be a coming together that will allow and it's not automatable in a way sometimes I think that one would want for a simplified system on genomics I'm sure a lot of people have different views about it but it's a problem and deciding what the gene is obviously is a problem. So what degree does the LRG initiative that Paul mentioned address some of the concerns that you have about that? I'm not sure. Paul, do you want to just, I mean because I sent some over out there. The goal of the initiative is to create a stable reference sequence that's something that is not changing, not versioned, is not an ensemble transcript, a RefSeq transcript, something that over time may have been reported in a way that in fact doesn't map to today's reporting and gives the ability to report from one version of the human genome assembly to another as that changes and collect information that exists in the genome coordinates and put it back into a smaller set of locus coordinates. As I said, this is an informatics solution. It largely does solve these informatics problems, but there are I think still challenges to adoption. Howard? So I've actually got two points to make now. One is in direct response to this that while I think it would be great to have a single reference sequence to find it and be done. I'll report on a conference that NHLBI hosted a couple of months ago where we discussed the same issue and the general consensus of that group was that while it would be ideal to have a single, never-changing reference, the realistic solution or thought process is with evolving technology, with ever-increasing knowledge, that may be utopian and it may require that references be date and time-stand, methods of sequence generation be annotated so that as things inevitably evolve, it's possible to go back and look at what it was compared to. A reference standard is critical, but it probably is in the real world going to have to evolve. The other point that I would make, which kind of follows on that and the previous part of the discussion, is that thinking as a clinician, I don't really care if it's an RS number or if it's C677T or if it's the word thermal label MTHFR. What I need to know is how do I translate from one language to another? So one of the databases that I think is missing is something that very easily lets me move from one to the next so that no matter what a patient comes to me with or someone else comes to me with, I can say, oh, that foreign language that you're using translates to this language that I'm familiar with, and then I can go out and figure out what to do with it. I think that that's where the... I'm so glad to hear that you're working on standardized vocabulary and structured language and this sort of thing and obviously with you and with NHLBI both working on this, that goes a long way to create the functionality at the user side to be able to navigate more seamlessly because in my vision, the report comes into the electronic health record. There's an interpretation with the length that, again, the clinician doesn't need to understand the language but can click on that link to get to where they need to go to understand how to use it. So my question is, obviously you're two big players in developing the standardized vocabulary and structured representation. Are there major players that contribute to these types of databases who aren't a part of that effort to develop a structured vocabulary and so what do you think we would need to do to bring them in so that we can all be working off the same page? So I think in general, and it's... I think it shows both the importance of the problem but there's also an unfortunate nature to it that there are, for almost every big player, there's an effort to create some standardized something. This actually shouldn't probably be a surprise but we certainly have worked closely with a number of different groups and we continue to do so. The collaboration between EBI and NCBI I think adds weight and a center of gravity to things that makes it more difficult to ignore but for us to be effective, we do have to...  It might be useful but it will be more useful if we are properly integrated in the right communities to do this. I think I can speak for Donna, she may want to speak for herself. We have made a number of efforts to contact these groups and we are working closely with them and be they groups such as local specific databases, people who work with diagnostic and run diagnostic labs, people who are also trying to aggregate information for use in clinical interpretation. So as co-chair, I'm going to from time to time just kind of pull out something that I at least think might be an important action item to take forward and it seems to me that this would be something where we would need to explore the role that perhaps NSG or I could play as a convener to bring the different people around the table because we definitely don't want to be in a VHS, Betamax situation and let the market decide. I think that you're absolutely right. We need to get the right people around the table so that we can do it and make sure that we don't have a sort of a balkanisation of this whole process. So before we kind of move away from the discussion of population variation and get into the possibly thornier issues of the clinical information. So now it's people's opportunity to give their wish list to Stephen Paul. So are there any burning desires of what people want to see from population variation resources? Bruce Blumberg, Kaiser Permanente. I want to follow up on a point that Mark made earlier that is that we're not all from Wisconsin. We need a database that will be just as relevant for underserved populations as for the people who've had their genome studied so far. And stating the obvious when I look around the room, the people in this room aren't very representative of the population of the United States either. So we really need to be careful to provide a database that's relevant to all populations, not just white upper middle class populations. So I guess one point I'd like to make relating to that is that we saw Les show that a frequency of one and a half percent I think was the cut-off used. Now it's one thing to study a population and be confident that you've discovered all the one and a half percent variants. It's another thing to be confident that you've got the frequency right so that when you say it's one and a half percent variant, it is actually one and a half percent variant. And I think that's something that needs consideration is actually the depth to which we go within each population to be able to make those statements carefully. Just on those reference populations, people have been talking about the reference genome. The reference genome actually now isn't just a single version because capturing variants is one thing, but there are regions where there are completely alternative alleles in the population and the reference genome is beginning to capture that in the form of patches right now. So ultimately maybe it has to become a whole graph structure and that's what you should be doing your analysis on. But the individual point variants, but there's also this internal structure of the reference which people should be aware of. Steve, last word on the population variation. Well, there's another dimension to this that DB SNP has struggled with. There's a tension between trying to be ecumenical for all variation and then realizing that some people are interested strictly in germline variation and others are interested in somatic variation, both of which could be benign and just neutral polymorphism. That comes up in sequencing. Right now we're trying to put all of it in DB step, but clearly partition it so that you can get through the downloads, the things that are germline, the things that are somatic coming in. I'm just wondering from a group like this is that the right approach, are there other categories? We're going to face this again with epigenetics and marks coming in. Is there thinking about how we want the repositories to accumulate these data, separate resources, one place to go but clearly identified, just some feedback on that would be helpful for planning. One point on population databases, one of the challenges we have is we look toward databases like DB SNP for what the control population is, but in fact a lot of the populations from which that data came are diseased populations and when you dive into that data it's very, very difficult to figure out where it came from, whether it was part of a disease cohort or whether it was part of a true control cohort which in and of itself is challenging because sometimes these are younger individuals when you're trying to study a late onset disease and that's very challenging. Ways to have a little better description of what those populations are from which this large scale data sets are being submitted would be extremely useful. Another minor point in using DB SNP particular RS numbers are not variance their locations and so we have numerous examples of both a pathogenic and a benign variant mapping to the same RS number because it's a location with both a C to an A being pathogenic and a C to a T being benign and makes it very, very difficult to decipher what's in there so on the population level those are some of my wish list. Along those lines it's pretty easy for me to have an RS number to go into DB SNP and find the information I want and they can confirm, you know, in the HGVS nomenclature with it but my analysis programs don't work that way. They give me the HGVS nomenclature and I can get to the RS number but it takes me about three or four clicks to get it in one click so even though yes I need a translation between the two as Howard was saying I'd really like just to work out of one nomenclature. Right, so we move on to the variation to attach to phenotype so I want to just raise one kind of very high level point just to gauge people's views on it is we've been talking about clinically actionable variants rather than clinically actionable collections of variants or clinically actionable genomes we've been talking about very variant by variant approach does it concern people that we're not taking a genome perspective we're taking a variant perspective? Howard? So, yeah, duh. Wait, there's more. What I would love to see of course we need the research to tie together one sequence variant with 10, 50, 100 other sequence variants but at the next scale up we need to tie that into epigenomic variation microbiome variation the next cool thing is going to go I forgot copy number variation whatever the next cool genomic or proteomic thing will be but that's still not enough we have to tie that to environmental variation let's not call it the viral gnome please but as far as database construction assuming for the moment that we can snap our fingers on all that data exists what I would love to see is smart informatics people build these discrete databases in such a way that they all speak to each other seamlessly behind the scenes that I don't have to look at and I can build my own search clinically or my own resource clinically that says show me the sequence variants and the microbiome variants among smokers and just let me put it all together and tell me what I want to know and cross reference all of that so that if I want to drill down and get all the way back to the primary literature so I can go back like I said was that a reliable study that it was based on before I came up to the clinical action information I can do what if I want and if I just want to get the answer and go I can do that too so maybe by next week lots of nodding heads when I mentioned the question though Howard McLeod from University of North Carolina I would strongly encourage us to not build one database I think that we're trying to build something that fit is purpose built for a bunch of different purposes and I think that was called the UGO and it didn't work very well but even the Hummer is no longer in production so we can have multiple databases that just have to interact with each other there are multiple ways of translating from Italian to English none of it makes sense but it's still there are those ways so I think we need to get away from one we're talking about variability and we're trying to build one size fits all and it's okay to have something that's geared towards clinical application and something that's geared towards genomic science and as long as we are thoughtful on how we build it So you don't know what to do but to build on that I think that's a really important point for the meeting as a whole is that the purpose as I see it is not to try and create the database because that will be doomed to failure particularly since we don't know where 90% of the heritability currently lies It's something like that we're in the same boat as a physicist who somehow misplaced 95% of the universe but I think the issues that are salient what I would like to see come away from the meeting are an identification of we know what we currently have in terms of resources where are the big hairy gaps that we don't have and of those big hairy gaps which are the ones that would be most appropriate for NHGRI to take some ownership on to say we need to fill that gap and which are the ones where we'd say this is an important gap but this probably would fall better to this group to be able to do it with the underlying assumption that there will be the ability to aggregate then I think that's something that Kent is going to be talking about a fair amount in his talk about how that type of multiple database integration system will work I also think it's important to think about how this is ultimately likely to be used I mean if this is going to be used in as I suspect it will be electronic health records which are increasingly more and more commercial products it's going to have to be done in a way that there is a place that these commercial EHR vendors can point their software at and on a regular basis get feeds so it's not going to be a clinician going and looking in a database it's going to be a clinician looking in electronic health record where the electronic health record system has taken that data in and through some magical process that we all still need to think about has presented them with the information they need to see so it's really a big step to go from being able to look in ensemble and actually get a regular data feed into an electronic health record system that a vendor is going to use Rex I agree with you but I think I also hear around the room that we still need or there's a reason to develop some sort of common resource that has sort of the common clinically actionable variance to date that could be useful for the clinician that does need access to the EHR Andrew Andrew because you have to build that anyway the underpinnings for any of these pipelines actually ensemble Paul mentioned this predictor thing which already is a service that is there on top of Andrew Johnson NHLBI in terms of thinking about areas not currently covered I think it was alluded to in one talk that phasing is something that maybe not well captured and could be important at least for some genes so I've been interested to hear from Paul or Steve or others in terms of thinking in a forward perspective genome sequences may allow us to to phase variance over long distances but then that's going to be harder to store in the databases and require a different framework So I could just quick reply I mean what we're doing now is looking at genotypes as a high throughput deliverable magnitude larger than SNPs because it's the product of every one type of genome but coming in with these data are phase information and so we are looking towards storing it as haplotypes as it has been doing data reduction on that dimension where it's delivered 1,000 genomes is probably the leading project doing this and it's a little easier than in a clinical context looking with deep population samples so I don't think the methods are there yet but trying to get the infrastructure worked out and how we would exchange that information as the necessary next step and then I think we can piggyback clinical linkage interpretation on whatever we've worked out for the big population projects Bill, can I ask, I like the way this conversation is going because I think it is going to be a network of networks, we have to understand that we're going to be using modern network technology just like the finance industry does just like the entertainment industry does well, I don't know I can put all my financial records into mint.com and I can get some pretty sophisticated analysis out and just two other relationships to that one let's please not make be dependent on EMRs EMRs are undergoing massive consolidation I'm not sure that the ones that exist now will exist 10 years from now they are not nimble, they are not flexible to do this. What they will be is one source of information that we will have primary source of information that we can combine with other sources and I don't think it's too early to put one other resource on the table that hasn't been put on and that's the citizen of the United States citizen of the United States is increasingly going to own, control and distribute their information and they're going to do that with genomes. Genome wide scanning is going to be on people's Facebook pages to exploit the fact that people have time opportunity to be able to do this sites like Ancestry.com have 26 million family histories that people have invested time to collect and and to date from various sources. There is enormous potential out there, they are a resource Do you have a proposal how that potential can be captured? Sure, you take the capabilities of an Ancestry.com and you begin to transition into medical histories they're interested in Ancestry DNA and ethnicity DNA which is going to be important but who knows more about their epigenic, their environmental exposures than the individual does that individual can anandate their individual thing and most people are altruistic they would like that information to be used in an aggregate source to advance research so there is an agent out there that can help us build one component of this network of networks that has the time and interest and it's most important for them to be able to do it so I think we have to look outside our traditional scientific spectrum to say not just to criticize these people who are saying they are offering DNA tests direct to the public but saying okay who of those are people that we might be able to work with in the future to be able to take this thing forward in a better and faster fashion I wanted to make two comments really in some aspect of practicality too so I was really struck by the contrast Howard got up and said clinician wants it hard fast and now and then Paul gave a talk and I just thought gosh I can see why his wife screams at him because I once said I'm joking but I'm being tongue cheap you actually said using the command line you can customize this in a really simple way okay that was a real contrast because it was exactly not what the clinician was asking for so what I wanted to ask you is I know who your audience has been or who your client base has been up until now but what I just really wanted to ask in a really practical way is is EBI beginning to rethink what its client base would be and would some of those clients start to be more clinicians and genetics clinical labs as distinct from very much on the research side and if so what initiatives are happening around that and then before your answer just to make the other point which I think picks up on your point I think we need to remember today that causation and prediction are two completely different things they have some overlaps but they are not entirely overlapping and so one of the challenges will be that was yeah we can look at variant by variant and think about causation actually what's more challenging to think about is that it's not just in racks alluded to you know what of it you do score from 33 variants or whatever but actually your entire GWAS print out could be a predictive tool itself at that level and that poses a whole other set of challenges but how you might present how you might collate on that information do you see what I mean you're right the top bullet on the the final slide that I had we are not and we do not want to be and we are not marketing ourselves to be a clinical decision support tool I believe that we should be in the next level down so the people who want to build those interfaces for the clinicians should find in us basically that what was just described the place that they can point their resources at to get updated information on a regular basis now I think at the EBI so I'll put it very strongly if after 20 years of collecting the world's biomolecular data this data turns out to be useless if we are planning human health we will have really screwed up and so we are interested in making our resources absolutely as useful for interpretation and healthcare approaches but to be honest I think there's probably two MDs out of 500 people at the EBI and neither one of them are practicing and so our role is deeper in the infrastructure generally we want to make better connections so that we can provide that when people ask for things we're giving them the types of answers that they want it was kind of the point made about the genome as a graph I don't even want to consider the genome as a graph and I'm certain the clinicians don't but somebody has to make this work and that's got to be deeply buried in the system that's very helpful question for the back way comment Gail Herman clinical geneticist nationwide children's hospital and I think this is going to only work as good as the clinical phenotyping that goes into it if we want to look at clinical utility and so how to address to get as much clinical information that's accurate that's updateable if you start with kids they're going to get older and they're going to have new problems and you want to incorporate that and I really like the idea over there of having people put in their own information it may not all be accurate but it's probably going to be as accurate as a lot of the information you'll get from other sources I think clinicians are going to need to educate people maybe about how to put information clinical information into these databases but I think the clinical labs know that when you have a detailed form maybe one in ten times you get the information you ask for so you can't go back from the lab data to the clinical phenotyping that you like very often so that really is a big question about phenotyping which might be something that we want to we just want to have in the last couple of minutes voices that we've not heard from thank you very much my name is John Parkinson I'm from the UK and I have the privilege of running a million EHR database and soon will be a 52 million EHR database and I just request from a comment made a while ago that we don't generalise about EMRs I call them EHRs and throw them all away there are some very good ones out there and I think we need to respect that I think you disagree um we could disagree perhaps we should talk about it okay any last final comments that people wanted to have a few briefly one or two sentences okay so basically I got nervous when something I said in my talk about phase that I need to know if this mutation and this mutation in the same gene are on different chromosomes to then a discussion about haplotype blocks and I think that's my concern about what I'm trying to do in the clinical to what you know people are trying to do at a genome level the haplotype of blocks unless these two variants on the same chromosome a long ways away actually contribute to the phenotype I don't really care about it so I just it's like it jumped from here to here and I'm in the clinical lab I need to be you know I'm I need to know more than I mean I need to be able to dig down more than what Howard was saying that his clinicians want a you know two minute thing I'm the one having to go in and do that but I can't go from here to there and sift through all of that data so I need to be able to do it not in two minutes but within 30 minutes you know and get it so it really made me a little nervous to see how a simple little phrase jumped and all of a sudden got to the point that I couldn't do you two other comments there we go I just wanted to not taking the sides on the EMR discussion I think the broader perspective is that we have to be open to the idea of non-traditional ways to access data and I agree with Bill in the sense that we've had some discussions with Ancestry.com about incorporating family history data along with the family structure I think that as we look at some of the information about where is the missing heritability it seems like at least some of it may be an idea where SNPs that are probably family specific so understanding family structures at a genealogic level is probably going to be important and so thinking about that type of information the phenotyping information is critically important and I think patients can probably supply some of that but that is a role I think where electronic data warehouses that are generated through EMRs if we can figure out a way to get the data out can also enhance for no other reason than to do validation of patient enter data but I think that we can't I would agree with Bill in the sense that we can't lock ourselves into thinking that the way we've always done medicine is going to be sustainable in the future it's going to have to be more distributed and so we need to be able to create a innovation space that allows us to test out different ways to do it and see what works and what doesn't I think we're going to have to leave it there because some of us are fueled by caffeine and we don't have very long to consume it now so so so thank you very much for the discussion and we'll return at 5 minutes past 11 I believe


Only 9% people already had a product management title for the first job. 91% of people do not even have product management experience, but they all became a product manager. And these following 10 different backgrounds successful transition into product management. They are. What's your background? You can make it happen as well. Hit the like button and comment in the description.


In this video, we provide the solution to question number 12 for the practice exam number three for math 1060 We're given a triangle ABC and we're asked to solve for that triangle The information we know is that the angle measure of a is 45 degrees The length of side B is one inch and the length of side C is the square root of two inches Which is about 1.4, but it's better to have the exact value there so notice that we have a Side angle side situation, so the law of cosines of the very appropriate tool for us We know angle a we can use the law of cosines to find the length of side length a right there So that's how we're going to proceed So the law of cosines tells us that a squared plus B squared or sorry a squared equals B squared plus C squared minus 2 BC cosine of a so we don't know what little a is so we're gonna fill out the right-hand side here Little B is one so we get one squared little C is the square root of two. We're gonna square that which is helpful We're gonna get two times one times the square root of two then times that by the cosine of 45 degrees for which one squared is one the square root of two squared is two Which is why it's better to have the exact value there two times one times square of two is two times the square root of two And we do are allowed to calculate here, but 45 degrees. That's one of our special angles That's gonna be root two over two For which then we're gonna continue to simplify this thing one plus two is three we're gonna have a Square root of two times the square root of two that's a two and then these two's cancel out like so So you end up with a minus two so in the end we end up with a one for that So a squared is equal to one taking the square root We get that little a is equal to positive one inch like so so that we see that's gonna equal one right there That helps us out a lot here because if this side is one and this side is one that actually means we have any We have an assosceles triangle The this Angle opposite side is corresponding to this angle opposite side they're equal that actually tells us very quickly that we have 45 degrees If you're not satisfied with that quick use of the assosceles triangle theorem We can use the law of sines to help us out here sine b over little b is equal to sine a over little a Right this would then of course tell us that sine of b is equal to b over a times sine of a Which b over a we both know those are one one over one times sine of a That is 45 degrees for which that would simplify to give us root two over two When is sine of b equal to root two over two you can consult your calculator But you're gonna end up of course with b equals 45 degrees again like so The other temptation of course is to do like in the second quadrant you're gonna get a hundred and 35 degrees which of course would leave that angle c is zero so that one doesn't work So we get that B is 45 degrees, but like I said, I recognize with a sausage triangle is able to do that really quickly That's not a necessary observation, but it does simplify the calculation dramatically there Once you get angle a and b whether you use the law of sines or the assosceles triangle theorem That doesn't matter once you get a and b to find the measure of angle c We're just going to of course take a hundred and eighty degrees Subtract from the angles we know so we have 45 degrees 45 degrees which combined is 90 degrees So a hundred and eighty degrees minus 90 degrees so we get that C itself is 90 degrees so it turns out that in hindsight we see that this triangle was actually a 40 40 45 45 90 triangle which was pretty cool not necessary. We found this using the law of cosines and law of sines mind you But we found all this information and it turned out to be pretty cool at the end Don't worry about the diagram these diagrams are not drawn the scales The fact doesn't look like a right triangle is actually important because we didn't want that to suggest That was the right answer. We found it through this trigometric formula of the law of cosines and sines


Job trends. Important information for finding a job today and tomorrow. What are job trends? Job trends give us information about jobs that are needed. This is called in-demand. Job trends give us information about jobs that are not in-demand. Job trends tell us what kind of education we need. Why are job trends important? Some job trends depend on the community where you live. Many job trends are the same everywhere. Job trends help you make decisions about your education. When you know about job trends, you will find a better job faster. General job trend. More education, more money. Going to college is very important in the United States. Did you know? With just one year of college, you can earn about $7,000 more per year. General job trend. Computers. Computers are very important for all jobs. You are learning how to use a computer in your idea program. Congratulations! General trend. Personality. Are you punctual? Are you organized? Are you hardworking?  Are you reliable? Great! You will always find a job. Example of a job trend. Home health care. Every community has people who need help. People are getting older because of better healthcare. Nursing assistants and personal care aides help people at home. There will be many new jobs in this area in the next 10 years. The end.


So, hello everyone and welcome to my talk about the QEMO emulated NVMe device. My name is Klaus and I'm a software engineer with Samsung Electronics. And this is my first time speaking at the KBM Forum and I am very excited to be here. So this is going to be in context of NVMe. So NVMe is the non-volatile memory express. It's a storage interface that's designed to exploit the low latency and inherent parallelism of net flash memory. And to understand some of the things we'll talk about in this talk, there are some core terminology that we should go through. Basically in NVMe you have the concept of a controller, which is a PCI express function that acts as the interface between the host, which is the device is connected to, and an NVM subsystem. The namespaces are quantities of non-volatile memory that are accessed independently from other namespaces and typically biological web address. NVM subsystem combines these things into a set of one or more controllers, zero or more namespaces and one or more ports, a port here being, let's say, a PCI spot. So a little bit of history on the NVMe device. It was first contributed by Keith Bush at that time working for Intel in 2013. And the implementation that he did held up for several years. It did the job and people could develop drivers, test out their drivers in an emulated setting before or when hardware was of limited availability. In 2018 and 19, I became involved in the open-channel SST ecosystem. And I was using your email on a day-to-day basis extensively. So I started to add a bunch of missing mandatory features to the device. And one of the things I started working on a lot was adding support for multiple namespaces to support the open-channel SST on emulated open-channel SST. And so because I started to contribute a lot from 2019 and up through the next couple of years, I became a co-maintainer in mid-2020. So one of the things I added was that I bumped the device version to implement NVMe v1.4. I added the multiple namespace supports. In 2020, also, we got the support for sown namespaces in the NVMe device. We added, I mean, we added the subsystem and namespace sharing support. And we added metadata and interim data protection just to mention a few major features that we've gotten recently. So as you can see, things actually moved pretty fast. And as we shall also see, sometimes it moved a bit too fast. So there were some mistakes done. And we'll be talking about one of them specifically today. And they stemmed from not really knowing about best practices or how to effectively use the available APIs and QEMO. And there are a lot of them. So it might be difficult to get this broad overview of how to wire up devices and how to make new device models. And it also stemmed from, especially for me, not really fully grasping QDALE and the relationship with the QEMO object model. So speaking of these APIs, one of the first issues I had when I really started doing QEMO work was I had trouble rocking on the standing QDALE versus the QDALE object model. In the beginning, I thought it were two different things because I thought it was a versus. And one of the things when I finally learned was that no QDALE builds on QEMO. And there are documentation available. It might just be a lot for a new device implementer, a new developer coming right into QEMO and wanting to make a new device. It might be difficult to grasp all this documentation available. The header files are extensively documented, and that's just a lot of it. So what QDALE builds on the QEMO object model and it actually provides an API that is tuned for sitting up user-created devices. And there's this emphasis on devices, which is later because devices are the things that we consider to be instantiated with command line with the dash device. So while it provides this nice API and a lot of nice teases to configure these devices, it also imposes a very strict structure on how to wire up your device inside the QEMO machine that you're emulating. This is an order tree where every also needing level is either a bus which can have multiple devices attached or a device which can create multiple children buses. So as you can see, you always have one parent relationship in this tree. So when the NVMe device was first introduced by Keith back in 2013, it only had single main space support. So you would have the device, the NVMe device, and it would have a drive property on it. And it would have all the associated drive or the common block device properties like the logical block size, discard support, stuff like that. So what I wanted to do was add support for multiple main spaces so that we could have several block devices attached with individual parameters. So we wanted different block sizes, say 512 bytes for one of them and 4K for one of the other main spaces. And when I first posted my patches, I got a lot of helpful comments from the community. So thank you for that. And what we ended up with was adding a new device, the NVMe NS device, and we would add a bus to the NVMe device such that the main spaces could attach to this bus implicitly or explicitly. And then you would have this relationship between the bus and between the controller device and the main spaces. And that's all of also how the SCSI subsystem does it today. So it was very nice because it fits into the QDib tree and you got introspection just worked by typing the info Q tree in the monitor. You'd get this nice tree. You'd get the main spaces underneath the controllers as children of the controller and get all the parameters and everything that just worked and was really nice. When the device was removed, a hot clock, then the children on the device would be automatically unrealized. So everything cleaned up by itself and it all made sense when we introduced this. And this automatic cleanup should be a nice thing, a good thing. But when we added more advanced features like subsystems and shared namespace functionality, then it became a problem. So if we look at the plumbing and how it was done prior to version 6.0 of QEMO, we had something like this. You would have the main system bus and you would have the PCI Express bus there. Then you would have the NVMe device, PCI device attached to this PCI bus and it had its own bus where the namespace was attached to. Looks nice and just the way it should be. But then we wanted to introduce shared namespaces. And a shared namespace is a namespace that can be accessed concurrently by two or more controllers within the same subsystem. And it's very useful for testing advanced drivers and multi-path IOs. So we really wanted to add this to the device model. So it required adding the concept of a NVM subsystem to the device. And again, because I or apparently also anyone else interested in the subsystem at the time didn't really knew any better, we ended up merging this as a device that was a busless device. It was not attached unrooted, was not attached to the system bus, but it was like an anonymous device or unattached device. And then we would add a subsystem link parameter on the controller to plumb it up with this subsystem. And it followed the design of how you would create the NVMe in this namespace device. And it felt like that was the way you create devices in QEM. So it looks something like this. You would have these controllers. And one of the controllers would have the namespaces attached. And through the NVMe control device, the namespaces would know about the subsystem through the link parameter on the controller device. And through that, they would register with the subsystem. And through that, you would basically attach it to all the controllers in the subsystem. Now, and as we can see, the namespaces devices can only be attached to one device or one bus in IQ Dev terms. So the problem is what happens when we remove this device? Well, then the namespaces would be automatically unrealized. And we would end up with the namespaces going away and maybe having references from the other controller that still thought that these namespaces were attached to it. So that's a big problem. So we had to get a fix in for this. And we did a fix. We basically added another NVMe bus on the subsystem to which the namespaces were attached directly. And this worked. But it was not really nice because due to backward compatibility issues, we had to keep the namespaces devices to attach initially to the NVMe devices. And then if there were a subsystem attached, then we would re-parent these namespaces devices to the subsystem bus instead. So but if we could fix this probably, then one of the things we could probably do was to implement a custom hotplug handler and maybe fail over the namespaces when one of the name controllers was removed. Or if we started from scratch, then we could have made the subsystem device, a system bus device that exposed this NVMe bus. And then we could keep the namespaces devices as they were and then we would attach to that bus instead of the controller created bus and which we removed. And so it could have looked something like this, that the namespaces were directly attached to the system bus and we would have references from the NVMe controller directed to that subsystem instead. Now there are some potential issues. Again, there are some backward compatibility issues that we could have to solve. It would probably require to implement new devices, deprecate the old ones. That's not a bad thing. It can be solved. But we would technically think of the NVMe controllers as children of the subsystem. But due to the way QBus works, we wouldn't be able to do this because the namespace or the subsystem device is not really a PCI device. It shouldn't be on the PCI bus. And the controllers needs to be on the PCI bus somehow through the tree. So it also retains this idea that subsystem namespaces are actually devices, which is not so nice. But this is how SCSI does it. And SCSI separates the controller from the drives and it uses a QBus to wire them up. So something here must be the right way to do it. It feels right, or it smells right at least. But this one parent restriction has apparently also impeded the addition of multi-path IO functionality in SCSI. And I know that Hennis Leininger, who I talked to, because we talked about this problem in NVMe, that he would run into this restriction of the audit tree, which gave him a lot of issues with implementing business SCSI. And it also seems like no other subsystem, QEMO block subsystem, block device subsystem, seems to support this notion of a shared block device like NVMe does. So what if we were to rethink this model? And what if we said that subsystem namespaces shouldn't be modeled at devices? Because neither of them actually expose virtual hardware. They don't expose memory. They don't expose IRQs or anything to the guests. And conceptually, a subsystem is the parent of controls, as I said before. But they are not a PCI device. So how would they fit? And namespaces can be associated on children of multiple controllers. But again, this runs against the audit tree with a one parent relationship. So we can really express that. And fundamentally, namespaces and subsystem are just concepts of a device model. And they happen to benefit design-wise when we do this of being independent devices or independent instances. So there is an alternative to this. And that's user-creatable objects that you can instantiate on the command line. That's object. And those actually might be more appropriate. Now, there are no existing devices that uses objects like this. So there is the memory-backed object, user-creatable object. And we actually use that in the ME device to implement the system memory region. So knowing that there were at least some devices doing stuff like this, I gave it a shot to actually try to implement it like this. So I posted this pretty big patch series that I called the Dopepocalypse. And considering the size of the NVMe subsystem, it's a really huge patch. But it is also a major refactor. And I did a lot of work to try to make it as renewable as possible. And what it does is that it introduces subsystem and namespaces as user-creatable objects. Now, the goals of this series is to introduce a new experimental controller device. This is mostly to get rid of some deprecated options, as well as changing how the subsystem link property works. It also creates or introduces new experimental user-creatable objects from namespaces and subsystems. And it introduces three of them, two namespaces objects for different namespace types, and one of the subsystems. It also exploits the QEMO object model extensively by using or implementing an abstract object that contains the base functionality or common functionality of namespaces. And then you have the NVM namespace types and the zone namespace types that derives from this base class. And the zone namespace actually even derives from the NVM object, because it just extends how the NVM commands the set works. And we retain backwards compatibility by keeping the existing devices around. So all the existing devices uses the new object code internally, so there's no code duplication, and there's not suddenly two trees to maintain. And the goal, of course, is to deprecate the subsystem namespace devices when these experimental objects stabilizes. And there are some perks, of course, having introduced brand new models so that we can clean up some of these confusing device parameters, such as the MSI execute size, which is really just maximum interrupt vectors for the device. And there are some so far unofficially deprecated, but there should have been officially deprecated parameters that we can also get rid of. Then there are some fixes for how the namespace manages some parameters and the subsystem as well that we can just fix up. So instead now, you create the subsystem as a user-creatable object, you give it an Identifier. And then you add the controllers, like before, as a device, because they need to go to the PCI bus and attaching it to the subsystem. Then you add namespaces. Again, you use the NBM or the zone version of them, and you attach that to the subsystem. And then there's a new parameter that can use multiple times to define what controllers it should be attached to initially at Google. There are, of course, some things about using objects instead of device. And one of the things is that properties are more opposed to define. And that stems from the fact that in QDM, properties are sort of considered immutable. When you've set them, you shouldn't be able to change them. And you can really hook into the gatherers setters. You can do that with the raw user-creatable object. And that gives you a lot of flexibility, of course, at the cost of slightly more opposed property definitions. There's also no realization space as there is in QDM. So what you can do is that you can use a machine.notifier to emulate this. I stole this from how the remote object works, which also does something similar to this. And also, if you're not using object composition, which we are not really using with this implementation, then you are responsible for doing cleanup as devices that you depend on are removed from the device model. So I think one of the lessons learned here is that you should consider all your options when you define or decide how to define your model or design your model. For instance, should it be split apart into multiple parts? And should those parts be devices or objects? Like, does it actually behave like a device? Does it expose virtual hardware or memory beaches? Like, does it quack? Because the flexibility of user-created objects might be what you're actually looking for if you can get by and live without the luxury of the niceties of the QDM API. Now, as my series goes through review, it might be very possible that we end up going back to the system-based approach, because that's how other devices does it right now. But I hope to at least push for this version, because I think it gives us some really nice and also some nice introspection features because of these more flexible gathers and centers of properties. So for future work, one of the main things that we want to change in QEMO for a long time is that we have this QEMO SGList and IO vector duality. So we use the SGList extensively, because most of the data that flows through the controller goes between the controller and the host. So it needs to be to use the DMA helpers, and we use those because they're nice. But there's also a bunch of commands that only transfer and move data internally on the controller and those like copy and verify the data and stuff like that. And those uses IO vectors, so we also have to move them. And whenever data goes into and out to the controller memory bar for the persistent memory region, then we also need to use the IO vectors. So one of the ideas here is to open code this DMA mapping transfer from DMA helpers into the device and process the PRP six data incrementally as we have DMA resources available, which would completely remove the need for this temporary SGList data structure. One of the other things that we're working on is to try and limit the latency of the device. So this is especially for profiling, pulling, and maybe drives that doesn't rely on interruption of the device. And one of the ways or one of the few ways to limit the latency of the device is to use in-memory and know of IO and use IO threads or dedicated calls for queue processing. There's also some para-visualization features in ADME that can limit the number of memory mapped IO and thereby the number of VM exits that need to do. This is not implemented, but there are some existing patches floating around that basically just need to try and interpret. I think that the FEMO SSD emulator, which is a form of QDMO actually implements this as well. So the big goal here is that can the emulator device possibly be made faster or at least latency-wise than available hardware? Or at least how low can we actually go in terms of latency and can get good enough for profiling? So what I was hoping here, especially for Q and A, is if anyone has any knowledge or experience with doing stuff like this, and they know that this is a hopeless endeavor than I'd be happy to know about that, so I don't go wasting my time too much on things that I just think is fun. So this was my talk. I think we're at the top of the hour and thank you for attending. And I hope to discuss stuff with you at the unit. Thank you.


So, I think I'll give you in the 25 minutes I have, ha-ha. But really, I'll give you in the 25 minutes? Yeah. Oh, wow. I'll give you more now. Say, seven lightning talks, how about that? And the slides will have about 40 more minutes of audience. So it's really, but luckily, you don't have to listen at all because I'm not telling you anything you can take with me. So, the first lightning talk is the Nasa nutrients. What's been going on in the VM? And this is a slide I recycle on these events from GVMLS to get to me. What should the VM look like? What has it looked like in about 20 years? What will look like 20 years from now? These are my speculations. And also aspirations. It should continue to have a uniform model of that satisfies objects and interfaces and arrays and primitive in a way that you work with them all and even like the narrow algorithms over them. That was very imperfect in the beginning of the JVM. The JVM still has this hard division between primitives and objects. But we're working on making that even better. We also, of course, want there to be efficient use of whatever hardware resources are standard, which today means catalogs of approximately 64 bytes that are prefetched and are weekly ordered developed for each other. So we want to be able to have flatter data. So that's one of the, I'll refer to you a little bit later, but we want naturally localized data structures that work well in that way and that don't waste a lot of space for house key functions. Of course, we want not only the data to be nice and tight but the code to be nice and tight. We don't want to run some kind of a bytecode engine with lots of simulation overheads all the way down. We want the VM to drop your code right down the pocket of the metal and run it as fast as possible. One thing that will be very different, I think, about 20 years from now versus 20 years ago is threads will no longer be the cool thing. Java was an early doctor of threads and now threads are showing their age. We want something finer grained. We also want interoperability. Java started out as a set top box and safe execution environment security and employer guarantees. It still is that, but it has a more forest boundary nowadays and the ceremony required to tie up your native code and data with JNI is too much. We want to do better than that. We want the VM to continue to be broadly useful. We want it to run whatever the modern languages are that are significant today, like in 20 years from now. We want the JVN to run it. That will probably include C and C++ someday if they're modern 20 years from now. And then finally, looking back, we want the JVN to continue to be compatible. We want it to run in dusty decks and perform it if you want to get it, like I said, lower down in the hardware. Whatever the new PUN are of the 20 years from now we want the JVN to run as well. So this is our top level goal. This is to keep the JVN relevant, applicable and useful in a word, vibrant. How do we make things vibrant? Today, well, today's workloads are pretty cloudy so we're paying a lot of attention to cloud execution models. We want also, of course, to be compatible with apps together. One of the reasons I think that Java has done so well in the long haul is in commitment that the emphasis is a sort of culture of bias or some compatibility and we want programmers' code to continue running and we don't want to have them to re-engineer their code every time they recompile it and then pull chain C++. So I think that gives us a certain amount of trust in the community and you can see the last half of that with the JDP9 people worrying about the adoption problems. I will say we tried really hard and I think we succeeded well in making the compatibility at a high level with the JDP9 where we had the breaks and things. The JDM has always been fairly reliable. We want to be more reliable. We want you to trust it not only with your code but also with the execution of the data. We want it to have good tools and of course we want open source collaboration. The JDM and Java deserve to be something that's developed out in the open and sunshine. What's developed out in the open and sunshine should be the best tool chain at one time for running code on the planet. It should give you the best access to your metal. So we can basically run the world on Java. I would guess that we want to care a fraction of the world now on Java so let's keep going and double down. Now in order to make this work the VM in particular has a whole ton of technical initiatives that are working. This slide just gives you a snapshot of it and I'm not going to explain it. I'm going to move on and tell you in detail I trust you will be able to see the slides after the fact. I'm relying on that. I want to give six lightning talks in a very short time I have remaining about the trends that I think are interesting and relatively new in some ways. Java on Java as exemplified in Project Metropolis which we've already heard of. Platzi or Criminin. So I'll explain that in a second but that's value types. Richard Leiger's support. That's some really interesting little books that we're doing in collaboratively we, in collaboration with the language nerds that Brian gets into. We have fruitful conversations with them between Project Amber and about Ally and then of course the hardware access in Panama that Marco alluded to is another interesting trend to watch. Concurrency getting more truthfully and granular better and full of race conditions. That's trend number five. I think we're going to get better over time and also let's scale up to bigger workloads and there's some really exciting stuff happening in recent months and coming months with some scaling stuff. And all of this I emphasized if we want to happen in the sunshine in the open with the community this is something that we want to be collaboratively and quick-quit again. So trend number one. Java hosts more of itself. As Mark pointed out the brawl jet as an experimental feature is coming to a release near you. This is just the beginning of a series of experiments where we think we will eventually be able to tear ourselves away from that C++ code we love so much and code more than Java. So starting with brawl code generator which is an amazing piece of technology. It has actually quite long lineage it's been much of it's been fostered by either some of it in some labs and some of it in much of it at Johannes Kepler University in Austria. Deep deep research the scales here are really quite impressive. We're looking at 10 years 10-ish years of calendar and just over that period of time probably hundreds of staff years of engineers working away many of which are grad students now community as professors or researchers. It's been an amazing run and now we we've used brawl as an engine for AOT. That was our first piece of brawl in anger in OpenJDK for the JDK itself and then also it's candidate for a proper protocol you can do this as Mark mentioned. So those of you who have experimented with this and worked on it and in hope tried out brawl as a jit for the future like there is yeah there's more to come join us. Brawl is also good with interpreters and scripting languages but you'll have to look elsewhere for information about brawl code. Metropolis is the experimental clone of JDK11 whatever the current JDK is where we try to make Java implement itself. We bootstrap Java on Java and we nudge out the C++ code and the assembly code that we've been pending on and replace it by up level Java code. This requires a certain kind of system Java to be able to replace the C++. We are experimenting with an engine called SDM SubstrateDM that will give us the ability to shrink down closed Java subsystems into code that is similar to what C++ compilatory creates. And so that will lead us into the world being able to take discrete modules from hotspots like maybe even the verifier and replace the system Java and replace the C++ code. The big one, of course, is replacing C2 but C2 is just the most optimized encoder and we also want to be able to replace C1 and the interpreter and various subs so that we can have a system that is running on one code generator. And of course, last month we discovered what happens if you have too many code generators and then you get a hardware bug that requires them all to be upgraded depending on just one code generator. And that's the digit for the Java ecosystem is to have is to own our own code generation rather than get it from our excellent colleague said with the LLVM. So, tomorrow's reference implementation, more Java, Java on Java. And here's a roadmap, I won't go into the details, but we think we can make this work and we're getting step-by-step closer. Next, let's talk how the primitives get classier. Of course, they're very good, but maybe we can add some class to them. The big idea is value types, of course. What is a value type? Well, it's a thing which is like an object, but it's also like an int. It has the good features of both. And mixes them together in a new way that you can't just get for today's objects, today's ints. So we want to heal the riff between those primitives. Always felt like a sort of unnecessary but bolted on a part of Java. More like that, more of the classes. So, the trick here is to distinguish a new type of class, called the value class which is distinct from an object class. And the value class defines things like ints, which have interesting properties I'll tell you very quickly now. The basic flow-in is that it codes like a class, but it works like an int. In other words, there is a value class with methods, with fields, and all this stuff. But, in the end, it sort of packages up and scrunches up at this unit of stuff which behaves like an int. I'll tell you in a minute how that sort of behaves like an object. This project also requires something really, I mean, that's hard. What seems harder is doing parametric polymorphism, full polymorphism, generics over not only objects but also values including primitives. So, list of ints. Yes, that's coming. And list of complex. Where complex is a unified type. Good stuff. This will require, oh my gosh, this is the biggest change we've ever made with ICOs. And I hope the last big change we ever did when we say that. In any case, it will require huge changes to tools and VMs. And VMs, VMs are ready for this. The effect on our source code is that it's probably going to have a similar effect than the generics had on our source code, the lambdas had on our source code. In other words, we will have to learn some new things. Here's how I code the value types. But the benefits will, I think, be comparable. Basically, classes are really great for correct encapsulation. And the system that Java has at interfaces is a really good way to talk about classes without knowing much about their implementations. And we believe we can spread that uniformly to value types as well. And once we grant fathering on these primitives as value types, then we will have in the team. So, if we bring the two sides together, then they both get stronger. Primitives, then, from this point of view are really just a distinctive kind of a class. I hope someday we will actually write some classes for int, flow, boolean, etc. that will show you what their intrinsic state and methods are. And those will just be value classes. And yeah, they'll have a special cleaning in the VM. But that won't be what you care about. Here's a bit of theory about, which I'll give you just a case. Here's what's different about value types from value classes. The JVM is encouraged and is able to flatten value types. In other words, if I have a containing type that has a feel of complex, maybe it's even complex flow, and then that complex flow propones that will be into the containing object. That's called a flash. And arrays of them will be flattened in a similar way. The VM isn't required to do this, but it's allowed to and encouraged to. That allows us to get that cash-friendly data structure that we're after. In order to do that, they must be non-nullable. Null doesn't hit with int. You need 33 bits if you're going to have int or null. That's a type, right? So 32 bits, that's a non-nullable int. The same way for value types. It also has to be identity-free. You can't say which 42. I want to lock this 42. That's not going to be allowed. So again, the VM does have little pointers to things holding value payloads. Those have to be completely isolated and made invisible to the user. Interesting challenge. So they're flattened. They can be buffered. You can refer to them internally in the VM by pointers, but pointers are never significant to the user. And therefore, you can re-buffer them. You can take the same value and you can buffer it in two places at best. Or if you see the same value in two different places, you can maybe on a GC pass de-duplicate them. All those things are allowed. Once identity is removed, interfaces apply equally to value classes and object classes, which means an interface code can work equally well on values and objects. And object itself is an honorary interface. That's a piece of forced fit that we have to do in order to make object be a value of potential value. Basically, object is sort of like comparable or runnable. It's a abstract thing. And that gives us the ability to work conveniently with value types in today's erased generics. Although we want to do more. We want to do parametric polymorphism. And work across all values. But at the same time, they allow you to compile specialized code that is optimized for the very particulars of a particular value type parameter. So if I say list of complex flow, I want the internal layout of that list not to box each individual complex or each individual flow. I want it to have some sort of flat array with real flow, memory flow, all laid out in a small set of cache lines. And that's just the starting point. There's a lot more to say about it. But what we need is something like simple plus templates but more dynamic. And in order to this mechanism will give us a lot interesting plays once we get it online. Okay. One way to think about this is remember that when you're coding generics your generic types T are in some sense universal. And the T is not the same thing as an object type or an interface type. It's a type parameter type. And there are tricks in the T that you can't do with a plain old interface. Same will be true for these new enhanced generics. This is hard. I won't tell you why but that's the slide. Okay. The full parameter of polymorphism is you can write generic algorithms over all of your types, not just the object types. All the values primitive and in reference types. And so you can have, have you noticed those places like in Java, Utah, the rays where there's seven or eight different kinds of methods for each primitive type and the overloading makes hides the shame of it. But if you look at the source code you're going to fix that, right? We're going to be able to categorize over all those types and have a true generic sort algorithm, for example. I think that would lead us to a better kind of generics, better kind of algorithm on the rays. One thing important to note is that we do not intend to expand these things statically. We intend to expand them dynamically and in a sense only when needed, although AOT will be able to pre-provision templating the species that are necessary. So, I'm going to skip that last one. Okay, what about the species? I know the species as well. Species is the combination of a template which has formal render holds and common killings for those holes causing a particular template to be expanded into species. So that's the basic idea. The VM has to be deep in the game on this so it requires deep cuts in the VM. The hardest problem is to arrange things so that you don't have to have a million copies for every different species of the code if you want a shared code if possible but when it gets hot, you want to specialize it just like it does today. Interesting thing, number three in my last six minutes. So, amber is, as I said, a sort of handshake between the languages as I was in the VM. There's a number of little toolkitty things that are really cool. One of them was just coming in sailing towards 11 and that's a part of a trend that I call bootstrap methods everywhere. Bootstrap methods turn out to be a good trick so we're going to use them like crazy. So we have a bootstrap method at call site that's a constant pull, that's condi. A bootstrap method in a method definition that doesn't have a cute name maybe Mindy, but what it really is is a method recipe that expands on use and produces the body of the method. Can you imagine writing your two-screen visualization boilerplate that way and then you don't have to load it and just expand it when you use it. So other pieces are nestinates and sealing. You can sort of watch the Alalists to see the smaller features that we're doing for support of language stuff. So what this leads us to is a situation where when the language designers tell the VM designers what they need, the VM designers can give them the right generic mechanisms that focus for new kinds of translation strategies then the language designers can do really wild new features but without increasing the bytecode size of their classes. You might have noticed that here if you're kind of Scala, that one of the downsides of Scala is that it can't use weird old VM features under the covers that have to use standard bytecodes but Scala can turn into 20 different class files in your jar. Each one of them has a significant size because of all the little adaptory classes that are needed. We think with the Lootstrap method trick we can avoid doing that and making it much more dynamic. Panama has already been discussed and there's some interesting information here on the slide deck for you so I'll let you look at that but the basic idea is BetterJNI who want to use the Java code when you brought in and basic locks in right in there with the Java code so basically you get inline calls to printf and whatever other Unix primitive you want to call. The idea that I'm making this work is the binder pattern which knows how to wire up foreign calls to whatever the low level facilities are in the JVM and again you don't have to pre-compile a little of the stuff because you just let the binder be before you know why. But in essence it will give you more direct access to your code and data at the C programming level and even at the assembly level. Speaking of the assembly level Intel has worked with us to produce a really wonderful proof of concept called the Vector API where basically you write a Java loop with Java objects to Java interfaces, Java generics to ADX code that you've written in the assembly by yourself and would have been proud to write it as an assembly programmer but it comes through Java and it's great. And we think we can expand that story to platforms beyond Intel including GPUs. So there's some references for Panama, Loom, Awesome, Fibers we need more Fibers in our diet we need fewer dinosaurs to strain over we want to break up the live parts of our computation into small independent bits that are mounted on a dinosaur thread and a gallop along for a millisecond then they dismount and then millions of other Fibers are also mounting on the same dinosaur thread over time. So the ultimate goal is to have millions of little concurrent units and just one just a small number of server threads. Again this requires tricky cuts in the JVM interpreter because we need to be able to quickly mount and dismount our computations on threads. It's like a user level scheduler for very tiny threadlets. I already explained this so I'm going to go on and Ron Kressler is working on this since last year and he was extending his work on Quasar which was a user mode above the level of VM. Now he's naturalizing the idea of these interuptable continuations on the inside of the JVM itself. It uses a low level concept of continuations on which you build a high level concept called Fibers but you could also build generators and other concepts in the future. Finally our scale will get scalier and I'm telling you it's almost out but this is an easy point to make. So we have new pointer base to read and read barriers in private Canada, really cool. It's a really low latency, and guess what? Here we are, another project that sets the mountain float itself and it uses a different kind of a re-bearer. So now we have the fight of re-bearers. You can use brooks pointers or you can use bit-based branches. Oh no, how are we going to decide this? There's too many new technologies floating around but we can handle this, we're a community. We have some short term tasks to work with this besides the individual project work. Make sure that we refactor everything that's common to the two projects into one source base and upstream that stuff so that when you eventually do dock these two different algorithms in it's not a huge amount of work to have one or the other and then even both live in the same in the same system. This enables not only coexistence but also stealing of good ideas from each other which is a great thing in the community. Long term result, like Mark said we want to unify low latency DC technology and it's a good experimental a good bench for experimenting. So fibers also are a scaling technique which is obvious to all of us and another technique for scaling is the curvision that you get from an app CDS and AOT that's for container scaling and finally I can't talk about racing data because I'm out of time to look at my JVM language summit talk of last year. I think we are in for a new way of looking at managing races in the job of memory model.


So, as many people probably already heard, Equifax had a data leak that could involve 143 million consumers. Now if you're not familiar with who Equifax is, they're one of the large credit reporting agencies. And if you are familiar with the R, it's because you've been super agitated because you found something on your credit report that became almost impossible to remove and you get caught in the round circle of dealing with this company that basically exists to slurp up data and come up with a rating and a value they place upon your head based on your credit rating. Which is the current credit system that we have here in the US where we decide a number and a score and a debt ratio and we decide whether or not you are worthy of being lending money. It won't rant too much about that. That system is dysfunctional on its own. What I am going to talk about is the security aspects of this. So the Equifax data leak because they have so many people who have credit. If you have a credit card, if you've applied for a car loan, a home loan, most any loan, at some point they start a credit profile and companies like Equifax have that credit profile. So they are then the reporting agency that the company you go to for the loan will use to determine your worthiness of the loan. That means you do not have an option of whether or not your data gets stored in this company. Now this company does fall under some regulation, technical regulation, and financial regulation. So they should be PCI compliant and whichever other compliance is applied to them, but the fact remains they lost the data. Now we don't have a lot of information yet, but I'm hoping a lot more comes to light and I'm hoping a full debrief is done because I want to know how they got hacked. It is more forgivable if we find out they were hacked by a unknown zero day that was used to attack them. That means a unpatched, no one knew about this particular type of security breach until it occurred. Those are more acceptable answers when it comes to breach security. But my feelings are we are going to find out that they ran security poorly. We have such a history with these companies that we find out that they just don't do a good job of security. They look at it as something that's a cost and how can we reduce that cost? How little can we spend on security and feel like we can still sleep at night? And yeah, that's kind of where I'm feeling we're going to go with this. We don't have any details. I only have some hyperbole and things I've read on Reddit from people that claim they worked there that the company did not care, used non-password protected Excel sheets to share information with all your personal data. And I don't know how truly that is. That's very speculative. Although there are a lot of people rambling on about it. I want a full disclosure from the company. What we did get though was the CEO, Rick Smith. And he had his little statement on this. So let's play it real quick. To that end, we're taking unprecedented step of offering every US consumer in the country a comprehensive package of identity theft protection and credit file monitoring at no cost. All right. So the company that screwed up all my data, if you didn't hear that, is now going to offer security monitoring of my social security number. That sounds interesting. But let's dig a little deeper right here. And here is the Trusted ID Premier, their company that they're offering. And I understand this only lasts for a year, even though they completely screwed up and lost all this data, it only lasts for a year. But I'm going to jump down to the important part of this of why you shouldn't sign up for it without really thinking about it. There's a lot of legalese. If you can see the size of this page, it's huge. Like there's a lot of stuff in here. But the part that really becomes interesting is by consenting to submit your claim to arbitration. You will be forfeiting your right to bring or participate in any class action. Yes. Of course, they want you to sign up. Hurry, sign up for us, because we're probably going to get sued by a lot of people. So please sign up. And that way, we can say, no, you don't get to benefit from suing us. Because by consenting, you submit your claim of arbitration you will be forfeiting your right to bring or participate in any class action lawsuit. Literally, I'm on their website, TrustedPremier.com, in their terms. And yes, if you sign up for them, you will do this.  They actually, granted they have lawyers writing this and people are scared and are running over here to do this, this happens. But yeah, you will be consenting to submit your claim of arbitration. So be careful on that. But don't worry about the executives in case you're worried anything will actually happen to them. Maybe the SEC will get a couple of them. Three Equifix managers sold stock before cyberhack revealed.  And before it was announced, apparently, intrusion on July 29th, regulatory findings show that days later, chief financial officer sold a million dollars worth of stock and president of US Information Solutions exercised his option to dispose of half a million and roll off ploder president of workforce solutions sold a quarter million. I have a feeling the chief financial officer probably knew that there was a breach. I mean, was he on vacation? I don't know. We're not gonna know, but this is, and it's a small percentage of stock, but still 1.8 million, they're like, yeah, let's cash this out because in about a month from now, there's gonna be this little announcement we do. So that's kind of my thoughts currently on the Equifix. I'm gonna be following the story because I'm always fascinated with the details of how they got breached. I wanna know, did they follow best security practice and they did everything right and something unknown came into them? Or were they doing everything wrong and it was an eventual matter of time before they got hacked, as we've seen with some other companies where poor security from top to bottom, it was kind of like hacker's choice. Which one of these things do we wanna breach? So we follow the story and hopefully be doing a full debrief. I really would love the details revealed because sharing the details of how they were breached hopefully can help us all in understanding how to avoid breaches in the future. Security is hard. I will be the first to admit that working in IT, it's a cat and mouse game and we're really on the almost the losing end because there is way more people attacking systems and trying to poke holes through them than are people securing those systems. And I do know a lot of companies that do look at security as an inconvenient cost that they have to do. So that's my thoughts on the Equifix security breach and the disgustingness of forfeiting your claims. So please think about it before you say, I'm not a lawyer or a person who's an expert on this stuff, but I'm just kind of pointing out the obvious holes that forfeiting your right to sue them when they lost all your data that you didn't have a choice or whether or not they would put your data in there is just terrible. I'm also gonna throw a few links in the description here. My understanding is one of the best things to do is do a credit freeze. So this isn't a problem. And I'm sure there's gonna be a million sites popping up that are fake about credit freezes. And so I'm gonna go ahead and link to the Federal Trade Commission one so you can start there and do some reading and make some decisions of what you wanna do. Please consult with a financial expert because I'm more of a security and IT guy but I'm trying to think of what to do myself but probably a credit freeze seems good because they lost a lot of data and it's everything from driver's license, social security numbers. So they have a lot of information of you whoever went into this data. So all right, thank you very much. And if you like the content here, like and subscribe.