是否可以从gc透视图标记不可收集的java对象以节省gc-sweep时间? [英] Is it possible to mark java objects non-collectable from gc perspective to save on gc-sweep time?

查看:121
本文介绍了是否可以从gc透视图标记不可收集的java对象以节省gc-sweep时间?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

是否可以从gc透视图标记不可收集的java对象以节省gc-sweep时间?

Is it possible to mark java objects non-collectable from gc perspective to save on gc-sweep time?

http://wwwasd.web.cern.ch/wwwasd /lhc++/Objectivity/V5.2/Java/guide/jgdStorage.fm.html ,特别是非垃圾收集容器那里(非垃圾收集?)。

Something along the lines of http://wwwasd.web.cern.ch/wwwasd/lhc++/Objectivity/V5.2/Java/guide/jgdStorage.fm.html and specifically non-garbage-collectible containers there (non-garbage-collectable?).

问题是我有很多普通的临时对象,但我有更大的(几个Gigs)对象存储用于缓存目的。没有理由,Java GC应该遍历所有那些试图找到要收集的内容的Cache千兆字节,因为它们包含有自己超时的缓存数据。

The problem is that I have lots of ordinary temporary objects, but I have even bigger (several Gigs) of objects that are stored for Cache purposes. For no reason should the Java GC traverse all those Cache gigabytes trying to find anything to collect, because they contain cached data which have their own timeouts.

这样我可以分区我的数据以自定义的方式进入无限生存和正常生活的对象,并且希望GC非常快,因为普通对象不能存活这么长时间并且数量较少。

This way I could partition my data in a custom way into infinite-lived and normal-lived objects, and hopefully GC would be quite fast because normal objects don't live so long and amount to smaller amounts.

此问题有一些解决方法,例如 Apache DirectMemory 和Commercial Terracotta BigMemory (http://terracotta.org/products/bigmemory),但java-native解决方案会更好(我的意思是免费,可能更可靠?)。此外,我想避免序列化开销,这意味着它应该在相同的jvm内发生。据我所知,DirectMemory和BigMemory主要运行 off heap ,这意味着必须将对象序列化/反序列化到jvm之外的内存中。简单地在jvm中标记非gc区域似乎是更好的解决方案。使用文件进行缓存也不是一种选择,它具有相同的无法承受的序列化/反序列化开销 - 用例是一个HA服务器,其中包含大量以随机(人工)顺序使用的数据并且需要低延迟。

There are some workarounds to this problem, such as Apache DirectMemory and Commercial Terracotta BigMemory(http://terracotta.org/products/bigmemory), but a java-native solution would be nicer (I mean free and probably more reliable?). Also I want to avoid serialization overhead which means it should happen within same jvm. To my understanding DirectMemory and BigMemory operate mainly off heap which means that the objects must be serialized/deserialized to/from memory outside jvm. Simply marking non-gc regions within the jvm would seem a better solution. Using Files for cache is not an option either, it has the same unaffordable serialization/deserialization overhead - use case is a HA server with lots of data used in random (human) order and low latency needed.

推荐答案


是否可以从gc透视图标记不可收集的java对象以节省gc-sweep时间?

Is it possible to mark java objects non-collectable from gc perspective to save on gc-sweep time?

不可能。

您可以通过保留对象来防止对象被垃圾收集可达,但GC仍然需要跟踪它们以检查每个完整的可达性; GC(至少)。

You can prevent objects from being garbage collected by keeping them reachable, but the GC will still need to trace them to check reachability on each full; GC (at least).


只是我的假设,当jvm挨饿时,它也开始扫描所有那些不必要的对象。

Is simply my assumption, that when the jvm is starving it begins scanning all those unnecessary objects too.

是的。那是正确的。但是,除非你有很多想要以这种方式对待的对象,否则开销很可能是微不足道的。 (无论如何,更好的想法是给JVM更多的内存......如果可能的话。)

Yes. That is correct. However, unless you've got LOTS of objects that you want to be treated this way, the overhead is likely to be insignificant. (And anyway, a better idea is to give the JVM more memory ... if that is possible.)

这篇关于是否可以从gc透视图标记不可收集的java对象以节省gc-sweep时间?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