Re: Java 7 & GC Settings

[Jerry]

I agree.

Major GC always means "pause" in application execution. This will
definitely hurt overall throughput & latency.

I think the goals of optimizing GC is to
 1. reduce # of Major GC as much as possible;
 2. reduce frequency of Minor GC as much as possible;

In order to achieve Goal #1, application must be written and configured so
that all objects
are not living in memory for long time. This means that, # of objects
coming into old
generation pool should be minimal.

Thanks.
-Jerry.

On Wed, Jul 4, 2012 at 3:33 PM, Niels van Klaveren <
niels.vanklave...@gmail.com> wrote:

> Interesting settings Sam,
> I'm curious about this one:
>
>
> "-XX:MaxTenuringThreshold=0"  ; Makes the full NewSize available to every 
> NewGC
>  ;  cycle, and reduces the pause time by not
>  ;  evaluating tenured objects. Technically, 
> this
>  ;  setting promotes all live objects to the 
> older
> ;  generation, rather than copying 
> them.
>
>
> That setting forces all new objects that survive a young scavenge to be
> promoted to the old generation. Effectively switching off generational GC,
> which is one of the main optimisations in performance GC memory management.
> Since GC on the old generation is generally more expensive pause-wise, how
> do you prevent that from becoming a problem ?
>
> On Tuesday, July 3, 2012 12:58:19 PM UTC+2, Sam Aaron wrote:
>>
>> Hi Bruce,
>>
>> at the bottom of this file you can see the options we use in Overtone to
>> try and reduce latency (i.e. we're not so worried about throughput, but are
>> trying to minimise the occurrence of long GC pauses)
>>
>> https://github.com/overtone/**overtone/blob/master/project.**clj
>>
>> Sam
>>
>> ---
>> http://sam.aaron.name
>>
>> On 1 Jul 2012, at 23:19, Bruce Durling wrote:
>>
>> > Clojurians,
>> >
>> > Interesting post here on different GC settings for Java 7. Does anyone
>> > have any tips/experience about what settings have worked best for them
>> > with clojure and under what circumstances?
>> >
>> > http://www.fasterj.com/**articles/oraclecollectors1.**shtml
>> >
>> > cheers,
>> > Bruce
>> >
>> > --
>> > @otfrom | CTO & co-founder @MastodonC | mastodonc.com
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clojure@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with
>> your first post.
>> > To unsubscribe from this group, send email to
>> > clojure+unsubscribe@**googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/**group/clojure?hl=en
>>
>>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Java 7 & GC Settings

[Niels van Klaveren]

Interesting settings Sam,
I'm curious about this one:

   
"-XX:MaxTenuringThreshold=0"  ; Makes the full NewSize available to every 
NewGC
 ;  cycle, and reduces the pause time by not
 ;  evaluating tenured objects. Technically, 
this
 ;  setting promotes all live objects to the 
older
;  generation, rather than copying them.


That setting forces all new objects that survive a young scavenge to be 
promoted to the old generation. Effectively switching off generational GC, 
which is one of the main optimisations in performance GC memory management. 
Since GC on the old generation is generally more expensive pause-wise, how 
do you prevent that from becoming a problem ? 

On Tuesday, July 3, 2012 12:58:19 PM UTC+2, Sam Aaron wrote:
>
> Hi Bruce, 
>
> at the bottom of this file you can see the options we use in Overtone to 
> try and reduce latency (i.e. we're not so worried about throughput, but are 
> trying to minimise the occurrence of long GC pauses) 
>
> https://github.com/overtone/overtone/blob/master/project.clj 
>
> Sam 
>
> --- 
> http://sam.aaron.name 
>
> On 1 Jul 2012, at 23:19, Bruce Durling wrote: 
>
> > Clojurians, 
> > 
> > Interesting post here on different GC settings for Java 7. Does anyone 
> > have any tips/experience about what settings have worked best for them 
> > with clojure and under what circumstances? 
> > 
> > http://www.fasterj.com/articles/oraclecollectors1.shtml 
> > 
> > cheers, 
> > Bruce 
> > 
> > -- 
> > @otfrom | CTO & co-founder @MastodonC | mastodonc.com 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clojure@googlegroups.com 
> > Note that posts from new members are moderated - please be patient with 
> your first post. 
> > To unsubscribe from this group, send email to 
> > clojure+unsubscr...@googlegroups.com 
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Java 7 & GC Settings

[Edward Garson]

For those deploying to Oracle Java 7, an updated GC reference (including 
valid combinations) is available at 
http://www.fasterj.com/articles/oraclecollectors1.shtml.

Regards

Edward

On Tuesday, July 3, 2012 5:48:15 AM UTC-4, Niels van Klaveren wrote:
>
> I haven't got much experience with large scale Clojure environments, but I 
> do know something from managing a lot of JVM production environments. The 
> biggest lesson is: All applications behave differently, usually more so in 
> type of application than JVM language used. No hard and fast rules can be 
> given, monitoring and tweaking GC under representative load is usually 
> necessary.
>
> Basically, most settings you see in the article are pretty much obsolete.
> To start off with a new application, there's usually two issues you need 
> to ask yourself:
>
> 1) Can the application be deployed multicore ?
> 2) How important is user interaction ?
>
> With a bit of luck, you don't need to worry about the amount of cores 
> nowadays. That means in the Young Generation you use the ParNewGC (default 
> in JVM 6 & 7). If cores are limited (especially single-core) it might be 
> necessary to dip into the obsolete settings.
>
> If you need the application to do a job from start to finish fastest (f.i. 
> calculations), with as little overhead in GC, but can tolerate a lot of 
> pauses, then you can use the default GC (MarkSweepCompact). You could use 
> ConcurrentMarkSweep as well, since on multicore machines this can 
> outperform MSC, and usually is pretty much on par with it. The only 
> exception for using MSC is when the CPU load maxes out while there's enough 
> memory available (because if memory maxes out, the CPU load from GC)
>
> If you need user interaction to be as smooth as possible (f.i. webservers 
> / webservices), use ConcurrentMarkSweep. CMS falls back to MSC when the Old 
> Generation gets too fragmented for large Young Generation objects to be 
> promoted into it, causing a full GC because the heap needs to get compacted.
>
> In theory, if this situation arises, the G1 GC collector would be a better 
> choice, because it incrementally compacts the heap. However, in a LOT of 
> applications I've seen CMS behave better pause-wise than G1, so I wouldn't 
> start off with it.
>
> To monitor GC performance, use the JVM parameters:
> -Xloggc:./gclog.txt
> -XX:+PrintGCDetails
>
> This will write a log with GC information from the start of the JVM, which 
> can be parsed with several tools like 
> HPJmeteror
>  
> GCviewer . After seeing how GC 
> behaves in your application under load, you can start tweaking. Other 
> useful links for GC info:
>
> Gil Tene's (Azul) presentation on Java VM Garbage Collection 
> 
> Alexey Ragozin's GC parameter 
> referencepage
>  (including PDF)
>
> Regards,
>
> Niels
>
> On Monday, July 2, 2012 12:19:35 AM UTC+2, Bruce Durling wrote:
>>
>> Clojurians, 
>>
>> Interesting post here on different GC settings for Java 7. Does anyone 
>> have any tips/experience about what settings have worked best for them 
>> with clojure and under what circumstances? 
>>
>> http://www.fasterj.com/articles/oraclecollectors1.shtml 
>>
>> cheers, 
>> Bruce 
>>
>> -- 
>> @otfrom | CTO & co-founder @MastodonC | mastodonc.com 
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Java 7 & GC Settings

[Sam Aaron]

Hi Bruce,

at the bottom of this file you can see the options we use in Overtone to try 
and reduce latency (i.e. we're not so worried about throughput, but are trying 
to minimise the occurrence of long GC pauses)

https://github.com/overtone/overtone/blob/master/project.clj

Sam

---
http://sam.aaron.name

On 1 Jul 2012, at 23:19, Bruce Durling wrote:

> Clojurians,
> 
> Interesting post here on different GC settings for Java 7. Does anyone
> have any tips/experience about what settings have worked best for them
> with clojure and under what circumstances?
> 
> http://www.fasterj.com/articles/oraclecollectors1.shtml
> 
> cheers,
> Bruce
> 
> -- 
> @otfrom | CTO & co-founder @MastodonC | mastodonc.com
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Java 7 & GC Settings

[Niels van Klaveren]

I haven't got much experience with large scale Clojure environments, but I 
do know something from managing a lot of JVM production environments. The 
biggest lesson is: All applications behave differently, usually more so in 
type of application than JVM language used. No hard and fast rules can be 
given, monitoring and tweaking GC under representative load is usually 
necessary.

Basically, most settings you see in the article are pretty much obsolete.
To start off with a new application, there's usually two issues you need to 
ask yourself:

1) Can the application be deployed multicore ?
2) How important is user interaction ?

With a bit of luck, you don't need to worry about the amount of cores 
nowadays. That means in the Young Generation you use the ParNewGC (default 
in JVM 6 & 7). If cores are limited (especially single-core) it might be 
necessary to dip into the obsolete settings.

If you need the application to do a job from start to finish fastest (f.i. 
calculations), with as little overhead in GC, but can tolerate a lot of 
pauses, then you can use the default GC (MarkSweepCompact). You could use 
ConcurrentMarkSweep as well, since on multicore machines this can 
outperform MSC, and usually is pretty much on par with it. The only 
exception for using MSC is when the CPU load maxes out while there's enough 
memory available (because if memory maxes out, the CPU load from GC)

If you need user interaction to be as smooth as possible (f.i. webservers / 
webservices), use ConcurrentMarkSweep. CMS falls back to MSC when the Old 
Generation gets too fragmented for large Young Generation objects to be 
promoted into it, causing a full GC because the heap needs to get compacted.

In theory, if this situation arises, the G1 GC collector would be a better 
choice, because it incrementally compacts the heap. However, in a LOT of 
applications I've seen CMS behave better pause-wise than G1, so I wouldn't 
start off with it.

To monitor GC performance, use the JVM parameters:
-Xloggc:./gclog.txt
-XX:+PrintGCDetails

This will write a log with GC information from the start of the JVM, which 
can be parsed with several tools like 
HPJmeteror
 
GCviewer . After seeing how GC 
behaves in your application under load, you can start tweaking. Other 
useful links for GC info:

Gil Tene's (Azul) presentation on Java VM Garbage Collection 

Alexey Ragozin's GC parameter 
referencepage
 (including PDF)

Regards,

Niels

On Monday, July 2, 2012 12:19:35 AM UTC+2, Bruce Durling wrote:
>
> Clojurians, 
>
> Interesting post here on different GC settings for Java 7. Does anyone 
> have any tips/experience about what settings have worked best for them 
> with clojure and under what circumstances? 
>
> http://www.fasterj.com/articles/oraclecollectors1.shtml 
>
> cheers, 
> Bruce 
>
> -- 
> @otfrom | CTO & co-founder @MastodonC | mastodonc.com 
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Java 7 is out!

[Aaron Bedra]

On 07/28/2011 11:54 AM, Daniel Gagnon wrote:

So, what does it means for Clojure?

Faster execution? Some new interesting stuff in the standard Java library?

And I remember there was something about forkjoin that would be good 
for Clojure, what about that?

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


The short answer here is that the new platform features in Java 7 will 
not get any attention for quite some time.  There is a lot of 
stabilization and maturity that has to happen here before we jump into 
implementation.  There is also the story of the backports.  Since 
Clojure still targets 1.5, this is walking the line of a non-starter.  
This can eventually change, but the benefit that we would see versus the 
impact to the language doesn't make sense right now.


That being said, given other benefits like the new garbage collector and 
more hotspot optimizations, it is very likely that Clojure sees 
performance improvements without doing anything.  We will be taking the 
time to make sure that Clojure runs on Java 7 and address issues that 
come up, but the invoke dynamic and method handle stuff is not in the 
immediate pipeline.  Neither is adding the Java language bits like 
Diamond, try-with-resources, or the rest of them into the Java parts of 
Clojure.


--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Java 7 is out!

[cassiel]

On Jul 29, 1:18 am, Ken Wesson  wrote:
> On the one hand, assuming that Java 7 doesn't outright break anything, [...]

Like loops?

http://www.lucidimagination.com/blog/2011/07/28/dont-use-java-7-for-anything/

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Java 7 is out!

[OGINO Masanori]

>From http://www.oracle.com/technetwork/java/hotspotfaq-138619.html :

---

I would like java to default to -server. I have a lot of scripts which
I cannot change (or do not want to change). Is there any way to do
this?
Since Java SE 5.0, with the exception of 32-bit Windows, the server VM
will automatically be selected on server-class machines. The
definition of a server-class machine may change from release to
release, so please check the appropriate ergonomics document for the
definition for your release. For 5.0, it's Ergonomics in the 5.0
Java[tm] Virtual Machine.

Are both -client and -server VM modes available in 64-bitJava?
Currently only the Java HotSpot Server VM supports 64-bit operation,
and the -server option is implicit with the use of -d64. This is
subject to change in a future release.

---

So 32-bit Windows JRE matters, right?

-- 
Name:  OGINO Masanori (荻野 雅紀)
E-mail: masanori.og...@gmail.com

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Java 7 is out!

[Bill Robertson]

The new JVM really starts fast. Clojure users will like that. I also
noticed that (at least for 64-bit) that the Windows version only comes
with the hotspot compiler. No client jvm. I haven't checked 32-bit.
This is a big change, because previous 32-bit JRE's only came w/
client. I had never checked the 64-bit.

I also agree that clojure is more able to take advantage of JDK 7,
since you tend to compile at runtime, you could just detect which JVM
you're running and install the fancier invokedynamic compiler. I've
seen claims that that won't really benefit Clojure, but I think that
determination ought to be left to measurement rather than guesswork.
One potential issue would be AOT compiled code, you would probably
want it to default to the old way, and have the option to compile with
the new compiler, should such a thing ever come into existence.

Apache Derby manages to pack multiple JDBC versions into the same jar.
I think, at runtime, its basically o.k. as long as you get the
dependencies right and never touch the wrong version's classes, the
classloader will not load them.



On Jul 28, 8:18 pm, OGINO Masanori  wrote:
> AFAIK using InvokeDynamic *requires* Java7, so I think it will be done
> if Java7 gets default and it fits for Clojure.
>
> However, for example, new HotSpot gains more performance then Clojure
> may also gain if you use Java7...
> (but you can't force everyone to use Java7 of course.)
>
> Also, you can call new libraries even if they are not used Clojure itself.
> (You may tell users your code works with Java7)
>
> --
> Name:  OGINO Masanori (荻野 雅紀)
> E-mail: masanori.og...@gmail.com

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Java 7 is out!

[OGINO Masanori]

AFAIK using InvokeDynamic *requires* Java7, so I think it will be done
if Java7 gets default and it fits for Clojure.

However, for example, new HotSpot gains more performance then Clojure
may also gain if you use Java7...
(but you can't force everyone to use Java7 of course.)

Also, you can call new libraries even if they are not used Clojure itself.
(You may tell users your code works with Java7)

-- 
Name:  OGINO Masanori (荻野 雅紀)
E-mail: masanori.og...@gmail.com

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Java 7 is out!

[Ken Wesson]

On Thu, Jul 28, 2011 at 7:32 PM, Kenny Stone  wrote:
> Can clojure take advantage of  some features if they are available?  I know
> the JRuby dudes are pretty excited about invoke dynamic...

I'm not really sure there's a single answer to that question.

On the one hand, assuming that Java 7 doesn't outright break anything,
just using it to run new or existing Clojure code gets you any new
Hotspot optimizations, the new G1 garbage collector, and (with new
Clojure code) access to new library functionality via interop.

On the other hand, invokedynamic won't instantly get you anything. If
Clojure can benefit from it at all, one *could* in principle modify
Compiler.java to try to detect whether it's running on a JVM that
supports the instruction or not, and to generate code that uses
invokedynamic only if it is.

As for using hypothetical new library functionality to implement parts
of clojure.core or clojure.lang, that would create a big backward
compatibility headache and should probably be avoided for now. Third
party libraries that provide functionality based on, say, fork-join
can certainly be made available though.

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Java 7 is out!

[Tal Liron]

I have to agree with this. In fact, it would be much easier to
integrate into Clojure than JRuby (or other JVM languages).

I know the Clojure Java source code pretty well, and wouldn't mind
playing with it a bit to see how feasible it is.

The ideal deployment solution would be to have an extra jar with the
JVM7 stuff that does not interfere with the core code. I'll have to
see how feasible that is.

-Tal

On Jul 28, 6:32 pm, Kenny Stone  wrote:
> Can clojure take advantage of  some features if they are available?  I know
> the JRuby dudes are pretty excited about invoke dynamic...
>
> Kenny
>
> On Thu, Jul 28, 2011 at 6:14 PM, Sean Corfield wrote:
>
>
>
>
>
>
>
> > On Thu, Jul 28, 2011 at 8:54 AM, Daniel Gagnon 
> > wrote:
> > > So, what does it means for Clojure?
>
> > It's not going to mean anything for a long time. Clojure still
> > supports Java 5 so it is probably going to be years before Java 7 is
> > mainstream enough that Clojure can _require_ it.
> > --
> > Sean A Corfield -- (904) 302-SEAN
> > An Architect's View --http://corfield.org/
> > World Singles, LLC. --http://worldsingles.com/
> > Railo Technologies, Inc. --http://www.getrailo.com/
>
> > "Perfection is the enemy of the good."
> > -- Gustave Flaubert, French realist novelist (1821-1880)
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Java 7 is out!

[Kenny Stone]

Can clojure take advantage of  some features if they are available?  I know
the JRuby dudes are pretty excited about invoke dynamic...

Kenny

On Thu, Jul 28, 2011 at 6:14 PM, Sean Corfield wrote:

> On Thu, Jul 28, 2011 at 8:54 AM, Daniel Gagnon 
> wrote:
> > So, what does it means for Clojure?
>
> It's not going to mean anything for a long time. Clojure still
> supports Java 5 so it is probably going to be years before Java 7 is
> mainstream enough that Clojure can _require_ it.
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
> Railo Technologies, Inc. -- http://www.getrailo.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Java 7 is out!

[Sean Corfield]

On Thu, Jul 28, 2011 at 8:54 AM, Daniel Gagnon  wrote:
> So, what does it means for Clojure?

It's not going to mean anything for a long time. Clojure still
supports Java 5 so it is probably going to be years before Java 7 is
mainstream enough that Clojure can _require_ it.
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: java 7

[Peter Schuller]

> A branch is certainly a possibility. But from what I've heard, the primary
> benefit of invokedynamic is convenience for language implementors. The
> performance benefits, if any, are modest.

If your language is doing dynamic dispatch a lot, invokedynamic can be
game-changing since suddenly the JIT has the potential to optimize in
ways similar to invokevirtual.

As far as I know, the main issue with clojure is that it is not heavy
on dynamic dispatch. Regular function calls and protocols don't
benefit from invokedynamic I think, so the performance benefit would
seem to be less than for something like groovy/ruby/python/etc. If
you're doing normal invokevirtual/invokestatic calls on types of known
type, and the performance impact is coming from things like boxing and
the fundamental nature of the data structures, I don't believe
invokedynamic will be expected to help much in the general case (but I
am certainly no expert here).

Would not multimethods be the main candidate for invokedynamic?

-- 
/ Peter Schuller

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: java 7

[Stuart Sierra]

A branch is certainly a possibility. But from what I've heard, the primary 
benefit of invokedynamic is convenience for language implementors. The 
performance benefits, if any, are modest.

-S
clojure.com

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: java 7

[Marko Koci?]

If Java 7 gives Clojure significant performance boost (invokedynamic and 
frields) wouldn't it make sense to have separate versions of Clojure that 
will be optimized for target JRE version?

I suppose that only small part of clojure codebase would be affected, with 
small improvements to build process.

I think that Groovy used to have "standard" and "jdk-1.4" releases, and 
there are other projects that are doing so.

Regards,
Marko Kocić

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: java 7

[Stuart Sierra]

So far, Clojure has targeted JVMs that are widely used in enterprise Java 
environments. That's why it still targets JDK 1.5 instead of 1.6. So if/when 
Java 7 arrives, Clojure probably wouldn't switch until it is widely 
deployed.

-S

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: java 7

[Ken Wesson]

On Tue, Jan 4, 2011 at 5:21 PM, Devrim Baris Acar  wrote:
> Hi list,
> I wonder what would Clojure exploit from Java 7 .
> Any ideas?

If Java 7 ever actually arrives, that question could become
interesting. But I'm not holding my breath. :)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Java 7 is adding dynamics

[MarkSwanson]

On Apr 9, 9:31 am, Alen Ribic  wrote:
> I came across this 
> posthttp://www.baptiste-wicht.com/2010/04/java-7-more-dynamics/
> and though this would be a good place to share.

The article seems to say that using this API instead of reflection
will make dynamic calls "almost the same as a standard call.".
Fascinating!

I wonder how much work it would be to modify Clojure to use the new
API automatically if it was present in the current JVM.

* Primitive Return Values *

I wondered if this new API could be used to specify primitive return
types so Clojure could be extended to create IFns that return int. I
found a text form of JSR 292 and it contained this gem:
(source: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001131.html)

1.3 Any call to a method in Dynamic accepts an optional type
parameter
which specifies the return type of the call site's descriptor.  The
type parameter may any type whatever, including void or a primitive
type.

Lau's latest experiment with fluid dynamics showed a 9794x speed
improvement by using native types for all of his calculations (and by
getting rid of reflection overhead):
http://www.bestinclass.dk/index.php/2010/03/functional-fluid-dynamics-in-clojure/

It looks like we'll soon have the JVM features available to get ~ this
speedup without having to resort to macros or arrays.

The thought of this makes me smile. I wish I wasn't in crunch mode
right now because this would be my personal fun project.

Cheers.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

To unsubscribe, reply using "remove me" as the subject.

Re: Java 7, nio, and createFile

[youngblood.carl]

Works beautifully. Thank you sir.

On Oct 28, 10:40 pm, Alex Osborne  wrote:
> youngblood.carl wrote:
> > When I try and call createFile from clojure:
> > (.createFile path)
>
> > I get an exception that there is no field named createFile.
>
> If I remember correctly variable argument Java methods, which is what
> that "..." syntax means:
>
>    abstract Path createFile(FileAttribute... attrs) {}
>
> are actually just syntactic sugar for an array argument:
>
>    abstract Path createFile(FileAttribute[] attrs) {}
>
> so try:
>
>    (.createFile path (make-array FileAttribute 0))
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Java 7, nio, and createFile

[Alex Osborne]

youngblood.carl wrote:
> When I try and call createFile from clojure:
> (.createFile path)
> 
> I get an exception that there is no field named createFile.

If I remember correctly variable argument Java methods, which is what 
that "..." syntax means:

   abstract Path createFile(FileAttribute... attrs) {}

are actually just syntactic sugar for an array argument:

   abstract Path createFile(FileAttribute[] attrs) {}

so try:

   (.createFile path (make-array FileAttribute 0))

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---