🚀 go-pugleaf

>the heap?". I have looked into the VM documents but found nothing about 
>this because it is undefined. - So does somebody know about what the 
>real practice is? Or where can I go to look for more information?
>
The real practice is that in Java you don't care.

Java != C 
In C you care because you have to deallocate that exact amount of space when you destroy the memory structure, in Java that's handled under the hood.

Jeroen Wenting wrote:
>>the heap?". I have looked into the VM documents but found nothing about 
>>this because it is undefined. - So does somebody know about what the 
>>real practice is? Or where can I go to look for more information?
>>
> 
> The real practice is that in Java you don't care.
> 
> Java != C 
> In C you care because you have to deallocate that exact amount of space when you destroy the memory structure, in Java that's handled under the hood.

I must disagree!
Proper knowledge of execution habits of your system will benefit the 
design of your algorithms. Under some circumstance this may entail 
dramatic differences up to the point which decide whether your 
application works or not. Memory is never unlimited!

Vander wrote:

> I want to assess some implementation details, some which can be 
> expected to be common among the major VM implemetatons (for default I
>  am referring to the Win32 implementation).
> 
> A good programmer is interested to know what he really invokes when 
> allocating a new object. For example the minimum data size that an 
> instance of a type consumes on the heap. Perhaps the question can be
>  transformed into "what is the minimum size of data allocation blocks
>  on the heap?". I have looked into the VM documents but found nothing
>  about this because it is undefined. - So does somebody know about 
> what the real practice is? Or where can I go to look for more 
> information?
> 
> Thanks! - Vander

1.  You really do not need to know this stuff, unless you are working
with embedded systems.  And if you are working with embedded systems,
then you would have all the documentation you needed already.

2.  But, if you insist, there are lots of tools to help you profile your
application.  If you are using Developer or Enterprise edition, you will
already have a built-in copy of OptimizeIt, so I suggest you use that.
If you are using Foundation, you will want to check out some freebies.
I found this page which is only 6 months old, so it should be up to date:

http://www.manageability.org/blog/stuff/open-source-profilers-for-java/view

Last, but not least, let me inflict MHO on you... DON'T optimize for the
sake of optimizing.  Define some reasonable metrics, figure out how to
test against those metrics, and then DON'T bother optimizing until those
tests start to fail.  Otherwise you'll just be screwing around wasting a
bunch of time.

-- 

Regards,

Lori Olson [TeamB]

------------

Save yourself, and everyone else, some time and search the
newsgroups and the FAQ-O-Matic before posting your next
question.

Google Advanced Newsgroup Search
     http://www.google.ca/advanced_group_search
Other Newsgroup Searches:
     http://www.borland.com/newsgroups/ngsearch.html
Joi Ellis's FAQ-O-Matic:
     http://www.visi.com/~gyles19/fom-serve/cache/1.html

Lori M Olson [TeamB] wrote:
> Vander wrote:
> 
>> I want to assess some implementation details, some which can be 
>> expected to be common among the major VM implemetatons (for default I
>>  am referring to the Win32 implementation).
>>
>> A good programmer is interested to know what he really invokes when 
>> allocating a new object. For example the minimum data size that an 
>> instance of a type consumes on the heap. Perhaps the question can be
>>  transformed into "what is the minimum size of data allocation blocks
>>  on the heap?". I have looked into the VM documents but found nothing
>>  about this because it is undefined. - So does somebody know about 
>> what the real practice is? Or where can I go to look for more 
>> information?
>>
>> Thanks! - Vander
> 
> 
> 1.  You really do not need to know this stuff, unless you are working
> with embedded systems.  And if you are working with embedded systems,
> then you would have all the documentation you needed already.
> 
> 2.  But, if you insist, there are lots of tools to help you profile your
> application.  If you are using Developer or Enterprise edition, you will
> already have a built-in copy of OptimizeIt, so I suggest you use that.
> If you are using Foundation, you will want to check out some freebies.
> I found this page which is only 6 months old, so it should be up to date:
> 
> http://www.manageability.org/blog/stuff/open-source-profilers-for-java/view
> 
> Last, but not least, let me inflict MHO on you... DON'T optimize for the
> sake of optimizing.  Define some reasonable metrics, figure out how to
> test against those metrics, and then DON'T bother optimizing until those
> tests start to fail.  Otherwise you'll just be screwing around wasting a
> bunch of time.
> 

