<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi John,<br>
<br>
Thanks! Following are some more questions.<br>
<br>
I see CompressedStream uses UNSIGNED5 coding of Pack200. I tried to
google around for the UNSIGNED5 coding compression rate, but without
much luck. If you have any info on that, please share. I was trying
to find some usage examples in the VM code, but there seems no usage
of CompressedStream (except the sa agent java code). Do you have any
pointer?<br>
<br>
Thanks,<br>
Jiangli<br>
<br>
On 12/11/2012 05:02 PM, John Rose wrote:
<blockquote
cite="mid:7CC0EDC2-E909-47CF-A749-6B5CA5C5D728@oracle.com"
type="cite">
<div>
<div>On Dec 10, 2012, at 3:30 PM, Jiangli Zhou wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div text="#000000" bgcolor="#ffffff"> Hi John,<br>
<br>
Thanks a lot for looking at the change again and the field
compressing suggestion! I've looked into the FieldInfo array
and optimized the memory usage for the generic signature
index slot earlier this year. I haven't played with any
compression technique. Thanks for the suggestion, definitely
worth to look into. I have one question maybe you have quick
answer to it. Does C1 or C2 heavily relying on fast
accessing to the FieldInfo array?<br>
</div>
</blockquote>
</div>
<br>
<div>A couple of other bits...</div>
<div><br>
</div>
<div>I sketched more of a compact design during Alexsey's review:</div>
<div><br>
</div>
<div>On Dec 11, 2012, at 3:21 PM, John Rose wrote:</div>
<div><br class="Apple-interchange-newline">
<blockquote type="cite"><span class="Apple-style-span"
style="border-collapse: separate; font-family: Helvetica;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-indent: 0px; text-transform: none;
white-space: normal; widows: 2; word-spacing: 0px;
font-size: medium;">On Dec 11, 2012, at 5:06 AM, Aleksey
Shipilev wrote:<br>
<br>
<blockquote type="cite">
<blockquote type="cite">...The rework could use something
like your tagging<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">scheme (which is clever) but have
the exceptional tag value mean "I<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">have extended attributes specified
in N additional words of data".<br>
</blockquote>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">I think we have a little bit of
mis-design about FieldInfo here. What<br>
</blockquote>
<blockquote type="cite">allows me to piggyback on FieldInfo
is that we clearly have the<br>
</blockquote>
<blockquote type="cite">classload-scope (CS) metadata info
for fields, and runtime-scope (RS)<br>
</blockquote>
<blockquote type="cite">metadata info. That allows us to
mangle CS data during the classload,<br>
</blockquote>
<blockquote type="cite">knowing for sure we substitute that
with RS after classload finishes.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">This is probably a little dodgy when
compared against sparse<br>
</blockquote>
<blockquote type="cite">representation, but I feel
uncomfortable rebuilding entire field<br>
</blockquote>
<blockquote type="cite">attribute mechanics in the course of
@Contended work.<br>
</blockquote>
<br>
It's totally dodgy. It makes some sense if you are aiming
at an in-memory copy of the classfile AST, but is not
friendly to the JVM which is actually using the data. If I
were rewriting it, I would try to use a temporary FieldInfo
structure with a simple but non-dense layout, and a packing
phase which would put the necessary field metadata into a
dense streamable form, in an array<u1>, using
CompressedStream. The FieldStream would unpack each
successive field descriptor into the FieldInfo structure.
By using CompressedStream, the data structure would be
32-bit clean, leading to various other advantages.<br>
</span></blockquote>
</div>
<div><span class="Apple-style-span" style="border-collapse:
separate; font-family: Helvetica; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: 2; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; font-size: medium;"><br>
</span></div>
<div><span class="Apple-style-span" style="border-collapse:
separate; font-family: Helvetica; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: 2; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; font-size: medium;">In general, I think we
should make more systematic use of CompressedStream for
storing metadata that is not directly accessed by the
interpreter or compiled code.</span></div>
<div><br>
</div>
<div>Also, I did a quick and dirty "printf" based test for average
field-info array size. It suggests that about 30% of the
classes have one or more fields, and that of those classes, the
average array length is 36 (u2) elements. This is pretty small
potatoes, but it's of similar magnitude to the other bit-packing
changes to InstanceKlass, so maybe it's worth while. I
definitely think using CompressedStream in more places is
worthwhile, if we want to pack our metadata down tighter, and at
the same time move toward 32-bit clean representations.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>— John</div>
</blockquote>
<br>
</body>
</html>