Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #5001 > unrolled thread

Managed-Code Bloat

Back to article view | Back to comp.lang.java.programmer

Contents

  Managed-Code Bloat Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-06 18:47 +1200
    Re: Managed-Code Bloat Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-06 06:40 -0300
      Re: Managed-Code Bloat Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-06 23:04 +1200
        Re: Managed-Code Bloat Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-06 17:41 -0300
          Re: Managed-Code Bloat Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-07 11:13 +1200
            Re: Managed-Code Bloat Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-07 07:08 -0300
        Re: Managed-Code Bloat Silvio <silvio@moc.com> - 2011-06-07 09:40 +0200
          Re: Managed-Code Bloat Patricia Shanahan <pats@acm.org> - 2011-06-07 06:08 -0700
    Re: Managed-Code Bloat Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-06 11:35 -0400
      Re: Managed-Code Bloat Alessio Stalla <alessiostalla@gmail.com> - 2011-06-06 10:47 -0700
        Re: Managed-Code Bloat Martin Gregorie <martin@address-in-sig.invalid> - 2011-06-06 18:21 +0000
          Re: Managed-Code Bloat Michael Wojcik <mwojcik@newsguy.com> - 2011-06-08 11:48 -0400
            Re: Managed-Code Bloat Martin Gregorie <martin@address-in-sig.invalid> - 2011-06-08 18:06 +0000
              Re: Managed-Code Bloat Michael Wojcik <mwojcik@newsguy.com> - 2011-06-11 14:00 -0400
        Re: Managed-Code Bloat Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-07 10:18 +1200
          Re: Managed-Code Bloat Michael Wojcik <mwojcik@newsguy.com> - 2011-06-08 11:59 -0400
        Re: Managed-Code Bloat Michael Wojcik <mwojcik@newsguy.com> - 2011-06-08 11:22 -0400
          Re: Managed-Code Bloat rossum <rossum48@coldmail.com> - 2011-06-08 21:45 +0100
      Re: Managed-Code Bloat Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-07 10:17 +1200
        Re: Managed-Code Bloat Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-06 16:37 -0700
          Re: Managed-Code Bloat Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-07 12:06 +1200
            Re: Managed-Code Bloat Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-06 17:44 -0700
              Re: Managed-Code Bloat Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-07 13:38 +1200
                Re: Managed-Code Bloat Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-06 20:13 -0700
                  Re: Managed-Code Bloat Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-07 15:41 +1200
                    Re: Managed-Code Bloat Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-06 20:47 -0700
                      Re: Managed-Code Bloat BGB <cr88192@hotmail.com> - 2011-06-07 01:06 -0700
                        Re: Managed-Code Bloat Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-07 23:53 +1200
                          Re: Managed-Code Bloat BGB <cr88192@hotmail.com> - 2011-06-07 16:04 -0700
                          Re: Managed-Code Bloat Michael Wojcik <mwojcik@newsguy.com> - 2011-06-08 13:04 -0400
                        Re: Managed-Code Bloat Michal Kleczek <kleku75@gmail.com> - 2011-06-08 09:23 +0200
                          Re: Managed-Code Bloat BGB <cr88192@hotmail.com> - 2011-06-08 03:54 -0700
                    Re: Managed-Code Bloat bugbear <bugbear@trim_papermule.co.uk_trim> - 2011-06-07 10:10 +0100
                  Re: Managed-Code Bloat BGB <cr88192@hotmail.com> - 2011-06-07 00:37 -0700
        Re: Managed-Code Bloat Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-07 07:31 -0300
          Re: Managed-Code Bloat BGB <cr88192@hotmail.com> - 2011-06-07 16:18 -0700
            Re: Managed-Code Bloat Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-07 20:50 -0300
            Re: Managed-Code Bloat Gene Wirchenko <genew@ocis.net> - 2011-06-08 07:53 -0700
              Re: Managed-Code Bloat BGB <cr88192@hotmail.com> - 2011-06-08 11:23 -0700
      Re: Managed-Code Bloat BGB <cr88192@hotmail.com> - 2011-06-06 16:54 -0700
    Re: Managed-Code Bloat Roedy Green <see_website@mindprod.com.invalid> - 2011-06-06 19:24 -0700
      Re: Managed-Code Bloat Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-07 15:44 +1200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#5044