I don't think I'm wasting time if I want to know what the minimum object 
size is, as a background information to decide on algorithmic 
alternatives. But thanks for the hint, perhaps I'm on the right track there.

Btw, I wonder what makes people so blindly proud about the Java memory 
management. The system has a rather dangerous memory consumption and not 
rare an application gets problems with the out-of-memory message. Just a 
side-note!

- Vander

Vander wrote:

> Btw, I wonder what makes people so blindly proud about the Java memory 
> management. The system has a rather dangerous memory consumption and not 
> rare an application gets problems with the out-of-memory message. Just a 
> side-note!

Well, who says anyone's proud or blind or both?

I'll tell you why I don't worry about it:

I have to get some work done.

The size of a Java object is trivia compared to
the problems we face every day on our jobs.  Were
I at the university, and wondering about navels
and object sizes; I'd be thrilled.  Right now,
I'm having a panic attack fixing a Perl-based
Web app!  (Yes, I said Perl in a JBuilder newsgroup.)
It makes spaghetti look well-ordered.  Now if
you want a crusade, go after Perl and blind pride.


-- 


Paul Furbacher (TeamB)

   Save time, search the archives:
        http://www.borland.com/newsgroups/ngsearch.html

   Is it in Joi Ellis's Faq-O-Matic?
        http://www.visi.com/~gyles19/fom-serve/cache/1.html

   Finally, please send responses to the newsgroup only.
   That means, do not send email directly to me.
   Thank you.

Vander wrote:

> Btw, I wonder what makes people so blindly proud about the Java memory 
> management. 

I don't know about "proud", but it definitely beats spending hours with 
valgrind on a heavily threaded program, going "*@&#^$" every time it 
core-dumps because valgrind gets confused about the thread stacks after 
a thread kill, all to track down a 4-byte (x100000) leak.

Fortunately, our main platform is pure Java, and our productivity (and 
platform stability) has been phenomenal compared to that with classic 
C/C++ development (from one of my recent jobs)..

> 
> Fortunately, our main platform is pure Java, and our productivity (and 
> platform stability) has been phenomenal compared to that with classic 
> C/C++ development (from one of my recent jobs)..

Certainly, I totally agree! That's why I am an enthusiastic Java 
programmer. - But why not try to be smart in handling with memory problems?

On 4/19/2005 at 5:25:31 AM, Vander wrote:

> I want to assess some implementation details, some which can be expected
> to be common among the major VM implemetatons (for default I am
> referring to the Win32 implementation).

This JavaWorld article should be of interest to you:

http://www.javaworld.com/javaworld/javatips/jw-javatip130.html

-- 
Regards,

John McGrath [TeamB]

---------------------------------------------------
Before sending me e-mail, please read:
    http://www.JPMcGrath.net/newsgroups/e-mail.html

John McGrath [TeamB] wrote:
> On 4/19/2005 at 5:25:31 AM, Vander wrote:
> 
> 
>>I want to assess some implementation details, some which can be expected
>>to be common among the major VM implemetatons (for default I am
>>referring to the Win32 implementation).
> 
> 
> This JavaWorld article should be of interest to you:
> 
> http://www.javaworld.com/javaworld/javatips/jw-javatip130.html
> 

Thank you so very much! - This article deals exactly with the topic, I 
would say even more: it is more than I expected. I recommend it to 
everybody.

I also hope this article has made the difference clearer between a 
versed system programmer and a language applicant. ;)

- Vander