«

Lasse Reichstein Nielsen <> writes:

> Roedy Green <> writes:
>
>> On Sun, 04 Nov 2007 09:21:55 -0800, Knute Johnson
>> <> wrote, quoted or indirectly quoted
>> someone who said :
>>
>>>The coming JRE is going to have greatly improved startup performance.
>>>
>>>https://jdk6.dev.java.net/6uNea.html
>>
>> "The Quick Starter feature will prefetch portions of the JRE into
>> memory, substantially decreasing the average JRE cold start-up time
>> (the time that it takes to launch a Java application for the first
>> time after a fresh reboot of a PC)."
>>
>> Sounds like they are loading a pre-loaded RAM image to get the basic
>> classes going. Yea! I have been asking for this since day 1.
>
> That, or they are making yet another "QuickStart" that loads and takes
> up memory at boot time, whether you use it or not.
> It can sit next to Office QuickStart, Firefox Quickstart and
> a gazillion other programs that think they are so important that
> you have to start everything but the GUI every time you start
> your machine.

Ack, I was hoping I was wrong. And I was, although only slightly so:

"The fix, then, is for us to take advantage of the disk cache to make
sure that the memory pages on disk that we must read at startup have
already been loaded before we need them. How do we do this? We cannot
magically pre-load the pages just prioir to launching; unfortunately,
the VM currently lacks the ability to see into the future to detect
when the user will be launching Java (we would love to have this
feature in the future, but it is not yet present). But we can
pre-load at some earlier time, such as Windows boot or login
time. And we can keep the pages warm in the disk cache as machine and
memory conditions allow."

From <URL:http://weblogs.java.net/blog/chet/archive/2007/05/consumer_jre_le.html#Quickstarter>

They do load everything into memory, only cache memory instead of
program memory. And they then keep hitting the pages to ensure that
no cache algorithm gets to do its job.
That's just being egoistical. I bet every application wants to be
loaded from RAM. Well, at least I get to turn it off.
/L
--
Lasse Reichstein Nielsen -
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

writes:

> <OT> I am looking for a language that is as close to the metal as C++,
> yet has garbage collection, which I think is a better idea than manual
> mm. Any ideas? </OT>

Try C++.

No - I'm not joking. So-called "manual" memory management isn't half as
bad as Sun's marketing makes it out to be. Newer tools, libraries, and
design patterns have made manual new() and delete() calls a rarity. If
you think MM in C++ is entirely manual, or painful to use, then odds are
good that you're either misusing it, or haven't written any C++ in quite
a few years.

Don't get me wrong - I like Java, and use it regularly. But if what you
need is C++ with GC, then you can have precisely that.

sherm--

--
WV News, Blogging, and Discussion: http://wv-www.com
Cocoa programming in Perl: http://camelbones.sourceforge.net

On Nov 5, 7:30 pm, Sherman Pendley <spamt...@dot-app.org> wrote:
> boroph...@gmail.com writes:
> > <OT> I am looking for a language that is as close to the metal as C++,
> > yet has garbage collection, which I think is a better idea than manual
> > mm. Any ideas? </OT>
>
> Try C++.
>
> No - I'm not joking. So-called "manual" memory management isn't half as
> bad as Sun's marketing makes it out to be. Newer tools, libraries, and
> design patterns have made manual new() and delete() calls a rarity.

Perhaps, but are they as efficient as a language which has GC built in
and was designed to be GC'd. Are these C++ GC libraries just manual MM
hidden behind classes/templates, or do they truly support "proper"
GC. This question seems to be important, because I have read that GC
done properly is more efficient than manual mm.

