>  
> That is the way it current works, you take what you need and reserve the 
> rest. If you have an OOME you've generally got a problem, a bug in your 
> application and it would behove you to fix the bug.
> 
> I guess what I find annoying is the memory reservation is, from the user's 
> perspective, only a constraint.  It obviously simplifies the implementation, 
> however as a user it doesn't buy me anything.  Set the value to low and I can 
> run out of memory with resources still available on the box, set it too high, 
> either the app doesn't start or (as happened yesterday in one of our test 
> environments) the guest OS can over commit virtual memory and the host OS's 
> OOM killer takes out the guest.  Not much that Java can do in that case.

I think that there are a few things we say here

1) Every application I run has come with the stipulation that it need a certain 
minimal amount of hardware in order to run properly.
2) Complex systems require knowledgeable and often customized if not one off 
installations
3) We want 0 admin for things we give to end users
4) Java is not 0 admin


> It always inspiring to speak to Gil.  I like that Azul are not content to 
> settle with what's available and are constantly reaching for what's possible. 
>  I think their proposed memory interface changes will get through sooner 
> rather than later, although the scheduler changes will be a tougher sell to 
> the linux crowd.  As for the Intel side, who knows.  If they could see the 
> potential for a hardware load value barrier outside of Java, perhaps.  
> Although there are a hugh number of features in the Intel chips driven by the 
> gaming industry (e.g. write-combining buffers), so perhaps the Java crowd 
> could have some influence too :-).  I think that it's awesome that Gil and 
> his team are even trying.

IMHO, this is the competitive spirit that Sun was originally trying to inspire. 
IBM has a new GC algorithm (Balance) that I know nothing about. We gave IBM a 
slot at JavaONE to explain what they've done. Creating better methods of memory 
management problems is an interesting topic.

The only way Intel will take Gil's suggestions to heart is if Java is very 
important to helping them sell processors and/or solving the Java write 
bandwidth problems helps solve other write bandwidth (and other real estate 
related) problems in the general application population.

Regards,
Kirk

> 
> Mike.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "The Java Posse" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/javaposse/-/bDGDQOGBVNYJ.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/javaposse?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Reply via email to