<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Thank you Kris for the explain,<br>
BTW, Kris and I ever talked with Ramki about the idea and the GCIH implementation and since CMS is not on the rador he suggested to do some modifications on G1 to support static heap subsets and one CR was filed<br>
<pre>6660122 G1: support for large, mostly-static heap subsets</pre>
GCIH now has been adopted online, the hadoop team in taobao uses GCIH as an efficient way of sharing static Java objects(data dictionary) among JVM processes(Hadoop Map processses) on same physical machine which helps to achieve 10x performance gains.<br>
Regards,<br>
Joseph<br>
<br>
the write barrier <br>
于 2012-7-27 0:16, Krystal Mok 写道:<br>
</div>
<blockquote type="cite">Hi Leo,
<div><br>
</div>
<div>Thanks for being interested :-) I think it's time for Joseph to chime in, if he will.</div>
<div>I don't work for Taobao anymore; it's better if someone from the inside to share the details.</div>
<div><br>
</div>
<div>I could briefly cover the parts of the VM we touched. We tried a lot of variants, and not all of them are meant to be **safe**.</div>
<div><br>
</div>
<div>GCIH as it is only works with ParNew+CMS configuration. We modified all tracing actions that's involved in ParNew and CMS so that during GC it wouldn't trace into objects within GCIH. We also modified the pointer adjusting logic so that it would fix-up
object pointers (oops) originated from GCIH that point to moved objects.</div>
<div><br>
</div>
<div>Note that we actually only allow such pointers to be metadata pointers pointing into the PermGen; after the PermGen elimination project is done, such pointers wouldn't even exist anymore (but I'm not sure if the PermGen elimination project allows metadata
to move; it'd be nice for GCIH if metadata doesn't move).</div>
<div>Otherwise, the object graph in GCIH must be self-contained, i.e. all object pointers originating from GCIH should also point into GCIH. In addition, objects in GCIH don't move. So, no pointer fix-ups other than the metadata pointers are needed.</div>
<div><br>
</div>
<div>To enforce the invariant above, write-barriers also need to be modified. Note that this could impact the throughput of normal Java programs, so it'd be preferable if it could be turned off -- but we're talking about trading safety for performance here,
so umm...there really isn't a choice.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Kris</div>
<div><br>
<div class="gmail_quote">On Thu, Jul 26, 2012 at 11:43 PM, Leo Romanoff <span dir="ltr">
<<a href="mailto:romixlev@yahoo.com" target="_blank">romixlev@yahoo.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex; border-left:1px #ccc solid; padding-left:1ex">
<br>
Hi Kris,<br>
<br>
Thanks a lot for this link about GCIH and other JVM extensions done at<br>
Taobao. Very interesting!<br>
The GCIH use-cases are almost identical to what I had in mind.<br>
<div class="im"><br>
<br>
Krystal Mok wrote:<br>
><br>
> We made deep modifications to the HotSpot VM to implement the features. As<br>
> you stated, it's unlikely to implement such feature without modifying the<br>
> internals of the VM, at least with the current standard APIs.<br>
><br>
<br>
</div>
Very interesting. Is any general (or even better - detailed) information<br>
about those deep modifications available anywhere? It would be interesting<br>
to better understand which parts of the HotSpot are affected or impacted by<br>
such an extension and to which extent.<br>
<br>
Thanks again,<br>
Leo<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
View this message in context: <a href="http://old.nabble.com/Question-Extension-proposal%3A-references-to-off-heap-objects-and-support-for-multiple-heaps-tp34215852p34216295.html" target="_blank">
http://old.nabble.com/Question-Extension-proposal%3A-references-to-off-heap-objects-and-support-for-multiple-heaps-tp34215852p34216295.html</a><br>
</font></span>
<div class="HOEnZb">
<div class="h5">Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com.<br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you.<br>
<br>
本电邮(包括任何附件)可能含有机密资料并受法律保护。如您不是正确的收件人，请您立即删除本邮件。请不要将本电邮进行复制并用作任何其他用途、或透露本邮件之内容。谢谢。<br>
</font>
</body>
</html>