Lasse Reichstein Nielsen wrote:
> Lasse Reichstein Nielsen <> writes:
>
>> Roedy Green <> writes:
>>
>>> On Sun, 04 Nov 2007 09:21:55 -0800, Knute Johnson
>>> <> wrote, quoted or indirectly quoted
>>> someone who said :
>>>
>>>> The coming JRE is going to have greatly improved startup performance.
>>>>
>>>> https://jdk6.dev.java.net/6uNea.html
>>> "The Quick Starter feature will prefetch portions of the JRE into
>>> memory, substantially decreasing the average JRE cold start-up time
>>> (the time that it takes to launch a Java application for the first
>>> time after a fresh reboot of a PC)."
>>>
>>> Sounds like they are loading a pre-loaded RAM image to get the basic
>>> classes going. Yea! I have been asking for this since day 1.
>> That, or they are making yet another "QuickStart" that loads and takes
>> up memory at boot time, whether you use it or not.
>> It can sit next to Office QuickStart, Firefox Quickstart and
>> a gazillion other programs that think they are so important that
>> you have to start everything but the GUI every time you start
>> your machine.
>
> Ack, I was hoping I was wrong. And I was, although only slightly so:
>
> "The fix, then, is for us to take advantage of the disk cache to make
> sure that the memory pages on disk that we must read at startup have
> already been loaded before we need them. How do we do this? We cannot
> magically pre-load the pages just prioir to launching; unfortunately,
> the VM currently lacks the ability to see into the future to detect
> when the user will be launching Java (we would love to have this
> feature in the future, but it is not yet present). But we can
> pre-load at some earlier time, such as Windows boot or login
> time. And we can keep the pages warm in the disk cache as machine and
> memory conditions allow."
>
> From <URL:http://weblogs.java.net/blog/chet/archive/2007/05/consumer_jre_le.html#Quickstarter>
>
> They do load everything into memory, only cache memory instead of
> program memory. And they then keep hitting the pages to ensure that
> no cache algorithm gets to do its job.
> That's just being egoistical. I bet every application wants to be
> loaded from RAM. Well, at least I get to turn it off.
> /L

One of my former jobs was project leader for the paging supervisor on a
virtual storage operating system. The described "feature" makes me
cringe. If every application did this, we would be forced to buy enough
memory for everything to run simultaneously, rather than just for the
maximum set of things we want to do at once.

Patricia

writes:

> On Nov 5, 7:30 pm, Sherman Pendley <spamt...@dot-app.org> wrote:
>> boroph...@gmail.com writes:
>> > <OT> I am looking for a language that is as close to the metal as C++,
>> > yet has garbage collection, which I think is a better idea than manual
>> > mm. Any ideas? </OT>
>>
>> Try C++.
>>
>> No - I'm not joking. So-called "manual" memory management isn't half as
>> bad as Sun's marketing makes it out to be. Newer tools, libraries, and
>> design patterns have made manual new() and delete() calls a rarity.
>
> Perhaps, but are they as efficient as a language which has GC built in
> and was designed to be GC'd. Are these C++ GC libraries just manual MM
> hidden behind classes/templates, or do they truly support "proper"
> GC. This question seems to be important, because I have read that GC
> done properly is more efficient than manual mm.

GC proponents invariably compare it to malloc()/free() or new()/delete().
That's accurate as far as it goes, but it's a pointless comparison because
modern C++ code hardly ever relies on such low-level memory management to
begin with.

Here's a pretty good review of GC options in C++:

<http://www.iecc.com/gclist/GC-faq.html>

sherm--

--
WV News, Blogging, and Discussion: http://wv-www.com
Cocoa programming in Perl: http://camelbones.sourceforge.net

wrote:
> Thanks all for the responses. The feeling I am getting is that Java
> is not very suitable for apps where it needs to interact quite closely
> with the machine (such as graphics, device I/O) because of large
> runtime overhead of JNI. Can this overhead be circumvented by
> compiling Java to native code? Or is it unavoidable for some reason..

I don't know. Jake2 achieves 200+ frames/s. Pretty fast for a Java program, eh?

> Does Java suffer from GC pauses anymore(on UP systems), or are they a
> thing of the past?

"Suffer"?

Of course there are GC pauses, but there are a variety of ways to minimize
their impact. The generational collector does a pretty darn good job of
keeping GC pauses to a minimum.

