new principle of division between structures and classes

[John Reimer]

Hello Bill,

> 2009/1/13 Weed <resume755 at mail.ru>:
> 
>> Andrei Alexandrescu пишет:
>> 
>>> Brad Roberts wrote:
>>> 
>>>> Andrei Alexandrescu wrote:
>>>> 
>>>>> Weed wrote:
>>>>> 
>>>>>> Weed пишет:
>>>>>> 
>>>>>>>>> 4. Java and C# also uses objects by reference? But both these
>>>>>>>>> of
>>>>>>>>> language are interpreted. I assume that the interpreter
>>>>>>>>> generally
>>>>>>>>> with
>>>>>>>>> identical speed allocates memory in a heap and in a stack,
>>>>>>>>> therefore
>>>>>>>>> authors of these languages and used reference model.
>>>>>>>> Neither of these languages are interpreted, they both are
>>>>>>>> compiled
>>>>>>>> into
>>>>>>>> native code at runtime.
>>>>>>> Oh!:) but I suspect such classes scheme somehow correspond with
>>>>>>> JIT-compilation.
>>>>>>> 
>>>>>> I guess allocation in Java occurs fast because of usage of the
>>>>>> its own
>>>>>> memory manager.
>>>>>> I do not know how it is fair, but:
>>>>>> http://www.ibm.com/developerworks/java/library/j-jtp09275.html
>>>>>> "Pop quiz: Which language boasts faster raw allocation
>>>>>> performance, the Java language, or C/C++? The answer may surprise
>>>>>> you -- allocation in modern JVMs is far faster than the best
>>>>>> performing malloc implementations. The common code path for new
>>>>>> Object() in HotSpot 1.4.2 and later is approximately 10 machine
>>>>>> instructions (data provided by Sun; see Resources), whereas the
>>>>>> best performing malloc implementations in C require on average
>>>>>> between 60 and 100 instructions per call (Detlefs, et. al.; see
>>>>>> Resources)."
>>>>>> 
>>>>> Meh, that should be taken with a grain of salt. An allocator that
>>>>> only bumps a pointer will simply eat more memory and be less
>>>>> cache-friendly. Many applications aren't that thrilled with the
>>>>> costs of such a model.
>>>>> 
>>>>> Andrei
>>>>> 
>>>> Take it as nicely seasoned.  The current jvm gc and memory
>>>> subsystem is _extremely_ clever.  However, it completely relies on
>>>> the ability to move objects during garbage collection.  If it was
>>>> purely the allocator that behaved that way, you'd be right.  But
>>>> it's interaction with the gc is where the system comes together to
>>>> form a useful whole.
>>>> 
>>> I understand. My point is that a 10-cycles-per-allocation allocator
>>> 
>> 10 *cycles* per allocation?
>> 
>>> will
>>> necessarily use more memory than one that attempts to reuse memory.
>>> There's no way around that. I mean we know what those cycles do :o).
>>> Some application don't work well with that. Escape analysis does
>>> reduce
>>> the number of cache-unfriendly patterns, but, as of today, not to
>>> the
>>> point the issue can be safely ignored.
>>> There's no contention that GC has made great progress lately, and
>>> that's a great thing.
>>> 
>> In any case, we cannot add such memory manager in D. And such
>> resource allocation does not approach us, and mandatory creation of
>> objects in a heap does not approach for D.
>> 
> I'm not and expert in garbage collection but...
> An interesting point was made yesterday on the GDAlgorithms mailing
> list.  Acording to this one game industry veteran, you don't need a
> fully moving garbage collector to get many of the benefits.  If *some*
> of the memory can be moved around then often that's enough to fill in
> the gaps and keep fragmentation down.
> So it may be worth while to have a special kind construct for
> containing data that the compiler is free to move around.  This type
> would have a hidden pointer inside of it that can be moved around by
> the gc, but applications would not be allowed to access that pointer.
> And I suppose that means all access to the data would given via
> lvalue only.   Probably wouldn't take much on the part of the GC to
> provide the necessary hooks.  Just some sort of "relocatable alloc"
> call.  Rest could probably be handled in higher level libs.
> 
> But like I said I don't know much about GC.
> 
> --bb
> 


Recently, I started looking into garbage collection theory.  Of course, the 
first source I went to was Hans Boem's.  Here's a couple of links that might 
be interesting:

http://www.hpl.hp.com/personal/Hans_Boehm/gc/complexity.html
http://www.hpl.hp.com/personal/Hans_Boehm/gc/conservative.html

And a whole list of other articles here:

http://www.hpl.hp.com/personal/Hans_Boehm/gc/

Lots of interesting material... and a fair bit of it is over my head. But, 
nonetheless, the fundamentals are there.  I'm not sure if some of there studies 
are accurate, biased, or out-dated since I don't keep up with state-of-the-art 
gc research.  But, it seems to me, that Hans is still one of the top experts 
in the field, so some of what's there must be very pertinant.

-JJR