In message <isjobk$e3s$1@dont-email.me>, Joshua Cranmer wrote:

> On 6/6/2011 3:17 PM, Lawrence D'Oliveiro wrote:
>
>> In message<isis49$cpq$1@dont-email.me>, Joshua Cranmer wrote:
>>
>>>    From a programming language design concept, one thing is abundantly
>>> clear: manually-managed memory is a failure.
>>
>> And yet managed code has failed to take off in the mass market. Why is
>> that?
> 
> Because you can't see the mass market. The use of HTML 5 and
> JavaScript-based applications is taking off. And what is JavaScript? Why
> managed code.

I think JavaScript uses reference-counting, too. Why else would it have a
“delete” statement
<http://developer.apple.com/library/mac/#documentation/ScriptingAutomation/Conceptual/JSCodingGuide/OOJavaScript/OOJavaScript.html#//apple_ref/doc/uid/TP40006539-SW1>?

[toc] | [prev] | [next] | [standalone]

#5045

On 6/6/2011 5:06 PM, Lawrence D'Oliveiro wrote:
> I think JavaScript uses reference-counting, too. Why else would it have a
> “delete” statement

Both SpiderMonkey and V8 are garbage-collected. Don't believe me? Here 
is their garbage collector:
<http://mxr.mozilla.org/mozilla-central/source/js/src/jsgc.cpp>
<http://code.google.com/apis/v8/design.html> (I don't actually work with 
V8, so I don't know it's class layout so well).

If you want more evidence, the ECMAScript committee talks about some JS 
things in the context of garbage collection: 
<http://wiki.ecmascript.org/doku.php?id=strawman:gc_semantics>.

As for python, Python does have a garbage collector because it is very 
easy to accidentally create cycles in references, the big bane of 
reference-counted systems.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#5046

In message <isjsa7$2j9$1@dont-email.me>, Joshua Cranmer wrote:

> On 6/6/2011 5:06 PM, Lawrence D'Oliveiro wrote:
>
>> I think JavaScript uses reference-counting, too. Why else would it have a
>> “delete” statement
> 
> As for python, Python does have a garbage collector because it is very
> easy to accidentally create cycles in references, the big bane of
> reference-counted systems.

Yes, but like Perl, the garbage collector only gets invoked in those less-
common cases where you do indeed have such cycles. The rest of the time 
(which is most of the time), reference-counting works just fine.

> Both SpiderMonkey and V8 are garbage-collected.

Probably same here.

[toc] | [prev] | [next] | [standalone]

#5050

On 6/6/2011 6:38 PM, Lawrence D'Oliveiro wrote:
> In message<isjsa7$2j9$1@dont-email.me>, Joshua Cranmer wrote:
>> Both SpiderMonkey and V8 are garbage-collected.
>
> Probably same here.

That is not the case. I have actually patched the source code to 
SpiderMonkey myself, I have literally sat next to the people who work on 
the engine, SpiderMonkey is garbage-collected. Mark-and-trace, although 
the plan is to move to generational GC. I'm not so sure about V8, but 
the page I linked to explicitly mentions generational garbage 
collection, so I'm sure it's in the same boat.

If you don't believe that, what would it take to get you to believe the 
truth? A signed note from Brendan Eich himself?

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#5051

In message <isk4vu$baq$1@dont-email.me>, Joshua Cranmer wrote:

> On 6/6/2011 6:38 PM, Lawrence D'Oliveiro wrote:
>
>> In message<isjsa7$2j9$1@dont-email.me>, Joshua Cranmer wrote:
>>
>>> Both SpiderMonkey and V8 are garbage-collected.
>>
>> Probably same here.
> 
> That is not the case.

So why have a “delete” statement, then?

[toc] | [prev] | [next] | [standalone]

#5053

On 6/6/2011 8:41 PM, Lawrence D'Oliveiro wrote:
> In message<isk4vu$baq$1@dont-email.me>, Joshua Cranmer wrote:
>
>> On 6/6/2011 6:38 PM, Lawrence D'Oliveiro wrote:
>>
>>> In message<isjsa7$2j9$1@dont-email.me>, Joshua Cranmer wrote:
>>>
>>>> Both SpiderMonkey and V8 are garbage-collected.
>>>
>>> Probably same here.
>>
>> That is not the case.
>
> So why have a “delete” statement, then?

