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

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

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

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

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?..