[QCon 2019] Java Futures

Brian Goetz

For other QCon blog posts, see QCon live blog table of contents

General

  • Java is approaching middle age. Almost 25 years old
  • Keep promises to users
  • Prime directive is compatibility
  • Backward compatibility matters ex: generics. Don’t need to recompile old code
  • Patterns ex: single method interfaces for lambdas rather than having to rewrite libraries
  • Languages features are forever. Interacts with others; even future ones
  • Waited 10 years for generics until had right story/timing. Knew copying C++ was the wrong choice
  • No language is ever finished
  • Languages are never good enough because hardware changes, new problems, developer expectations change
  • mid-2019 edition because things change so fast

Cadence

  • Used to release based on a feature rather than a data
  • Often didn’t feel worthwhile to do small feature because got stuck behind big ones
  • Now doing about two years of six month release schedule.
  • Release management overhead went down to almost zero
  • Same rate of innovation; just changed rate of release
  • Java 13 already in rampdown. Released in September.
  • Already working on Java 14

Preview feature

  • Risk of things happening too quickly since features are forever
  • Preview means feature is done but not finalized
  • Not experimental/beta.
  • Think of as provisional feature.
  • Expected outcome is that will be promoted to real feature in next version or two
  • Full IDE/Tooling support for preview features
  • Need to turn them on so not accidentally using in production -enable-preview flag

Current initiatives

  • Amber – right sizing language ceremony. Includes local variable type inference and future changes like pattern matching
  • Valhalla – adapt form modern hardware, value types, generic specialization
  • Loom – Fibers
  • Panama – Native code and data

Local Variable type inference

  • In Java 10. Future if on Java 8. Infinite past if you are Brian :).
  • var instead of type for local variable
  • Not syntactic sugar. Can expose “hidden” type (ex: capture types, intersection types and anonymous class types). So see more generics.
  • One of most commonly requested features
  • But also significant/vocal angst – can write bad code; giving into fashion
  • Not controversial once release. Fear of change in advance?
  • Will take time for good practices to emerge
  • Style guide https://openjdk.java.net/projects/amber/LVTIstyle.html

Switch enhancements

  • Preview feature in Java 12 and 13
  • Significant fraction of switch statements want to be expression. SO have to assign in each case.
  • Break is annoying. Irritating and error prone
  • Looked at how switch statements needs to evolve for pattern matching and then made more generally useful.
  • Boilerplate bad because a place for bugs to hide
  • Two changes – can use switch as expression or statement. Streamlined syntax label -> consequence
  • Will be in Java 14 unless feedback said made some horrible error

Multi-line String literals

  • Preview feature in Java 13
  • Require quotes and concatenation. Error prone for JSON, SQL and HTML
  • Manual mangling introduces errors
  • Was going to be a preview feature in Java 12. WIthdrawn because had better idea of how to do it.
  • Triple quotes to start/end
  • Dots for indentation that is just for IDE so don’t get extra whitespace when reformat in IDE.

Pattern matching

  • Intend to deliver in phases; hopefully starting in Java 14
  • Phase 1
    • Replaces if statement for instanceof and then the cast for the same
    • “Not only does the language make you cast explicitly, but it gives you the change to get it wrong”
    • if (a instanceof Integer intvalue) – checks type and gives new variable can use as type safely
    • Simplifies equals method implementation
  • Phase 2
    • Use in switch
    • case Integer i – matches if Integer, bind to i and allow use of variable inside the case.

Records

  • Lots of boilerplate – constructor, accessors, Object methods
  • A lot of code to read only to find out didn’t need to read any of it.
  • IDE generates boilerplate, but it doesn’t help you read it.
  • record Point(int x, int y) {}
  • Like enum, give up some extra features to get functionality.
  • Get sensible defaults in record
  • Declaratively states “I am simply a carrier for my data”
  • Programmer making a commitment
  • [does this discourage adding instance methods?]
  • Product type of algebraic data type

