Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!weretis.net!feeder1.news.weretis.net!news.albasani.net!.POSTED!not-for-mail
From: BGB <cr88192@hotmail.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: Managed-Code Bloat
Date: Tue, 07 Jun 2011 01:06:59 -0700
Organization: albasani.net
Lines: 49
Message-ID: <iskmd5$anm$1@news.albasani.net>
References: <isht62$t08$1@lust.ihug.co.nz> <isis49$cpq$1@dont-email.me> <isjjl5$sm1$1@lust.ihug.co.nz> <isjobk$e3s$1@dont-email.me> <isjq2m$pb$1@lust.ihug.co.nz> <isjsa7$2j9$1@dont-email.me> <isjvee$3na$1@lust.ihug.co.nz> <isk4vu$baq$1@dont-email.me> <isk6l1$7nj$2@lust.ihug.co.nz> <isk71h$kso$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.albasani.net CaUBXyJZy8l0FuoH257ByTO6b/hstLwbS8eQ3b76Xpur6ZrvcGoDGsYD+mHyvlNiwGZ4pq8y69NeJThMcozzpA==
NNTP-Posting-Date: Tue, 7 Jun 2011 08:10:14 +0000 (UTC)
Injection-Info: news.albasani.net; logging-data="wgDhe+u47DjiA9Iq1bag3C3+6bX/JtvsdXJwyOy+87/5soGADWa5YgczVOCdovBLofyItyO6W5lVnM4rd3GfM5dx38Nx/cXbWmr5KbWzRQhoMkrBeNwFSjcze9M1zBI2"; mail-complaints-to="abuse@albasani.net"
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
In-Reply-To: <isk71h$kso$1@dont-email.me>
Cancel-Lock: sha1:37I3hDc9NMppiVOt4H7miZl2ZGU=
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer: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...