JavaScript objects are basically hashmaps. The delete statement is the 
JS equivalent of map.remove.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#5056

On 6/6/2011 8:47 PM, Joshua Cranmer wrote:
> On 6/6/2011 8:41 PM, Lawrence D'Oliveiro wrote:
>> In message<isk4vu$baq$1@dont-email.me>, Joshua Cranmer wrote:
>>
>>> On 6/6/2011 6:38 PM, Lawrence D'Oliveiro wrote:
>>>
>>>> In message<isjsa7$2j9$1@dont-email.me>, Joshua Cranmer wrote:
>>>>
>>>>> Both SpiderMonkey and V8 are garbage-collected.
>>>>
>>>> Probably same here.
>>>
>>> That is not the case.
>>
>> So why have a “delete” statement, then?
>
> JavaScript objects are basically hashmaps. The delete statement is the
> JS equivalent of map.remove.
>

yep, and also IMO the Java idea that GC=="inability to free crap" is IMO 
stupid...

delete can basically also allow a VM to free stuff early, and thus 
potentially improve overall performance.


also, possible though are some garbage reduction tricks:
ref-counting (as they can detect earlier objects that have died);
(heap-based) value types (because their lifespan behavior is trivial to 
determine, and so one can allocate/free them aggressively);
...

ref-counting has the drawback though that it is very difficult to write 
"general purpose" code and not screw up the ref-counts somewhere (which 
can easily blow up the program), causing me to generally not use them.

value types are simpler to work with, but (like ref-counts) involve lots 
of operations which may add overhead, are not as general-purpose (since 
they reflect particular usage semantics), and involve in some cases 
"policy" decisions (basically, who "owns" a value-object, since 
internally they are passed as a reference, with operations which copy 
and free them as necessary to cause their behaviors).

a smarter VM (or a JIT) could probably use the stack-frame to store 
value-types.


or such...

[toc] | [prev] | [next] | [standalone]

#5063

In message <iskmd5$anm$1@news.albasani.net>, BGB wrote:

> delete can basically also allow a VM to free stuff early, and thus
> potentially improve overall performance.

Isn’t that conceding the point that automatic garbage collection saps 
performance?

[toc] | [prev] | [next] | [standalone]

#5076

On 6/7/2011 4:53 AM, Lawrence D'Oliveiro wrote:
> In message<iskmd5$anm$1@news.albasani.net>, BGB wrote:
>
>> delete can basically also allow a VM to free stuff early, and thus
>> potentially improve overall performance.
>
> Isn’t that conceding the point that automatic garbage collection saps
> performance?

I wasn't claiming it doesn't...


the merit of GC is that it can be easier to use, as it can serve as a 
"safety net" for all of those objects which fail to get freed correctly 
(or, rigged with some additional machinery, serve as a leak-detector and 
provide partial diagnosis...).

the downside though is, of course, that performance can be lost, and if 
the GC has to do its thing (GC cycles), this is not free either.

