View mode: basic / threaded / horizontal-split · Log in · Help
January 13, 2009
Re: new principle of division between structures and classes
Benji Smith wrote:
> Actually, memory allocated in the JVM is very cache-friendly, since two 
> subsequent allocations will always be adjacent to one another in 
> physical memory. And, since the JVM uses a moving GC, long-lived objects 
> move closer and closer together.

Well the problem is that the allocation size grows quickly. Allocate and 
dispose one object per loop -> pages will be quickly eaten.

for (...) {
    JavaClassWithAReallyLongNameAsTheyUsuallyAre o = factory.giveMeOne();
    o.method();
}

The escape analyzer could catch that the variable doesn't survive the 
pass through the loop, but the call to method makes things rather tricky 
(virtual, source unavailable...). So then we're facing a quickly growing 
allocation block and consequently less cache friendliness and more 
frequent collections.


Andrei
January 13, 2009
Re: new principle of division between structures and classes
Andrei Alexandrescu wrote:
> Benji Smith wrote:
>> Actually, memory allocated in the JVM is very cache-friendly, since 
>> two subsequent allocations will always be adjacent to one another in 
>> physical memory. And, since the JVM uses a moving GC, long-lived 
>> objects move closer and closer together.
> 
> Well the problem is that the allocation size grows quickly. Allocate and 
> dispose one object per loop -> pages will be quickly eaten.
> 
> for (...) {
>     JavaClassWithAReallyLongNameAsTheyUsuallyAre o = factory.giveMeOne();
>     o.method();
> }
> 
> The escape analyzer could catch that the variable doesn't survive the 
> pass through the loop, but the call to method makes things rather tricky 
> (virtual, source unavailable...). So then we're facing a quickly growing 
> allocation block and consequently less cache friendliness and more 
> frequent collections.
> 
> 
> Andrei

Good point. I remember five years ago when people were buzzing about the 
possible implementation of escape analysis in the next Java version, and 
how it'd move a boatload of intermediate object allocations from the 
heap to the stack. Personally, I don't think it'll ever happen. They 
can't even agree on how to get *closures* into the language.

I personally think the JVM and the HotSpot compiler are two of the 
greatest accomplishments of computer science. But the Java community has 
long since jumped the shark, and I don't expect much innovation from 
that neighborhood anymore.

--benji
January 13, 2009
Re: new principle of division between structures and classes
Benji Smith wrote:
> [snip]
>
> ... But the Java community has
> long since jumped the shark, and I don't expect much innovation from
> that neighborhood anymore.
> 
> --benji

import javax.actions.aquatic.jumper.*;
import javax.zoology.animals.*;

class SharkJumper
{
 public SharkJumper()
 {
 }

 public void jump() throws Exception
 {
   AnimalFactory animalFactory = new AnimalFactory(false);
   GenusRegistry genusRegistry = new GenusRegistry();
   Animal animal =
animalFactory.createAnimal(genusRegistry.findScientifficNameFromCommonName("shark"));
   ActionFactory actionFactory = new ActionFactory();
   Action action = actionFactory.createFromVerb("jump",
Culture.createFromShortName("en"));
   action.performActionOnObjectPassedAsFirstArgument(animal);
 }
}

Sorry, couldn't resist a chance to bash Java :D  Apologies for any
mistakes; it's been a while since I was forced a gunpoint to write Java
code...

 -- Daniel
January 15, 2009
Re: new principle of division between structures and classes
On Tue, Jan 13, 2009 at 7:30 AM, Daniel Keep
<daniel.keep.lists@gmail.com> wrote:
[snip]
> Sorry, couldn't resist a chance to bash Java :D  Apologies for any
> mistakes; it's been a while since I was forced a gunpoint to write Java
> code...

That's why there is Scala. A far more elegant language, the same VM.

-- Daniel
January 16, 2009
Re: new principle of division between structures and classes
Weed пишет:
> Denis Koroskin пишет:
>> On Sun, 11 Jan 2009 05:04:11 +0300, Weed <resume755@mail.ru> wrote:
>>
>>> Bill Baxter пишет:
>>>> 2009/1/11 Weed <resume755@mail.ru>:
>>>>> Bill Baxter пишет:
>>>>>
>>>>>> But since classes can be polymorphic, value copying gets you into
>>>>>> slicing problems.  That's why value copying is disabled to begin with.
>>>>>>  So disabling value copies is a good thing.
>>>>> It is not always a good thing.
>>>> Yeh, I just mean there is some merit in disabling value copies.  But I
>>>> don't rule out the possibility that there may be an even better way
>>>> that banning them altogether.
>>>>
>>>>> I propose to prohibit only the copying by value of the base type to
>>>>> derivative type
>>>> Ok, this is key.  How do you propose to do this?  In general it
>>>> requires a runtime check, I think.
>>>> And I think you need to say that you prohibit copying unless
>>>> typeA==typeB exactly.  If you allow copying either way between base
>>>> and derived you are asking for trouble.
>>>>
>>>> But still given
>>>>   Base x = get_one();
>>>>   Base y = get_another();
>>>>   *x = *y; // presumed value copy syntax
>>>>
>>>> you have no way in general to know that x and y are really both a Base
>>>> at compile time.  So you must have a run-time check there.  Perhaps it
>>>> could be omitted for -release builds, though.
>>> It can lead to a difficult and non-reproduceable errors than old
>>> C++-style splitting.
>>>
>>> It is possible to try to prohibit assignment of the dereferenced
>>> pointers? Simply to prohibit assignment too it is possible, essentially
>>> it changes nothing.
>>>
>> Err.. I don't get what you say. The *x = *y is just one of the possible
>> syntaxes, nothing else.
>>
> 
> (I have incorrectly expressed)
> 
> If dereferencing was not used in lvalue or rvalue and is both a classes
> by value it is possible to assignment, except cases when the base type
> to the derivative is assigned.
> 
> Example:
> 
> class C {}
> class C2 : C {}
> 
> C c();
> C2 c2();
> 
> C* c_p = &c;
> C2* c2_p = &c2;
> 
> c = c2; // ok
> c2 = c; // err
> *c_p = *c2_p; // err
> *c2_p = *c_p; // err
> c2 = *c2_p; // err
> 
> and:
> c = c2 + *c2_p; // ok
> 

And any remark on the sentence?..
Next ›   Last »
3 4 5 6 7
Top | Discussion index | About this forum | D home