Sealed types

  • Sum type of algebraic data types
  • Shape = Circle + Rect
  • Compiler will know only those types
  • sealed interface Shape {}
  • record Circle(Point center, int radius) implements Shape {}
  • record Rect(Point x,….
  • Can use in if statement and pattern matching to get fields of record as local variables
  • Can use in switch statement. Compiler will complain if don’t address all possible implementations of sealed types
  • ex: case Circle(Var center, var r) -> PI * r * r;

Project Valhalla

  • Aims to reboot the layout of data in memory
  • Hardware change a lot in past 25 years.
  • Cost of memory fetch vs arithmetic has increased heavily in last 25 years
  • An array of objects will use data all over so many cache misses
  • Big change because goes down so far.
  • We want to be able to specify the class should be inlined
  • Giving up immutability and representation polymorphism.
  • Getting hardware friendly data layout
  • Code for the class works like an int

My Impressions

Great talk! It covered both things I had seen and things I hadn’t. Great perspective. Excited for some of the coming features.

[QCon 2019] No Moore Left to Give

Bryan Cantrill

For other QCon blog posts, see QCon live blog table of contents

Moore’s law

  • Not about speed, # transistors, density or per dollar
  • Not coined by Moore
  • Came from paper in 1965 – “Cramming more components onto integrated circuits:
  • Term coined in 1971 when Carver Mead was talking to a journalist
  • Moore also predicated home computers and computers onboard cars. Predicting 40 years out accurately is hard.
  • Predicted lower costs
  • In 1975, Moore updated the law to be a doubling of transistor density every two years. Meant to be a way of motivating engineers.
  • An Intel executive said 18 months (vs 2 years) and that got quoted all over.

Implications

  • Apps don’t get twice as fast.
  • Hit memory wall
  • Moore’s Law could add more caching, but that can only get so far
  • Need Symmetric Multi Processing to increase throughput
  • Speculative execution tried to pre-execute code and then became a security issue
  • Cost matters. It’s not about increasing speed at any cost

End of Moore’s Law

  • Samsung trying to 3 nanometer.
  • Many unsolved problems
  • A silicon atom is .2 nanometers.
  • This is the end. Can’t physically make smaller. 3 nanometers is only 15 atoms across
  • 7 nanometers might be the smallest size at a reasonable cost.

Beyond Moore’s Law – Quantum

  • Quantum computer is surprisingly really
  • Need large refrigerator. Must be close to absolute zero
  • Problem domain is very limited
  • Scale is tiny
  • Don’t yet have ability to scale qbits
  • Quantum computing may be relevant one day for the enterprise, but not any time soon

Beyond Moore’s Law – Specialized Compute

  • Bitcoin mining
  • GPGPU for ML/DL (machine learning/deep learning)

Beyond Moore’s Law – 3D

  • Heat and cost problems
  • Intel working on (Foveros)
  • Not a way to get “back on track” for Moore’s law

Beyond Moore’s Law – 2.5D

  • Smaller chiplets that are integrated on a larger die through silicon
  • Can be different types and sizes
  • Intel investing in this as well.

Beyond Moore’s Law – Alternate Tech

  • Carbon nanotubes, phase change memory, etc
  • History indicates won’t be able to compete on economics
  • If/when break through, change industry
  • Flash memory is only example of a break through like this

Beyond Moore’s Law – Wright’s Law

  • Cost of manufacturing an aircraft dropped 10-15% which volume doubled
  • Learning curve effect
  • Possible chips will get cheaper again as product goes up.

My impressions

This was great! He has amazing energy. It was a topic that was interesting and general interest. (I missed some of this because I was excited and communicating about being a Java Champion!). The state of the art and future is cool to hear about!

[QCon 2019] Rockstar Java Performance Panel

Todd Montgomery, Kirk Pepperdine and Bert Ertman

For other QCon blog posts, see QCon live blog table of contents

Quotes

  • “If you don’t create garbage, you aren’t going to have a problem with the garbage collector” – Kirk
  • ”Performance is in the eye of the beholder” – Bert
  • “Once you see it you can’t stop seeing it” – Kirk
  • ”Need to adjust containers in a sensible way” – Kirk

GC

  • Memory churn is an issue. But observability bad so cant see. -Kirk
  • GC allocation rate not the problem. It’s the result of the collection – Todd. Immediately Kirk disagrees
  • Don’t fear allocating objects, but don’t be wasteful. Parsing a String in the JDK is wasteful – Todd
  • Allocation rates still matter. Have to use CPU to allocate. Can fill a water tower one spoon at a time -Kirk

Solutions

  • Write simple code first -Todd
  • Never stop making it better. You may pause or decide not enough time. But never really done – Todd [this sounds like good enough]
  • A good engineer wants it to take less time. Will plan up front to type less. But also can’t stop thinking about how to make it better. However, might not be able to get the chance to do so. -Todd. As a counter, Bert noted that time runs out eventually and ok i have met no-functional requirements.
  • Get data – Kirk

General

  • First question is whether what customer wants is possible – Todd
  • A lot of the tools lie to you – Kirk
  • Profile disruption – Kirk
  • Have ore than one tool – Todd

Tools

  • Async profler – Todd
  • Flight recorder Todd. Looking at adding perf data – Kirk.
  • perf on linux – Todd
  • Remove/reduce logging – Todd. Seconded by Kirk. Good at finding the problems that have already been solved and likely won’t occur again.
  • perf – Kirk
  • GC logging – Kirk
  • Jmeter and other tools. Use with cloud based apps – Bert

Cloud vs hardware

  • Can start taking some variables out for serverless – Todd
  • There’s a lot between you and the actual hardware. Some tricks don’t work -Todd
  • Idiomatic parts of Java still work. Simple designs. Decoupled. No shared state – Todd
  • Underprovisioning other parts of hardware. Ex: focus on CPU and not network – Kirk
  • JIT compiler can produce different results depending on part of memory used – Kirk
  • Can look at assembly generated from JIT to counter this – Todd
  • Serverless often used as glorified REST API or glue code More config needed- Bert. Kirk countered that won’t happen because IT compiler is still going half an hour For complex code, could be hours or never for JIT to have stable plan. Sometimes stabilize in less than optimal config. Emergent just about every time restart – Kirk

Questions

  • Spring boot? Not using would be premature optiimization. Can tweak after – Kirk
  • How much knowledge of OS should have? As much as can -Kirk. It’s something that is there and have to live with. The more you understand it, the less it seems like magic. – Todd, The better you know environment the better can accoomdate it – Kirk. Better understand illusions. Writing to memory not immediate – Todd. Kirk asked who knows what a DDR4 chip layout is. More than zero :). Incorporated into chip design
  • Performance tuning on how deal with which quadrant? Yes. Deal with threads being on different cores with different profiles. Can only control so much. Don’t take into account unless want to go fully into it – Todd. Unless you are Todd, don’t go off heap – Kirk
  • Performance difference between Open JDK and Oracle JDK? Many JDKs based on same Open JDK core Difference in patches applied for bugs backported So performance shouldn’t vary. -Kirk Everyone should be supporting Adopt Open JDK. Only community supported distribution – Todd and Kirk. Todd uses Oracle JDK less but his clients do.
  • Cloud JDK? Depends on distribution. Amazon has own JDK now. Also bring your own runtime – Bert
  • More on how profilers lie? Not malicious. Profilers sample. A lot happens between savepoint – Todd. One thread can stop all others including GC. Samplers can show conflicting views of the same data. Biggest gain is o get application do wha wanted it to do in the first place. A lot of profilers work on differentials – Kirk
  • How generate less garbage? Find hot allocation sites and get rid of them -Kirk. Primitive data structures using boxed version instead of actual primitive version. Consider primitive instead of Object Be careful, but sometimes allocating a pool helps. Not always the best solution. Look at API have Can you reuse common aspects – Todd
  • Avoiding mutable state increases allocation rates. Kirk cringed. Doesn’t like mutable state, but not going around making everything immutable. Final comes with consequences. Proper encapsulation helps avoid need for immutability. Do you real need getter/setter Embed responsibility in object instead – Kirk. Absolutes are wrong. There’s always exceptions. Mutable state not a bad idea. Shared mutable state is the problem. Have one thread handle writes. – Todd. HashMap not a word used in business terminology. Missing a domain term in model – Kirk. Indiscriminate use of final is a bandaid over modeling issue – Kirk
  • How avoid getters in CRUD apps. Need gets at edge of system. Ex: database, GUI. In middle of system, don’t need to externalize – Kirk, Streaming set of change – Todd
  • Microservices? Not all services are designed for reuse. Time to market is the driver – Bert. REST is terrible from a model perspective. A lot of time spent parsing ASCII – Todd. Can parse a lot of ASCII in one network call – Kirk
  • Serialization? Dislike ORM as already had data. Easier to learn SQL – Todd. Kirk disagrees with SQL part. Wire friendly formats better than serialization. Or make them events – Kirk
  • When god to use object pooling? Someone said never. (I thin Kirk) Needs to pay for itself – Todd. Small object that are churned will be removed by the JIT. Large objects that are expensive may pay or self. But then it is like writing own GC. – Kirk
  • What features most excited for? Don’t look what coming to avoid disappointment – Todd. Fibers. Adding more work generally makes things slower. But fibers reduce thread count so might have benefits in some situations – Kirk
  • How make custom profiler? Look at problem to see what info need. Extend what need. Could be bytecode analyzer or an existing profiler. No two are the same when customize profiler. Tune in prod. Profilers will like sometimes. Test environments almost always lie. So lower sampling rate/impact since run in prod – Kirk. Very few organizations have test environment that mirror prod in any real way. Happy accident when tuning test environment improves prod performance – Todd
  • What resources recommend? Mechanical sympathy mailing list. – Kirk

My impressions

The three panelists chatted for a while before the panel started. They clearly look just as comfortable on stage then when just standing around. They interact well ad it is fun. It would have been nice if they had more than one mic to share across the three of them. During the day, I understand there re only so many mics. But right now only two rooms are in use. So I wish we could have been given the Q&A mics to borrow from other rooms. I learned a lot. Also, I brought a snack in case was hungry since the session starts/ends late in the day. I was engaged enough by the session that I wasn’t hungry enough to be distracted! Also Sai: thank you for volunteering to run the mic!