it depends though, as heavy use of RAII/Smart-Pointers and Pass-by-Copy, 
which is "common" in a lot of C++ code, can actually manage to be slower 
(a lot of C++ devs though use this in an attempt to reduce leaks without 
going through the more costly process of determining exactly when and 
where to free things as part of their code design, setting up "who owns 
what" policies, and so on...).


personally, I am just thinking here that GC + the ability to free things 
(basically, when one can determine for themselves when it is no longer 
needed) allows combining the good points (combining the relative ease of 
GC with a little more of the performance of manual MM).

I think Java just sort of left out delete due more to ideological 
reasons though, when instead they could have treated it like a hint (if 
the compiler or VM has good reason to doubt that the delete is valid, it 
can make it no-op and/or raise an exception if used incorrectly).

say, program crashes with an exception 
"java.lang.AccessFollowingDeleteError" or similar...


so, it is a tradeoff...

[toc] | [prev] | [next] | [standalone]

#5117

Lawrence D'Oliveiro wrote:
> In message <iskmd5$anm$1@news.albasani.net>, BGB wrote:
> 
>> delete can basically also allow a VM to free stuff early, and thus
>> potentially improve overall performance.
> 
> Isn’t that conceding the point that automatic garbage collection saps 
> performance?

Research shows it does not, as a general rule.

See for example Blackburn & McKinley's paper on ulterior reference
counting. The generational GC in that study outperforms the
ref-counting GC in total test execution time. The incentive to
hybridize is reducing the GC pause time.

(And incidentally, reference-counting garbage collection is still
automatic garbage collection. And the "automatic" is redundant, too.)

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

[toc] | [prev] | [next] | [standalone]

#5085

BGB wrote:

> 
> also, possible though are some garbage reduction tricks:
> ref-counting (as they can detect earlier objects that have died);
> (heap-based) value types (because their lifespan behavior is trivial to
> determine, and so one can allocate/free them aggressively);
> ...
> 
> ref-counting has the drawback though that it is very difficult to write
> "general purpose" code and not screw up the ref-counts somewhere (which
> can easily blow up the program), causing me to generally not use them.
> 

There has been some work done to implement ref-counting GC in (Sun) JVM. 
See:
http://www.cs.technion.ac.il/~erez/Papers/refcount.ps
The results were promissing but it has not been incorporated into production 
JVM.

-- 
Michal

[toc] | [prev] | [next] | [standalone]

#5087

On 6/8/2011 12:23 AM, Michal Kleczek wrote:
> BGB wrote:
>
>>
>> also, possible though are some garbage reduction tricks:
>> ref-counting (as they can detect earlier objects that have died);
>> (heap-based) value types (because their lifespan behavior is trivial to
>> determine, and so one can allocate/free them aggressively);
>> ...
>>
>> ref-counting has the drawback though that it is very difficult to write
>> "general purpose" code and not screw up the ref-counts somewhere (which
>> can easily blow up the program), causing me to generally not use them.
>>
>
> There has been some work done to implement ref-counting GC in (Sun) JVM.
> See:
> http://www.cs.technion.ac.il/~erez/Papers/refcount.ps
> The results were promissing but it has not been incorporated into production
> JVM.
>

yeah...

this is along with several other major features.


one of my own prior VMs used ref-counting, but this, combined with other 
factors, made the VM in question very painful to work on (or interface 
with).

my current VMs are much easier to work with, at a cost of being somewhat 
less efficient.


another partial point of controversy in my current architecture, is that 
the core type-system is based mostly on strings and "strcmp()". again it 
was another tradeoff: strings were generally the least-effort option, 
and eventually largely won out in their battle against tagged references 
(which were technically "better", but also generally more of a pain to 
work with, vs using raw pointers and "magic" types).


or such...

[toc] | [prev] | [next] | [standalone]

#5059

Lawrence D'Oliveiro wrote:
> In message<isk4vu$baq$1@dont-email.me>, Joshua Cranmer wrote:
>
>> On 6/6/2011 6:38 PM, Lawrence D'Oliveiro wrote:
>>
>>> In message<isjsa7$2j9$1@dont-email.me>, Joshua Cranmer wrote:
>>>
>>>> Both SpiderMonkey and V8 are garbage-collected.
>>>
>>> Probably same here.
>>
>> That is not the case.
>
> So why have a “delete” statement, then?

Tell you what. Go and learn about garbage collection
(in the most general sense) and we'll continue
the discussion when you know enough to be worth talking with.

    BugBear

[toc] | [prev] | [next] | [standalone]

#5054

On 6/6/2011 8:13 PM, Joshua Cranmer wrote:
> On 6/6/2011 6:38 PM, Lawrence D'Oliveiro wrote:
>> In message<isjsa7$2j9$1@dont-email.me>, Joshua Cranmer wrote:
>>> Both SpiderMonkey and V8 are garbage-collected.
>>
>> Probably same here.
>
> That is not the case. I have actually patched the source code to
> SpiderMonkey myself, I have literally sat next to the people who work on
> the engine, SpiderMonkey is garbage-collected. Mark-and-trace, although
> the plan is to move to generational GC. I'm not so sure about V8, but
> the page I linked to explicitly mentions generational garbage
> collection, so I'm sure it's in the same boat.
>
> If you don't believe that, what would it take to get you to believe the
> truth? A signed note from Brendan Eich himself?
>

yep... and my own language (partly derived from JavaScript) also uses 
GC, but it is based on conservative mark/sweep (similar to the Boehm GC).

sadly, the problem with traditional generation GC strategies is that 
they would depend on having a precise GC, which has the major drawback 
of being notably painful to work with (apart from having to 
"pin"/"defile" pretty much any object which may be potentially 
referenced by "unsafe" C code).

the tradeoff though is that precise generational GC's can get much 
better performance than conservative mark/sweep.


however, my GC is used by nearly all of the C code as well, and with 
care, most GC stalls can be largely avoided (I am using it successfully 
with a 3D engine, doing an FPS style game).

part of the trick though is that I am mostly treating the GC as if it 
were a manual MM, as in, freeing stuff when it is known no longer needed 
(and the script VM also has a few tricks to reduce garbage production as 
well...).


or such...

[toc] | [prev] | [next] | [standalone]

#5062

On 11-06-06 07:17 PM, Lawrence D'Oliveiro wrote:
> In message <isis49$cpq$1@dont-email.me>, Joshua Cranmer wrote:
> 
>>  From a programming language design concept, one thing is abundantly
>> clear: manually-managed memory is a failure.
> 
> And yet managed code has failed to take off in the mass market. Why is that?

Dude, what do you consider to be managed code? It's not just .NET and
Java. Fact is, any language system that takes care of some details for
you that you need to deal with yourself in C or assembly has aspects of
management. This is a continuous spectrum, not an all or nothing.

As Spolsky puts it, if your language lets you concatenate strings and
not worry about how it happens, you've got managed code.

>> Most programmers--even the very best--have very little ability to prevent
>> memory from being leaked. That's why pretty much everyone accuses every
>> very large application written in native languages as acting like a leaky
>> bucket: Windows, Firefox, etc.
> 
> And yet it is the “managed” apps that tend to be the memory hogs.

Really? So C and C++ programs have never been accused of having memory
management issues. Interesting.

There is actually some truth to your observation however. Again, not for
the reasons you think. Since when you said "managed" you really meant
Java and .NET, I'll confine my remarks to those also. Anyway, Java and
C#, among others, can be abused by incompetent or unschooled or ignorant
programmers just like any other language can. If a programmer is shabby
at programming, and more specifically, shabby at OOP, they'll write crap
in C++ *and* Java *and* C#. With a C++ app it'll probably crash within
minutes and very possibly never ship. With Java and C# a mediocre coder
is much more likely to be able to release his poor code - humans being
humans, such a coder will blame the language for bloat and slowness and
errors.

If you run across a Java app that's a memory hog, why do you think it's
the fault of the language? It never occurred to you that it might be the
programmers? It's not like more than 25% (being charitable) of all
programmers working today should even be let near a keyboard, after all.

AHS

[toc] | [prev] | [next] | [standalone]

#5077

On 6/7/2011 3:31 AM, Arved Sandstrom wrote:
> On 11-06-06 07:17 PM, Lawrence D'Oliveiro wrote:
>> In message<isis49$cpq$1@dont-email.me>, Joshua Cranmer wrote:
>>
>>>    From a programming language design concept, one thing is abundantly
>>> clear: manually-managed memory is a failure.
>>
>> And yet managed code has failed to take off in the mass market. Why is that?
>
> Dude, what do you consider to be managed code? It's not just .NET and
> Java. Fact is, any language system that takes care of some details for
> you that you need to deal with yourself in C or assembly has aspects of
> management. This is a continuous spectrum, not an all or nothing.
>
> As Spolsky puts it, if your language lets you concatenate strings and
> not worry about how it happens, you've got managed code.
>
>>> Most programmers--even the very best--have very little ability to prevent
>>> memory from being leaked. That's why pretty much everyone accuses every
>>> very large application written in native languages as acting like a leaky
>>> bucket: Windows, Firefox, etc.
>>
>> And yet it is the “managed” apps that tend to be the memory hogs.
>
> Really? So C and C++ programs have never been accused of having memory
> management issues. Interesting.
>
> There is actually some truth to your observation however. Again, not for
> the reasons you think. Since when you said "managed" you really meant
> Java and .NET, I'll confine my remarks to those also. Anyway, Java and
> C#, among others, can be abused by incompetent or unschooled or ignorant
> programmers just like any other language can. If a programmer is shabby
> at programming, and more specifically, shabby at OOP, they'll write crap
> in C++ *and* Java *and* C#. With a C++ app it'll probably crash within
> minutes and very possibly never ship. With Java and C# a mediocre coder
> is much more likely to be able to release his poor code - humans being
> humans, such a coder will blame the language for bloat and slowness and
> errors.
>
> If you run across a Java app that's a memory hog, why do you think it's
> the fault of the language? It never occurred to you that it might be the
> programmers? It's not like more than 25% (being charitable) of all
> programmers working today should even be let near a keyboard, after all.
>

well, I think it actually partly goes both ways.

while many programmers do suck... both Java and C# implement things in 
many cases, in ways which are fairly costly...


for example, in C, a string is just a glob of 8-bit characters in 
memory, and so doesn't really take much more memory than the space to 
store these characters.

in Java, a "String" is a class instance containing an array of 16-bit 
characters...

just at the outset, this is a good deal more expensive (I calculated for 
my own technology, reaching an approx 7x difference for the memory cost 
of storing the string "Hello"). granted, the JVM may have a lower base 
overhead, and it will drop and approach 2x as the string gets longer (a 
lot of the overhead was mostly related to the cost of the object 
instance and array headers).

but, even 2x is still a significant space overhead... (due to UTF-16 vs 
UTF-8...).


also, there are many places internally where "new" will be used in 
copious amounts due to the basic design of the VM architecture, ...

a lot of this is still likely not exactly free either, and a lot of this 
may add up...


or such...

[toc] | [prev] | [next] | [standalone]

#5079

On 11-06-07 08:18 PM, BGB wrote:
> On 6/7/2011 3:31 AM, Arved Sandstrom wrote:
>> On 11-06-06 07:17 PM, Lawrence D'Oliveiro wrote:
>>> In message<isis49$cpq$1@dont-email.me>, Joshua Cranmer wrote:
>>>
>>>>    From a programming language design concept, one thing is abundantly
>>>> clear: manually-managed memory is a failure.
>>>
>>> And yet managed code has failed to take off in the mass market. Why
>>> is that?
>>
>> Dude, what do you consider to be managed code? It's not just .NET and
>> Java. Fact is, any language system that takes care of some details for
>> you that you need to deal with yourself in C or assembly has aspects of
>> management. This is a continuous spectrum, not an all or nothing.
>>
>> As Spolsky puts it, if your language lets you concatenate strings and
>> not worry about how it happens, you've got managed code.
>>
>>>> Most programmers--even the very best--have very little ability to
>>>> prevent
>>>> memory from being leaked. That's why pretty much everyone accuses every
>>>> very large application written in native languages as acting like a
>>>> leaky
>>>> bucket: Windows, Firefox, etc.
>>>
>>> And yet it is the “managed” apps that tend to be the memory hogs.
>>
>> Really? So C and C++ programs have never been accused of having memory
>> management issues. Interesting.
>>
>> There is actually some truth to your observation however. Again, not for
>> the reasons you think. Since when you said "managed" you really meant
>> Java and .NET, I'll confine my remarks to those also. Anyway, Java and
>> C#, among others, can be abused by incompetent or unschooled or ignorant
>> programmers just like any other language can. If a programmer is shabby
>> at programming, and more specifically, shabby at OOP, they'll write crap
>> in C++ *and* Java *and* C#. With a C++ app it'll probably crash within
>> minutes and very possibly never ship. With Java and C# a mediocre coder
>> is much more likely to be able to release his poor code - humans being
>> humans, such a coder will blame the language for bloat and slowness and
>> errors.
>>
>> If you run across a Java app that's a memory hog, why do you think it's
>> the fault of the language? It never occurred to you that it might be the
>> programmers? It's not like more than 25% (being charitable) of all
>> programmers working today should even be let near a keyboard, after all.
>>
> 
> well, I think it actually partly goes both ways.
> 
> while many programmers do suck... both Java and C# implement things in
> many cases, in ways which are fairly costly...
> 
> 
> for example, in C, a string is just a glob of 8-bit characters in
> memory, and so doesn't really take much more memory than the space to
> store these characters.
> 
> in Java, a "String" is a class instance containing an array of 16-bit
> characters...
> 
> just at the outset, this is a good deal more expensive (I calculated for
> my own technology, reaching an approx 7x difference for the memory cost
> of storing the string "Hello"). granted, the JVM may have a lower base
> overhead, and it will drop and approach 2x as the string gets longer (a
> lot of the overhead was mostly related to the cost of the object
> instance and array headers).
> 
> but, even 2x is still a significant space overhead... (due to UTF-16 vs
> UTF-8...).
> 
> also, there are many places internally where "new" will be used in
> copious amounts due to the basic design of the VM architecture, ...
> 
> a lot of this is still likely not exactly free either, and a lot of this
> may add up...
> 
> or such...
> 
No argument from me, but in over a decade of working with Java I've yet
to see a "memory hog" bloated application that couldn't have been
improved to make it acceptable. Which means it could have been written
that way to start with.

Good design helps a great deal - minimize coupling and you minimize the
number of references that are held, keeping other objects around. Cut
down on object lifetimes by creating them when definitely needed, and
make sure they are cut loose as soon as possible after their usefulness
is done. Re-use immutable value objects when possible (flyweight), or
singletons - try to recycle. Use the right data structures. Use pools.
Understand GC and the Reference API.

Etc etc etc. Jack Shirazi's "Java Performance Tuning" book came out in
2000, and it ought to have been a must read for every Java programmer
from the gitgo. I wonder what percentage of Java programmers ever read
it. A lot of it still holds true; there's plenty other updated material
to cover newer Java.

AHS

[toc] | [prev] | [next] | [standalone]

#5097

On Tue, 07 Jun 2011 16:18:29 -0700, BGB <cr88192@hotmail.com> wrote:

[snip]

>for example, in C, a string is just a glob of 8-bit characters in 
>memory, and so doesn't really take much more memory than the space to 
>store these characters.

     It can be, but it need not be.  Some systems have a different
CHARBITS value.  Some systems have each character in a larger data
chunk.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#5127

On 6/8/2011 7:53 AM, Gene Wirchenko wrote:
> On Tue, 07 Jun 2011 16:18:29 -0700, BGB<cr88192@hotmail.com>  wrote:
>
> [snip]
>
>> for example, in C, a string is just a glob of 8-bit characters in
>> memory, and so doesn't really take much more memory than the space to
>> store these characters.
>
>       It can be, but it need not be.  Some systems have a different
> CHARBITS value.  Some systems have each character in a larger data
> chunk.
>

yes, but the issue can be restated as "on pretty much any HW either 
programmers or users are likely to deal with".

in this case, it is very unlikely to need to worry about HW with 
characters with non-8-bit characters.

much like, the vast majority of normal computers also run x86, and on 
x86, bytes are 8-bit (likewise goes for PPC, ARM, ...). everything else? 
mostly irrelevant.

relatively under-used features, such as wide-character strings ("wchar_t 
*str=L"...";" and likewise), are also being disregarded.


this means, in a general case:
C will need 8 bits per character, with little overhead apart from 
in-memory storage;
Java will need 16 bits per character.


generally, Java stores String's as a class instance, where the class 
holds an array. so, one also has to add in the overhead of storing a 
instance and an array (for example, an 'Object', and the respective 
memory headers for an instance and an array).

combining all of these, a Java implementation will generally have a 
somewhat higher overhead in the cost of storing a string, as per the 
number of in-memory bytes.


not that this may be a killer in itself, but it may add up...

[toc] | [prev] | [next] | [standalone]

#5043

On 6/6/2011 8:35 AM, Joshua Cranmer wrote:
> On 06/06/2011 02:47 AM, Lawrence D'Oliveiro wrote:
>> The whole managed-code/auto-garbage-collected concept may really
>> appeal to
>> corporate code-cutter types, but I think it has real trouble in the mass
>> market.
>
>  From a programming language design concept, one thing is abundantly
> clear: manually-managed memory is a failure. Most programmers--even the
> very best--have very little ability to prevent memory from being leaked.
> That's why pretty much everyone accuses every very large application
> written in native languages as acting like a leaky bucket: Windows,
> Firefox, etc.
>

you know... some of us use garbage collectors in C...

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web