The java class file format is well documented. Basically one pointer to the runtime class of the object followed by the object.<div><br></div><div>If a given language is reference counted each object has one extra atomic field to count references.</div><div><br></div><div>If a given language does not have objects but instead uses maps (that repeat the fields evey instance) that is going to be a more large object in memory.</div><div><br></div><div>While i am not a large expert in this i believe javas approach is like a c struct with the exception the first word size bytes are a pointer to the type of class so that instances can be runtime inspected.</div><div><br></div><div>Java also has a very clever system for compressing 64 bit pointers.. see compressedOOPs option. I have not heard much of this optimization anywhere else.</div><div><br>On Thursday, April 28, 2016, Sujit K M <<a href="mailto:kmsujit@gmail.com">kmsujit@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Anecdotal. Keep in mind I have tested this and you can create 'a lot more<br>
> objects' given the same RAM than many other popular non java languages. :)<br>
<br>
Could you please clarify further? I mean does it involve a object size<br>
on the JVM.<br>
How to measure the size occupied by the Object? How much extra space the JVM<br>
needs? What is JDK Feature that Let's you claim this?<br>
<br>
I have serious questions regarding this claim. As Interpreted or JIT<br>
compiled languages<br>
should in reality occupy more space.<br>
<br>
><br>
> On Wed, Apr 27, 2016 at 4:13 PM, Pete Wright <<a href="javascript:;" onclick="_e(event, 'cvml', 'pete@nomadlogic.org')">pete@nomadlogic.org</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On 04/26/2016 03:56 AM, Brian Coca wrote:<br>
>>><br>
>>> As many a Java dev has told me: "the only problem is that you did not<br>
>>> install enough RAM, just add it, it's cheap!"<br>
>>><br>
>>><br>
>><br>
>> and therein is the issue - in practice i've found that by adding more<br>
>> memory to a JVM heap will tend to worsen GC pauses, especially for latency<br>
>> sensitive operations.  then you get to do all sorts of fun stuff like<br>
>> storing cached objects outside of the JVM or lord knows what.<br>
>><br>
>> i spent about 3 months trying to help a team tune their java app when they<br>
>> noticed it would periodically show latencies of several seconds. they kept<br>
>> adding more memory to the heap, which made things worse.  once we turned on<br>
>> debugging metrics for GC it became painfully apparent that due to the huge<br>
>> heap that they had allocated GC was taking ages to complete and stopping to<br>
>> world in the process.  good times :)<br>
>><br>
>> -pete<br>
>><br>
>> --<br>
>> Pete Wright<br>
>> <a href="javascript:;" onclick="_e(event, 'cvml', 'pete@nomadlogic.org')">pete@nomadlogic.org</a><br>
>><br>
>> _______________________________________________<br>
>> talk mailing list<br>
>> <a href="javascript:;" onclick="_e(event, 'cvml', 'talk@lists.nycbug.org')">talk@lists.nycbug.org</a><br>
>> <a href="http://lists.nycbug.org/mailman/listinfo/talk" target="_blank">http://lists.nycbug.org/mailman/listinfo/talk</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> talk mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'talk@lists.nycbug.org')">talk@lists.nycbug.org</a><br>
> <a href="http://lists.nycbug.org/mailman/listinfo/talk" target="_blank">http://lists.nycbug.org/mailman/listinfo/talk</a><br>
<br>
_______________________________________________<br>
talk mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'talk@lists.nycbug.org')">talk@lists.nycbug.org</a><br>
<a href="http://lists.nycbug.org/mailman/listinfo/talk" target="_blank">http://lists.nycbug.org/mailman/listinfo/talk</a><br>
</blockquote></div><br><br>-- <br>Sorry this was sent from mobile. Will do less grammar and spell check than usual.<br>