DOCSLIB.ORG

IBM SDK, Java Technology Edition, Version 7 Release 1: AIX User Guide Garbage Collector Diagnostic Data

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

IBM SDK, Java Technology Edition Version 7 Release 1 AIX User Guide IBM IBM SDK, Java Technology Edition Version 7 Release 1 AIX User Guide IBM Note Before you use this information and the product it supports, read the information in “Notices” on page 623. Copyright information This edition of the user guide applies to the IBM SDK, Java Technology Edition, Version 7 Release 1, for all supported AIX architectures, and to all subsequent releases, modifications, and fix packs, until otherwise indicated in new editions. This guide applies to the following programs: v IBM 32-bit SDK for AIX, Java Technology Edition, Version 7 Release 1 v IBM 64-bit SDK for AIX, Java Technology Edition, Version 7 Release 1 Portions © Copyright 1997, 2018, Oracle and/or its affiliates. © Copyright IBM Corporation 2011, 2018. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Preface .............. vii CORBA .............. 113 RMI and RMI-IIOP .......... 114 Chapter 1. Product overview ...... 1 Java IDL or RMI-IIOP? ......... 114 RMI-IIOP limitations .......... 114 Introduction .............. 1 Examples of client–server applications .... 115 IBM Software Developers Kit (SDK) ..... 2 Using the ORB ............ 119 Runtime Environment .......... 4 How the ORB works .......... 121 J9 Virtual Machine (JVM) ......... 6 Additional features of the ORB ...... 129 What's new ............... 6 The Java Native Interface (JNI) ....... 132 First release.............. 7 Overview of JNI ........... 132 Service refresh 1 ............ 9 The JNI and the Garbage Collector ..... 133 Service refresh 2 ............ 10 Copying and pinning.......... 138 Service refresh 3 ............ 13 Handling exceptions .......... 139 Service refresh 4 ............ 15 Synchronization ........... 140 Packed object evaluation technology ...... 16 Debugging the JNI .......... 140 Packed objects ............ 16 JNI checklist............. 142 Conventions and terminology ........ 62 Other sources of information ........ 64 Accessibility .............. 64 Chapter 3. Planning......... 143 Migrating from earlier releases of the IBM SDK, Chapter 2. Understanding the Java Technology Edition .......... 143 components ............ 65 Version compatibility ........... 145 Supported environments ......... 146 The building blocks of the IBM Virtual Machine for Additional information for AIX ....... 146 Java ................. 65 Java application stack .......... 66 Chapter 4. Installing and configuring Components of the IBM Virtual Machine for Java 67 Memory management ........... 69 the SDK and Runtime Environment .. 149 Overview of memory management ..... 69 Installing from an InstallAnywhere package ... 150 Allocation .............. 71 Completing an attended installation ..... 150 Detailed description of global garbage collection 74 Completing an unattended installation .... 151 Generational Concurrent Garbage Collector... 83 Interrupted installation ......... 152 Balanced Garbage Collection policy ..... 84 Known issues and limitations ....... 153 Metronome Garbage Collection policy .... 91 Relocating an installp package........ 153 How to do heap sizing ......... 92 Upgrading the SDK ........... 153 Interaction of the Garbage Collector with Verification .............. 154 applications ............. 94 Setting the path ............ 155 How to coexist with the Garbage Collector ... 95 Setting the class path ........... 155 Frequently asked questions about the Garbage Updating your SDK or runtime environment for Collector .............. 98 Daylight Saving Time changes........ 156 Class loading ............. 101 The parent-delegation model ....... 102 Chapter 5. Developing Java Namespaces and the runtime package .... 103 applications ............ 157 Custom class loaders .......... 103 Using XML .............. 157 Class data sharing ............ 104 Migrating to the XL-TXE-J ........ 159 The JIT compiler ............ 105 Securing Java API for XML processing (JAXP) JIT compiler overview ......... 105 against malformed input ........ 161 How the JIT compiler optimizes code .... 106 XML reference information ........ 162 Frequently asked questions about the JIT Debugging Java applications ........ 166 compiler .............. 108 Java Debugger (JDB) .......... 167 The AOT compiler............ 109 Determining whether your application is running Java Remote Method Invocation ....... 110 on a 32-bit or 64-bit JVM ......... 168 The RMI implementation ........ 110 Porting Java applications to 64-bit systems ... 168 Thread pooling for RMI connection handlers .. 111 General porting considerations ...... 168 Understanding distributed garbage collection 111 Porting native code from 32-bit to 64-bit systems 171 Debugging applications involving RMI .... 112 JNI considerations ........... 172 The ORB ............... 112 Usage of the JNI interface ........ 174 © Copyright IBM Corp. 2011, 2018 iii JVMPI and JVMDI interfaces ....... 174 More effective heap usage using compressed How the JVM processes signals ....... 175 references ............. 216 Signals used by the JVM ........ 175 Pause time ............. 216 Linking a native code driver to the Pause time reduction .......... 217 signal-chaining library ......... 177 Environments with very full heaps ..... 218 Writing JNI applications .......... 178 Using the Metronome Garbage Collector ... 218 Supported compilers .......... 178 Dynamic Logical Partitioning (DLPAR) support 225 JNI compatibility ........... 178 Live application mobility on AIX WPAR .... 226 JNI runtime linking .......... 179 Using the IPv6 extensions ......... 227 Example of using AIX shared libraries .... 182 Support for bidirectional data ........ 227 Support for thread-level recovery of blocked Special Arabic characters ........ 228 connectors .............. 183 Known limitations........... 230 CORBA support ............ 184 Euro symbol support ........... 230 System properties for tracing the ORB .... 185 Scaling support............. 230 System properties for tuning the ORB .... 185 Configuring large page memory allocation ... 231 Java security permissions for the ORB .... 186 SDK use of AIX large program support..... 232 ORB implementation classes ....... 186 Automatic LDR_CNTRL=MAXDATA values .. 232 RMI over IIOP ............. 187 Manual LDR_CNTRL=MAXDATA values ... 234 RMI-IIOP Programmer's Guide ...... 187 System resource limits and the ulimit command 235 Implementing the Connection Handler Pool for AIX Stack Execution Disable ........ 236 RMI ................ 194 AIX native threads ........... 194 Chapter 8. Performance ....... 239 Developing Java applications ........ 194 Class data sharing between JVMs ...... 239 Support for XToolkit ........... 194 Overview of class data sharing ...... 239 Support for the Java Attach API ....... 195 Class data sharing command-line options ... 241 The Data Access Accelerator Library...... 197 Creating, populating, monitoring, and deleting a cache ............... 242 Chapter 6. Plug-in, Applet Viewer and Performance and memory consumption ... 243 Web Start ............. 201 Considerations and limitations of using class Using the Java plug-in .......... 201 data sharing ............. 243 Supported browsers .......... 201 Adapting custom class loaders to share classes 246 Installing the Java plug-in ........ 202 | Enabling hardware compression acceleration on Changing the properties of the Java Plug-in .. 202 | Power Systems ............. 246 Common Document Object Model (DOM) Performance problems .......... 247 support .............. 202 Using DBCS parameters ......... 203 Chapter 9. Security ......... 249 Working with applets .......... 203 Security considerations .......... 249 Running and debugging applets with the Security components and tools ....... 251 Applet Viewer ............ 203 Java Applet Viewer and the classpath .... 204 Chapter 10. Troubleshooting and Using Web Start ............ 204 support .............. 253 Running Web Start .......... 205 Submitting problem reports ........ 253 WebStart Secure Static Versioning...... 206 Problem determination .......... 253 Distributing Java applications ........ 206 First steps in problem determination .... 253 AIX problem determination ....... 255 Chapter 7. Running Java applications 207 NLS problem determination ....... 291 The java and javaw commands ....... 207 ORB problem determination ....... 293 Obtaining version information....... 207 | Hardware compression acceleration issues on Specifying Java options and system properties 209 | Power Systems ............ 307 Standard options ........... 209 Attach API problem determination ..... 308 Globalization of the java command ..... 210 Using diagnostic tools .......... 312 Working with the LIBPATH environment variable 211 Overview of the available diagnostic tools... 312 Working with the LDR_CNTRL environment variable 212 Using the IBM Monitoring and Diagnostic Tools 319 The Just-In-Time (JIT) compiler ....... 213 Using dump agents .......... 321 Disabling the JIT ........... 213 Using Javadump ........... 340 Enabling the JIT ........... 214 Using Heapdump ........... 363 Determining whether the JIT is enabled ... 214 Using system dumps and the dump viewer .. 373 Specifying a garbage collection policy ..... 214 Tracing Java applications and the JVM .... 393 Garbage collection options ........ 215 JIT and AOT problem determination .... 430 IBM Support Assistant Data Collector .... 436 iv IBM SDK, Java Technology Edition, Version 7 Release 1: AIX User Guide Garbage Collector
Recommended publications
  • Thriving in a Crowded and Changing World: C++ 2006–2020

    Thriving in a Crowded and Changing World: C++ 2006–2020

    Thriving in a Crowded and Changing World: C++ 2006–2020 BJARNE STROUSTRUP, Morgan Stanley and Columbia University, USA Shepherd: Yannis Smaragdakis, University of Athens, Greece By 2006, C++ had been in widespread industrial use for 20 years. It contained parts that had survived unchanged since introduced into C in the early 1970s as well as features that were novel in the early 2000s. From 2006 to 2020, the C++ developer community grew from about 3 million to about 4.5 million. It was a period where new programming models emerged, hardware architectures evolved, new application domains gained massive importance, and quite a few well-financed and professionally marketed languages fought for dominance. How did C++ ś an older language without serious commercial backing ś manage to thrive in the face of all that? This paper focuses on the major changes to the ISO C++ standard for the 2011, 2014, 2017, and 2020 revisions. The standard library is about 3/4 of the C++20 standard, but this paper’s primary focus is on language features and the programming techniques they support. The paper contains long lists of features documenting the growth of C++. Significant technical points are discussed and illustrated with short code fragments. In addition, it presents some failed proposals and the discussions that led to their failure. It offers a perspective on the bewildering flow of facts and features across the years. The emphasis is on the ideas, people, and processes that shaped the language. Themes include efforts to preserve the essence of C++ through evolutionary changes, to simplify itsuse,to improve support for generic programming, to better support compile-time programming, to extend support for concurrency and parallel programming, and to maintain stable support for decades’ old code.
  • Defining the Undefinedness of C

    Defining the Undefinedness of C

    Technical Report: Defining the Undefinedness of C Chucky Ellison Grigore Ros, u University of Illinois {celliso2,grosu}@illinois.edu Abstract naturally capture undefined behavior simply by exclusion, be- This paper investigates undefined behavior in C and offers cause of the complexity of undefined behavior, it takes active a few simple techniques for operationally specifying such work to avoid giving many undefined programs semantics. behavior formally. A semantics-based undefinedness checker In addition, capturing the undefined behavior is at least as for C is developed using these techniques, as well as a test important as capturing the defined behavior, as it represents suite of undefined programs. The tool is evaluated against a source of many subtle program bugs. While a semantics other popular analysis tools, using the new test suite in of defined programs can be used to prove their behavioral addition to a third-party test suite. The semantics-based tool correctness, any results are contingent upon programs actu- performs at least as well or better than the other tools tested. ally being defined—it takes a semantics capturing undefined behavior to decide whether this is the case. 1. Introduction C, together with C++, is the king of undefined behavior—C has over 200 explicitly undefined categories of behavior, and A programming language specification or semantics has dual more that are left implicitly undefined [11]. Many of these duty: to describe the behavior of correct programs and to behaviors can not be detected statically, and as we show later identify incorrect programs. The process of identifying incor- (Section 2.6), detecting them is actually undecidable even rect programs can also be seen as describing which programs dynamically.
  • Automatic Detection of Unspecified Expression Evaluation in Freertos Programs

    Automatic Detection of Unspecified Expression Evaluation in Freertos Programs

    IT 14 022 Examensarbete 30 hp Juni 2014 Automatic Detection of Unspecified Expression Evaluation in FreeRTOS Programs Shahrzad Khodayari Institutionen för informationsteknologi Department of Information Technology . ... ... .... . . .. . . Acknowledgements This is a master thesis submitted in Embedded Systems to Department of Information Technology, Uppsala University, Uppsala, Sweden. I would like to express my deepest gratitude to my suppervisor Philipp Rümmer, Programme Director for Master’s programme in Embedded System at Uppsala University, for his patience in supporting continuously and generously guiding me with this project. I would like to appriciate professor Bengt Jonsson for reviewing my master thesis and offering valuable suggestions and comments. I would like to thank professor Daniel Kroening for helping me and providing updates of CBMC. Sincere thanks to my husband and my incredible parents who gave me courage and support throughout the project. Contents 1 Introduction..........................................................................................................1 Contributions.................................................................................................................3 Structure of the thesis report..........................................................................................3 2 Background...........................................................................................................5 2.1 Verification..............................................................................................................5
  • Lenient Execution of C on a JVM How I Learned to Stop Worrying and Execute the Code

    Lenient Execution of C on a JVM How I Learned to Stop Worrying and Execute the Code

    Lenient Execution of C on a JVM How I Learned to Stop Worrying and Execute the Code Manuel Rigger Roland Schatz Johannes Kepler University Linz, Austria Oracle Labs, Austria [email protected] [email protected] Matthias Grimmer Hanspeter M¨ossenb¨ock Oracle Labs, Austria Johannes Kepler University Linz, Austria [email protected] [email protected] ABSTRACT that rely on undefined behavior risk introducing bugs that Most C programs do not strictly conform to the C standard, are hard to find, can result in security vulnerabilities, or and often show undefined behavior, e.g., on signed integer remain as time bombs in the code that explode after compiler overflow. When compiled by non-optimizing compilers, such updates [31, 44, 45]. programs often behave as the programmer intended. However, While bug-finding tools help programmers to find and optimizing compilers may exploit undefined semantics for eliminate undefined behavior in C programs, the majority more aggressive optimizations, thus possibly breaking the of C code will still contain at least some occurrences of non- code. Analysis tools can help to find and fix such issues. Alter- portable code. This includes unspecified and implementation- natively, one could define a C dialect in which clear semantics defined patterns, which do not render the whole program are defined for frequent program patterns whose behavior invalid, but can still cause surprising results. To address would otherwise be undefined. In this paper, we present such this, it has been advocated to come up with a more lenient a dialect, called Lenient C, that specifies semantics for behav- C dialect, that better suits the programmers' needs and ior that the standard left open for interpretation.
  • C/C++ Coding Standard Recommendations for IEC 61508

    C/C++ Coding Standard Recommendations for IEC 61508

    C/C++ Coding Standard Recommendations for IEC 61508 Version V1, Revision R2 Feb 23, 2011 CONFIDENTIAL INFORMATION © exida Consulting LLC exida c c++ coding standard - iec61508.doc, Feb 23, 2011 Mike Medoff - John Grebe Page 1 of 18 CONFIDENTIAL INFORMATION Table of Contents 1. C/C++ Source Code Standard ................................................................................... 3 1.1 Introduction ..................................................................................................................... 3 1.1.1 Purpose and Scope ..............................................................................................3 1.1.2 Standards used ....................................................................................................4 2. Background ................................................................................................................ 4 2.1 IEC 61508 Requirements ................................................................................................4 2.2 C/C++ Programming languages compared to IEC 61508 language selection requirements ........................................................................................................................................ 5 2.2.1 IEC 61508 language selection requirements ....................................................... 5 2.2.2 Gap Analysis ........................................................................................................6 2.3 Knowledge of typical Coding Errors Made by C/C++ Programmers ..............................
  • High Integrity C++ Version

    High Integrity C++ Version

    Coding Standard Version 4.0 www.codingstandard.com 3 October 2013 Programming Research Ltd Mark House - 9/11 Queens Road - Hersham - Surrey KT12 5LU - United Kingdom Tel: +44 (0) 1932 888 080 - Fax: +44 (0) 1932 888 081 [email protected] www.programmingresearch.com Registered in England No. 2844401 © 2013 Programming Research Ltd Contents Contents 0 Introduction 7 0.1 Typographical Conventions.........................................7 0.2 Escalation policy...............................................7 0.3 Base Standard and Policy..........................................8 0.3.1 ISO Standard C++..........................................8 0.3.2 Statically detectable restrictions...................................8 0.3.3 Examples...............................................8 0.4 Basis of requirements............................................8 0.5 Rule Enforcement..............................................8 0.6 Deviations...................................................9 0.7 Glossary....................................................9 1 General 10 1.1 Implementation compliance......................................... 10 1.1.1 Ensure that code complies with the 2011 ISO C++ Language Standard............ 10 1.2 Redundancy................................................. 10 1.2.1 Ensure that all statements are reachable............................. 10 1.2.2 Ensure that no expression or sub-expression is redundant.................... 11 1.3 Deprecated features............................................. 12 1.3.1 Do not
  • Security in Programming Languages Security in Programming Languages

    Security in Programming Languages Security in Programming Languages

    Security in programming languages Security in programming languages • Languages have long been related to security. • Modern languages should contribute to security: – Constructs for protection (e.g., objects). – Techniques for static analysis, in particular for ensuring safety by typechecking. – A tractable theory, with sophisticated methods. • Several security techniques rely on language ideas, with static and dynamic checks. See Morris’s “Protection in Programming Languages”. A class with a secret field class C { • A possible conjecture: Any two instances of this // the field class are observationally private int x; equivalent (that is, they // a constructor cannot be distinguished public C(int v) { x = v; } within the language). } • More realistic examples use constructs similarly. • Objects are unforgeable. // two instances of C E.g., integers cannot be C c1 = new C(17); cast into objects. C c2 = new C(28); Mediated access [example from A. Kennedy] class Widget {// No checking of argument virtual void Operation(string s) {…}; } class SecureWidget : Widget { // Validate argument and pass on // Could also authenticate the caller override void Operation(string s) { Validate(s); base.Operation(s); } } … SecureWidget sw = new SecureWidget(); sw.Operation(“Nice string”); // Can’t avoid validation of argument Some application areas Avoiding or detecting Using language constructs to implementation flaws embody policies • Various static analyses (e.g., • Data abstraction for for C programs). protecting private state. • High-level languages with • Objects for capabilities. automatic memory • Method calls enriched with management (e.g., Java). security semantics (as in • Typed assembly and stack inspection). intermediate languages; • Information-flow control proof-carrying code. (e.g., in Jif). Other aspects of language-based security • Secure coding practices.
  • The Java™ Language Specification Java SE 7 Edition

    The Java™ Language Specification Java SE 7 Edition

    The Java™ Language Specification Java SE 7 Edition James Gosling Bill Joy Guy Steele Gilad Bracha Alex Buckley Copyright © 1997, 2011, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Duke logo™ designed by Joe Palrang. LIMITED LICENSE GRANTS 1. License for Evaluation Purposes. Oracle hereby grants you a fully-paid, non-exclusive, non-transferable, worldwide, limited license (without the right to sublicense), under Oracle's applicable intellectual property rights to view, download, use and reproduce the Specification only for the purpose of internal evaluation. This includes (i) developing applications intended to run on an implementation of the Specification, provided that such applications do not themselves implement any portion(s) of the Specification, and (ii) discussing the Specification with any third party; and (iii) excerpting brief portions of the Specification in oral or written communications which discuss the Specification provided that such excerpts do not in the aggregate constitute a significant portion of the Specification. 2. License for the Distribution of Compliant Implementations. Oracle also grants you a perpetual, non-exclusive, non-transferable, worldwide, fully paid-up, royalty free, limited license (without the right to sublicense) under any applicable copyrights or, subject to the provisions of subsection 4 below, patent rights it may have covering the Specification to create and/or
  • Lenient Execution of C on a Java Virtual Machine Or: How I Learned to Stop Worrying and Run the Code

    Lenient Execution of C on a Java Virtual Machine Or: How I Learned to Stop Worrying and Run the Code

    Lenient Execution of C on a Java Virtual Machine or: How I Learned to Stop Worrying and Run the Code Manuel Rigger Roland Schatz Johannes Kepler University Linz, Austria Oracle Labs, Austria [email protected] [email protected] Matthias Grimmer Hanspeter Mössenböck Oracle Labs, Austria Johannes Kepler University Linz, Austria [email protected] [email protected] ABSTRACT optimization and may lead to machine code that does not behave as Most C programs do not conform strictly to the C standard, and expected. Consequently, programs that rely on undefined behavior often show undefined behaviors, for instance, in the case of signed may introduce bugs that are hard to find, can result in security integer overflow. When compiled by non-optimizing compilers, vulnerabilities, or remain as time bombs in the code that explode such programs often behave as the programmer intended. However, after compiler updates [34, 51, 52]. optimizing compilers may exploit undefined semantics to achieve While bug-finding tools help programmers to find and eliminate more aggressive optimizations, possibly breaking the code in the undefined behavior in C programs, the majority of C programs process. Analysis tools can help to find and fix such issues. Alter- will still contain at least some non-portable code. This includes natively, a C dialect could be defined in which clear semantics are unspecified and implementation-defined patterns, which donot specified for frequently occurring program patterns with otherwise render the whole program invalid, but can cause unexpected results. undefined behaviors. In this paper, we present Lenient C, a C dialect Specifying a more lenient C dialect that better suits programmers’ that specifies semantics for behaviors left open for interpretation in needs and addresses common programming mistakes has been the standard.
  • RH850 Coding Target Device RH850 Family

    RH850 Coding Target Device RH850 Family

    User's Manual CubeSuite+ V2.01.00 Integrated Development Environment User's Manual: RH850 Coding Target Device RH850 Family All information contained in these materials, including products and product specifications, represents information on the product at the time of publication and is subject to change by Renesas Electronics Corp. without notice. Please review the latest information published by Renesas Electronics Corp. through various means, including the Renesas Electronics Corp. website (http://www.renesas.com). www.renesas.com Rev.1.01 Sep 2013 Notice 1. Descriptions of circuits, software and other related information in this document are provided only to illustrate the operation of semiconductor products and application examples. You are fully responsible for the incorporation of these circuits, software, and information in the design of your equipment. Renesas Electronics assumes no responsibility for any losses incurred by you or third parties arising from the use of these circuits, software, or information. 2. Renesas Electronics has used reasonable care in preparing the information included in this document, but Renesas Electronics does not warrant that such information is error free. Renesas Electronics assumes no liability whatsoever for any damages incurred by you resulting from errors in or omissions from the information included herein. 3. Renesas Electronics does not assume any liability for infringement of patents, copyrights, or other intellectual property rights of third parties by or arising from the use of Renesas Electronics products or technical information described in this document. No license, express, implied or otherwise, is granted hereby under any patents, copyrights or other intellectual property rights of Renesas Electronics or others.
  • Man Pages Section 5 Standards Environments and Macros

    Man Pages Section 5 Standards Environments and Macros

    man pages section 5: Standards, Environments, and Macros Part No: 821–1474–10 November 2011 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract,and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.
  • Undefined Behavior Is Not an Error

    Undefined Behavior Is Not an Error

    Undefined Behavior is Not an Error Barbara Geller & Ansel Sermersheim CppCon - Sept 2018 Introduction ● Prologue ● Terminology ● What is Undefined Behavior ● Why Study Undefined Behavior ● Defined Undefined Behavior ● Undefined Behavior is Not an Error ● Sequences ● Undocumented Behavior ● Undocumented Undefined Behavior ● Avoiding Undefined Behavior 2 Who is CopperSpice ● Maintainers and Co-Founders of the following projects ○ CopperSpice ■ set of cross platform C++ libraries (linux, os x, windows) ○ DoxyPress ■ documentation program for multiple languages and outputs ○ CsString ■ support for UTF-8 and UTF-16, extensible to other encodings ○ CsSignal ■ thread aware signal / slot library ○ libGuarded ■ library which manages access to data shared between threads 3 Who is CopperSpice ● Credentials ○ products leverage modern C++ idioms ○ all of our libraries and applications are open source ○ source code hosted on github ○ experience spans multiple platforms and languages ○ active video series teaching C++ with over 30 videos ○ copperspice is an expanding team ■ C++ developers world wide ■ technical documentation reviewers ■ test and quality assurance contributors ■ slack channel for team communication 4 Undefined Behavior ● Prologue ○ what does undefined behavior represent for a compiler developer ■ fascinating and intriguing theoretical discussion ■ possible masters degree subject for a compiler designer ■ influences the way they write an optimizer ○ should I study compilers to learn undefined behavior ■ looking at undefined behavior the