侯体宗的博客
  • 首页
  • Hyperf版
  • beego仿版
  • 人生(杂谈)
  • 技术
  • 关于我
  • 更多分类
    • 文件下载
    • 文字修仙
    • 群聊
    • 九宫格抽奖
    • 拼图
    • 消消乐
    • 相册

Java Hotspot: Remove the Permanent Generation

Java  /  管理员 发布于 3年前   208

openjdk上关于hotspot将移除永久带的描述非常详细,http://openjdk.java.net/jeps/122

 

JEP 122: Remove the Permanent GenerationAuthorJon MasamitsuOrganizationOracleCreated2010/8/15Updated2011/11/2TypeFeatureStatePostedComponentvm/gcScopeImplRFE6964458Internal-refsOracle:A360:682265Discussionhotspot dash dev at openjdk dot java dot netStart2010/Q3EffortXLDurationXLReviewed-byPaul HohenseeEndorsed-byPaul HohenseeSummaryRemove the permanent generation from the Hotspot JVM and thus the need to tune the size of the permanent generation.Non-GoalsExtending Class Data Sharing to application classes. Reducing the memory needed for class metadata. Enabling asynchronous collection of class metadata.Success MetricsClass metadata, interned Strings and class static variables will be moved from the permanent generation to either the Java heap or native memory.The code for the permanent generation in the Hotspot JVM will be removed.Application startup and footprint will not regress more than 1% as measured by a yet-to-be-chosen set of benchmarks.MotivationThis is part of the JRockit and Hotspot convergence effort. JRockit customers do not need to configure the permanent generation (since JRockit does not have a permanent generation) and are accustomed to not configuring the permanent generation.DescriptionMove part of the contents of the permanent generation in Hotspot to the Java heap and the remainder to native memory.Hotspot’s representation of Java classes (referred to here as class meta-data) is currently stored in a portion of the Java heap referred to as the permanent generation. In addition, interned Strings and class static variables are stored in the permanent generation. The permanent generation is managed by Hotspot and must have enough room for all the class meta-data, interned Strings and class statics used by the Java application. Class metadata and statics are allocated in the permanent generation when a class is loaded and are garbage collected from the permanent generation when the class is unloaded. Interned Strings are also garbage collected when the permanent generation is GC’ed.The proposed implementation will allocate class meta-data in native memory and move interned Strings and class statics to the Java heap. Hotspot will explicitly allocate and free the native memory for the class meta-data. Allocation of new class meta-data would be limited by the amount of available native memory rather than fixed by the value of -XX:MaxPermSize, whether the default or specified on the command line.Allocation of native memory for class meta-data will be done in blocks of a size large enough to fit multiple pieces of class meta-data. Each block will be associated with a class loader and all class meta-data loaded by that class loader will be allocated by Hotspot from the block for that class loader. Additional blocks will be allocated for a class loader as needed. The block sizes will vary depending on the behavior of the application. The sizes will be chosen so as to limit internal and external fragmentation. Freeing the space for the class meta-data would be done when the class loader dies by freeing all the blocks associated with the class loader. Class meta-data will not be moved during the life of the class.AlternativesThe goal of removing the need for sizing the permanent generation can be met by having a permanent generation that can grow. There are additional data structures that would have to grow with the permanent generation (such as the card table and block offset table). For an efficient implementation the permanent generation would need to look like one contiguous space with some parts that are not usable.TestingChanges in native memory usage will need to be monitored during testing to look for memory leaks.Risks and AssumptionsThe scope of the changes to the Hotspot JVM is the primary risk. Also identifying exactly what needs to be changed will likely only be determined during the implementation.This is a large project that affects all the garbage collectors extensively. Knowledge of the permanent generation and how it works exists in both the runtime and compiler parts of the hotspot JVM. Data structures outside of the garbage collectors will be changed to facilitate the garbage collector’s processing of the class meta-data in native memory.Some parts of the JVM will likely have to be reimplemented as part of this project. As an example class data sharing will be affected and may require reimplementation in whole or in part.Class redefinition is an area of risk. Redefinition relies on the garbage collection of class meta-data during the collection of the permanent generation (i.e., redefinition does not currently free classes that have been redefined so some means will be necessary to discover when the meta-data for classes that have been redefined can be freed).Moving interned Strings and class statics to the Java heap may result in an Out-of-memory exception or an increase in the number of GCs. Some adjustment of -Xmx by a user may be needed.With the UseCompressedOops option pointers to class meta-data (in the permanent generation) can be compressed in the same way as pointers into the Java heap. This yields a significant performance improvement (on the order of a few percent). Pointers to meta-data in native memory will be compressed in a similar manner but with a different implementation. This latter implementation may not be as high performance as compressing the pointers into the Java heap. The requirements of compressing the pointers to meta-data may put an upper limit on the size of the meta-data. For example if the implementation required all meta-data to be allocated below some address (for example below the 4g limit) that would limit the size of the meta-data.DependencesTools that know about the permanent generation will need to be reimplemented. The serviceability agent, jconsole, Java VisualVM and jhat are examples of tools that will be affected.ImpactOther JDK components: Tools that have knowledge of the permanent generation.Compatibility: Command line flags relating to the permanent generation will become obsolete.Documentation: References to the permanent generation will need to be removed.



  • 上一条:
    Java异常那些不得不说的事
    下一条:
    java web开发 高并发处理
  • 昵称:

    邮箱:

    0条评论 (评论内容有缓存机制,请悉知!)
    最新最热
    • 分类目录
    • 人生(杂谈)
    • 技术
    • linux
    • Java
    • php
    • 框架(架构)
    • 前端
    • ThinkPHP
    • 数据库
    • 微信(小程序)
    • Laravel
    • Redis
    • Docker
    • Go
    • swoole
    • Windows
    • Python
    • 苹果(mac/ios)
    • 相关文章
    • 在php8.0+版本中使用属性来增加值代码示例(0个评论)
    • java 正则表达式基础,实例学习资料收集大全 原创(0个评论)
    • java正则表达式彻底研究(0个评论)
    • java正则表达式验证函数(0个评论)
    • MVC、MVP和MVVM分别是什么(0个评论)
    • 近期文章
    • 在go语言中对Grpc工具buf.build使用流程步骤(0个评论)
    • 宝塔面板Nginx开启Brotli压缩流程步骤,提升网站加载速度(0个评论)
    • 在go语言中如何判断用户代理是否为移动设备的示例(0个评论)
    • 在go语言中实现一个函数来检查用户代理是否是机器人或爬虫的示例(0个评论)
    • Laravel 10.13版本发布(0个评论)
    • 在github创建task的同时创建分支流程步骤(0个评论)
    • 在go语言中以邮件标题中获取SPF和DMARC,来判断是否为垃圾邮件之垃圾邮件过滤器功能实现(0个评论)
    • 在go语言中使用attr字段标签提取XML属性数据示例(0个评论)
    • 在laravel中介绍一个生成假数据的PHP库:FakerPHP(0个评论)
    • 在laravel框架中对环境配置文件的加载过程步骤浅析(0个评论)
    • 近期评论
    • 博主 在

      2023年国务院办公厅春节放假通知:1月21日起休7天中评论 @ xiaoB 你只管努力,剩下的叫给天意;天若有情天亦老,..
    • xiaoB 在

      2023年国务院办公厅春节放假通知:1月21日起休7天中评论 会不会春节放假后又阳一次?..
    • BUG4 在

      你翻墙过吗?国内使用vpn翻墙可能会被网警抓,你需了解的事中评论 不是吧?..
    • 博主 在

      go语言+beego框架中获取get,post请求的所有参数中评论 @ t1  直接在router.go文件中配就ok..
    • Jade 在

      如何在MySQL查询中获得当月记录中评论 Dear zongscan.com team, We can skyroc..
    • 2016-11
    • 2018-03
    • 2020-03
    • 2023-05
    Top

    Copyright·© 2019 侯体宗版权所有· 粤ICP备20027696号 PHP交流群

    侯体宗的博客