How long does it take to free memory in a non-GC language?

If memory is to be freed, it will take time. We don't notice it if that time
is amortized properly over the program run, as, say, with Java's GC mechanism.

> <OT> I am looking for a language that is as close to the metal as C++,
> yet has garbage collection, which I think is a better idea than manual
> mm. Any ideas? </OT>

I suggest Java.

--
Lew

Patricia Shanahan wrote:
> Lasse Reichstein Nielsen wrote:
>> Lasse Reichstein Nielsen <> writes:
>>
>>> Roedy Green <> writes:
>>>
>>>> On Sun, 04 Nov 2007 09:21:55 -0800, Knute Johnson
>>>> <> wrote, quoted or indirectly quoted
>>>> someone who said :
>>>>
>>>>> The coming JRE is going to have greatly improved startup performance.
>>>>>
>>>>> https://jdk6.dev.java.net/6uNea.html
>>>> "The Quick Starter feature will prefetch portions of the JRE into
>>>> memory, substantially decreasing the average JRE cold start-up time
>>>> (the time that it takes to launch a Java application for the first
>>>> time after a fresh reboot of a PC)."
>>>>
>>>> Sounds like they are loading a pre-loaded RAM image to get the basic
>>>> classes going. Yea! I have been asking for this since day 1.
>>> That, or they are making yet another "QuickStart" that loads and takes
>>> up memory at boot time, whether you use it or not.
>>> It can sit next to Office QuickStart, Firefox Quickstart and a
>>> gazillion other programs that think they are so important that
>>> you have to start everything but the GUI every time you start
>>> your machine.
>>
>> Ack, I was hoping I was wrong. And I was, although only slightly so:
>>
>> "The fix, then, is for us to take advantage of the disk cache to make
>> sure that the memory pages on disk that we must read at startup have
>> already been loaded before we need them. How do we do this? We cannot
>> magically pre-load the pages just prioir to launching; unfortunately,
>> the VM currently lacks the ability to see into the future to detect
>> when the user will be launching Java (we would love to have this
>> feature in the future, but it is not yet present). But we can
>> pre-load at some earlier time, such as Windows boot or login
>> time. And we can keep the pages warm in the disk cache as machine and
>> memory conditions allow."
>>
>> From
>> <URL:http://weblogs.java.net/blog/chet/archive/2007/05/consumer_jre_le.html#Quickstarter>
>>
>>
>> They do load everything into memory, only cache memory instead of
>> program memory. And they then keep hitting the pages to ensure that
>> no cache algorithm gets to do its job.
>> That's just being egoistical. I bet every application wants to be
>> loaded from RAM. Well, at least I get to turn it off.
>> /L
>
> One of my former jobs was project leader for the paging supervisor on a
> virtual storage operating system. The described "feature" makes me
> cringe. If every application did this, we would be forced to buy enough
> memory for everything to run simultaneously, rather than just for the
> maximum set of things we want to do at once.
>
> Patricia

Isn't that Windows Vista .

--

Knute Johnson
email s/nospam/knute/

Knute Johnson wrote:

> Isn't that Windows Vista .
>

msconfig is back in Vista, with a nice little tab where you can turn all
that stuff off. I've got about 50% of mine removed, and I'm slowly
working my way down to the essentials.

Except for InstallShield Dev Studio. Why does that need to be in the
startup programs?

*zap*

On Mon, 05 Nov 2007 03:17:47 -0800, Patricia Shanahan <>
wrote, quoted or indirectly quoted someone who said :

>One of my former jobs was project leader for the paging supervisor on a
>virtual storage operating system. The described "feature" makes me
>cringe. If every application did this, we would be forced to buy enough
>memory for everything to run simultaneously, rather than just for the
>maximum set of things we want to do at once.

They might avoid that problem with a java.exe command line option like
this:

-preload { swing | awt | none | nogui }

"none" would be equivalent to the current behaviour.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com