Re: Unsafe getLong/getLongVolatile has to read 8 bytes. It atomic / synchronized?
If you can use Java 11, Take a look to the VarHandle API, using VarHandles is as fast as using Unsafe, but it does not crash. For an explanation of the different order modes, [ https://gee.cs.oswego.edu/dl/html/j9mm.html | https://gee.cs.oswego.edu/dl/html/j9mm.html ] Bonus answer: as far as i know, VMs do not rely on C++ atomics but generates their own assembly codes (for the interpreter and for the JITs). regards, Rémi > From: "Fred Castaneras" > To: "mechanical-sympathy" > Sent: Friday, June 9, 2023 12:07:53 AM > Subject: Unsafe getLong/getLongVolatile has to read 8 bytes. It atomic / > synchronized? > Hello, > So I know the difference between getLong and getLongVolatile => visibility. By > using getLongVolatile I avoid any thread/process cache and I can be sure to > read the latest contents from memory. Great! But how about synchronization / > atomicity? Do any of these two methods (getLong and getLongVolatile) will > protect me from a writer in another process writing my 8 bytes while I'm > reading them? > From practical experience using this, I would think so, but just wanted to run > that question through you guys to see what you have to say about that. Perhaps > only if the writer is also using putLong and putLongVolatile? What about if > the > writer is writing byte by byte with putByte or putByteVolatile? Would this > situation cause a race-condition between reader and writer? > And a bonus questions: > How such synchronization / atomicity would be implemented at the C level by > Unsafe? Is the C source code of Unsafe available somewhere so we can take a > look to find out? > -Fred > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email > to [ mailto:mechanical-sympathy+unsubscr...@googlegroups.com | > mechanical-sympathy+unsubscr...@googlegroups.com ] . > To view this discussion on the web, visit [ > https://groups.google.com/d/msgid/mechanical-sympathy/0b8a3784-5df3-4648-9d3c-918ab4694564n%40googlegroups.com?utm_medium=email&utm_source=footer > | > https://groups.google.com/d/msgid/mechanical-sympathy/0b8a3784-5df3-4648-9d3c-918ab4694564n%40googlegroups.com > ] . -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/1891937154.76839809.1686322028788.JavaMail.zimbra%40univ-eiffel.fr.
Re: Compute in a lock free way
> From: "Dain Ironfoot"
> To: "mechanical-sympathy"
> Sent: Saturday, June 4, 2022 5:11:49 PM
> Subject: Re: Compute in a lock free way
> Thank you so much Remi!!
> I took your advice of using CAS to update both of them and came up with this
> (Can't use record as still on JDK 11).
> Does this look ok?
I think you can separate the concurrency part from the algorithm part and
always have the reference initialized to avoid those pesky nulls, like this
public final class Computer {
private static final class Stat {
private final BigDecimal sum;
private final int count;
public Stat(BigDecimal sum, int count) {
this.sum = sum;
this.count = count;
}
public Stat add(double value) {
return new Stat(sum.add(BigDecimal.valueOf(value)), count + 1);
}
public double compute() {
return sum.divide(BigDecimal.valueOf(count)).doubleValue();
}
}
private final AtomicReference statReference;
public Computer() {
this.statReference = new AtomicReference<>(new Stat(BigDecimal.ZERO, 0));
}
public void add(double value) {
statReference.getAndUpdate(s -> s.add(value));
}
public double compute() {
return statReference.get().compute();
}
}
> public final class Computer {
> public static class Stat{
> private final BigDecimal sum;
> private final int count;
> public Stat(BigDecimal sum, int count){
> this.sum = sum;
> this.count = count;
> }
> }
> private final AtomicReference statReference;
> public Computer ( ){
> this.statReference = new AtomicReference<>();
> }
> public final void add ( int value ){
> Stat oldStat = null;
> Stat newStat = null;
> do{
> oldStat = statReference.get();
> BigDecimal newSum = BigDecimal. valueOf (value);
> BigDecimal newStatCheck = (oldStat == null ) ? newSum :
> oldStat.sum.add(newSum);
> int newCount = (oldStat == null ) ? 1 : oldStat.count + 1;
> newStat = new Stat( newStatCheck, newCount);
> }while( !statReference.compareAndSet(oldStat, newStat) );
> }
> public final double compute ( ){
> Stat stat = statReference.get();
> if( stat == null ){
> return 0;
> }else {
> return stat.sum.divide(BigDecimal. valueOf (stat.count)).doubleValue();
> }
> }
> On Saturday, June 4, 2022 at 3:45:50 AM UTC-5 fo...@univ-mlv.fr wrote:
>>> From: "Dain Ironfoot" < [ https://partage.u-pem.fr/mail |
>>> vicva...@gmail.com ] >
>>> To: "mechanical-sympathy" < [ https://partage.u-pem.fr/mail |
>>> mechanica...@googlegroups.com ] >
>>> Sent: Saturday, June 4, 2022 12:53:55 AM
>>> Subject: Compute in a lock free way
>>> Hello,
>>> I am writing a class to calculate average of prices. We use it to generate
>>> buy/sell signal for some financial instruments therefore latency is crucial.
>>> Prices are sent via different threads therefore class needs to be
>>> thread-safe.
>>> Am I correct in understanding that I have to use a lock to make the two
>>> operations (adding and incrementing) atomic? I have looked at
>>> AtomicLong/LongAdder/LongAccumulator but looks like they can only sum the
>>> numbers atomically.
>>> In other words, there is no way to do this in a lock-free manner?
>> you can group them in an object and do a CAS (see VarHandle.compareAndSet) on
>> the references
>> record Stat(BigDecimal sum, int count) { }
>> public final class Computer {
>> private volatile Stat stat;
>> public void add(double value) {
>> // do a CAS between stat and new Stat(BigDecimal.valueOf(value), stat.count
>> + 1)
>> }
>> }
>> BTW in your example, rwLock, readLock and writeLock should be declared final
>> to
>> avoid any publication issues,
>> see [
>> https://stackoverflow.com/questions/1621435/not-thread-safe-object-publishing
>> |
>> https://stackoverflow.com/questions/1621435/not-thread-safe-object-publishing
>> ]
>> regards,
>> Rémi
>>> Thank you!
>>> public final class Computer{
>>> private ReentrantReadWriteLock rwLock;
>>> private ReadLock readLock;
>>> private WriteLock writeLock;
>>> private BigDecimal sum;
>>> private int count;
>>> public AverageCalculatorThreadSafeImplementation2( ){
>>> this.rwLock = new ReentrantReadWriteLock();
>>> this.readLock = rwLock.readLock();
>>> this.writeLock = rwLock.writeLock();
>>> this.sum = new BigDecimal(0);
>>> }
>>> public final void add( double value ){
>>> writeLock.lock();
>>> try{
>>> sum = sum.add( BigDecimal. valueOf (value) );
>>> ++count;
>>> }finally{
>>> writeLock.unlock();
>>> }
>>> }
>>> public final double compute( ){
>>> readLock.lock();
>>> try{
>>> return sum.divide(BigDecimal. valueOf (count)).doubleValue();
>>> }finally{
>>> readLock.unlock();
>>> }
>>> }
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "mechanical-sympathy" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email
>>> to [ https://partage.u-pem.fr/mail | mechanical-symp...@googlegroups.com ] .
>>> To view this discussion on the web, visit [
>>> https://groups.google.com/d/msgid/mechanical-sympathy/2d083587-2ee1-4f8f-a7ee-a99062a6ef5cn%40googlegroups.c
Re: Compute in a lock free way
- Original Message - > From: "Laurynas Biveinis" > To: "mechanical-sympathy" > Sent: Saturday, June 4, 2022 11:03:28 AM > Subject: Re: Compute in a lock free way >> I am writing a class to calculate average of prices. We use it to generate >> buy/sell signal for some financial instruments therefore latency is crucial. >> Prices are sent via different threads therefore class needs to be >> thread-safe. >> >> Am I correct in understanding that I have to use a lock to make the two >> operations (adding and incrementing) atomic? I have looked at >> AtomicLong/LongAdder/LongAccumulator but looks like they can only sum the >> numbers atomically. >> >> In other words, there is no way to do this in a lock-free manner? > > I am not much of an expert here but I have done exactly this. The mean > and count were packed into a single 128-bit value, which was then > updated with x86_64 DWCAS operation (LOCK CMPXCHG16B). It was slower > than a locking version though. I think that is because 1) 128-bit > atomics are more limited than 64-bit ones on x86_64, i.e. to load the > 128 bit value you still have to do CAS instead of simple load, > resulting in a more expensive implementation; You do not have to, on x86_64 the SIMD mov operations are atomic on 128 bits. > 2) under high concurrency this implementation trades a contended lock for a > contended 128-bit atomic, gaining nothing for scalability. To scale, > I'd look into per-thread averages with occasional global aggregation, > but I'm not sure your use case allows this > > > -- > Laurynas Rémi > > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email > to mechanical-sympathy+unsubscr...@googlegroups.com. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/mechanical-sympathy/CAHkCEVePWi7ZQ6UagR_WX%2B_fJeGR3yLeC1td02nZHV_iKH%2Bgeg%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/393058532.2017386.1654335563970.JavaMail.zimbra%40u-pem.fr.
Re: Compute in a lock free way
> From: "Dain Ironfoot"
> To: "mechanical-sympathy"
> Sent: Saturday, June 4, 2022 12:53:55 AM
> Subject: Compute in a lock free way
> Hello,
> I am writing a class to calculate average of prices. We use it to generate
> buy/sell signal for some financial instruments therefore latency is crucial.
> Prices are sent via different threads therefore class needs to be thread-safe.
> Am I correct in understanding that I have to use a lock to make the two
> operations (adding and incrementing) atomic? I have looked at
> AtomicLong/LongAdder/LongAccumulator but looks like they can only sum the
> numbers atomically.
> In other words, there is no way to do this in a lock-free manner?
you can group them in an object and do a CAS (see VarHandle.compareAndSet) on
the references
record Stat(BigDecimal sum, int count) { }
public final class Computer {
private volatile Stat stat;
public void add(double value) {
// do a CAS between stat and new Stat(BigDecimal.valueOf(value), stat.count +
1)
}
}
BTW in your example, rwLock, readLock and writeLock should be declared final to
avoid any publication issues,
see [
https://stackoverflow.com/questions/1621435/not-thread-safe-object-publishing |
https://stackoverflow.com/questions/1621435/not-thread-safe-object-publishing ]
regards,
Rémi
> Thank you!
> public final class Computer{
> private ReentrantReadWriteLock rwLock;
> private ReadLock readLock;
> private WriteLock writeLock;
> private BigDecimal sum;
> private int count;
> public AverageCalculatorThreadSafeImplementation2( ){
> this.rwLock = new ReentrantReadWriteLock();
> this.readLock = rwLock.readLock();
> this.writeLock = rwLock.writeLock();
> this.sum = new BigDecimal(0);
> }
> public final void add( double value ){
> writeLock.lock();
> try{
> sum = sum.add( BigDecimal. valueOf (value) );
> ++count;
> }finally{
> writeLock.unlock();
> }
> }
> public final double compute( ){
> readLock.lock();
> try{
> return sum.divide(BigDecimal. valueOf (count)).doubleValue();
> }finally{
> readLock.unlock();
> }
> }
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email
> to [ mailto:mechanical-sympathy+unsubscr...@googlegroups.com |
> mechanical-sympathy+unsubscr...@googlegroups.com ] .
> To view this discussion on the web, visit [
> https://groups.google.com/d/msgid/mechanical-sympathy/2d083587-2ee1-4f8f-a7ee-a99062a6ef5cn%40googlegroups.com?utm_medium=email&utm_source=footer
> |
> https://groups.google.com/d/msgid/mechanical-sympathy/2d083587-2ee1-4f8f-a7ee-a99062a6ef5cn%40googlegroups.com
> ] .
--
You received this message because you are subscribed to the Google Groups
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/mechanical-sympathy/145240008.2007500.1654332340634.JavaMail.zimbra%40u-pem.fr.
Re: Megamorphic virtual call optimization in Java
> From: "r r"
> To: "mechanical-sympathy"
> Sent: Saturday, February 5, 2022 12:20:12 PM
> Subject: Megamorphic virtual call optimization in Java
> Hello,
> we know that there are some techniques that make virtual calls not so
> expensive
> in JVM like Inline Cache or Polymorphic Inline Cache.
> Let's consider the following situation:
> Base is an interface.
> public void f(Base[] b) {
> for(int i = 0; i < b.length; i++) {
> b[i].m();
> }
> }
> I see from my profiler that calling virtual (interface) method m is relatively
> expensive.
> f is on the hot path and it was compiled to machine code (C2) but I see that
> call to m is a real virtual call. It means that it was not optimised by JVM.
> The question is, how to deal with a such situation? Obviously, I cannot make
> the
> method m not virtual here because it requires a serious redesign.
> Can I do anything or I have to accept it? I was thinking how to "force" or
> "convince" a JVM to
> 1. use polymorphic inline cache here - the number of different types in b is
> quite low - between 4-5 types.
> 2. to unroll this loop - length of b is also relatively small. After an unroll
> it is possible that Inline Cache will be helpful here.
I've recently implemented a small library for that kind of stuff.
[ https://github.com/forax/macro | https://github.com/forax/macro ]
The idea is to see b[i].m() or f(Base[] b) as a method call and extract
constants from that method call, the library allows you to choose if a value is
a constant or f(value) is a constant (in case of the array Base[].length is a
constant) and to decide the policy when it's not a real constant (fail, use a
monomorphic inlining cache or use a polymorphic inlining cache).
It uses java.lang.invoke under the hood so everything tend to be inlined.
> Thanks in advance for any advices.
> Regards,
regards,
Rémi
--
You received this message because you are subscribed to the Google Groups
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/mechanical-sympathy/1998782990.10616957.1644061571789.JavaMail.zimbra%40u-pem.fr.
Re: Tools for understanding GPUs?
> De: "Henri Tremblay" > À: "mechanical-sympathy" > Envoyé: Lundi 22 Mars 2021 12:17:23 > Objet: Re: Tools for understanding GPUs? > I learned playing with Aparapi ( [ https://aparapi.com/ | > https://aparapi.com/ ] > ). > It's not super complicated but you need to jump right in mechanical sympathy > with GPU. To decide vector length and type of memory used. It makes a huge > difference. > I would love to tell you to try Java 16 and the Vector API but it doesn't seem > to support GPU. Just AVX. That's my understanding at least. yes, The Vector API support AVX, AVX-2 and AVX-512 and also NEON but do not support GPUs. Rémi > On Sun, 21 Mar 2021 at 14:36, William Pietri < [ mailto:will...@scissor.com | > will...@scissor.com ] > wrote: >> Years of coding, performance tuning, and ops work have given me some level of >> mechanical sympathy, albeit nothing like many of the contributors to this >> list. >> But now dealing with GPUs I feel like a noob again. 8704 cores! And I feel >> like >> I'm peering through a keyhole trying to figure out what's going on in there. >> These days I'm working on the Anti-Defamation League's Online Hate Index. We >> are >> creating ML models to spot many kinds of hate, and we aim to apply them at >> scale to high-volume sources like social media. Luckily, ML experts are >> handling the modeling. I'm mainly working on the "at scale" part. As a >> non-profit, optimizing for cost is especially important to us, so I really >> need >> to understand the performance. >> What tools and resources do folks here like for developing their intuitions >> about GPU activity? And if you have ML-specific resources, even better. >> Thanks, >> William >> -- >> You received this message because you are subscribed to the Google Groups >> "mechanical-sympathy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email >> to [ mailto:mechanical-sympathy+unsubscr...@googlegroups.com | >> mechanical-sympathy+unsubscr...@googlegroups.com ] . >> To view this discussion on the web, visit [ >> https://groups.google.com/d/msgid/mechanical-sympathy/895470ac-05fc-c2f5-526f-66b33d5cd65d%40scissor.com?utm_medium=email&utm_source=footer >> | >> https://groups.google.com/d/msgid/mechanical-sympathy/895470ac-05fc-c2f5-526f-66b33d5cd65d%40scissor.com >> ] . > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email > to [ mailto:mechanical-sympathy+unsubscr...@googlegroups.com | > mechanical-sympathy+unsubscr...@googlegroups.com ] . > To view this discussion on the web, visit [ > https://groups.google.com/d/msgid/mechanical-sympathy/CADZL2%3DtNxpPjTCx6v5V5kgmWG09H2g2y_ffk-%2Bmq5N3K8Nmm%2BQ%40mail.gmail.com?utm_medium=email&utm_source=footer > | > https://groups.google.com/d/msgid/mechanical-sympathy/CADZL2%3DtNxpPjTCx6v5V5kgmWG09H2g2y_ffk-%2Bmq5N3K8Nmm%2BQ%40mail.gmail.com > ] . -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/756072569.728250.1616419011146.JavaMail.zimbra%40u-pem.fr.
Re: Best way to dynamically spin Java classes?
> De: "stevenselectronicmail" > À: "mechanical-sympathy" > Envoyé: Vendredi 1 Mai 2020 17:51:47 > Objet: Re: Best way to dynamically spin Java classes? > Huh > I've often thought about doing similar. > Two nits: > 1. > RT.java is clever, I know ClassValue was probably the way to do things but > couldn't figure out how to do it. But it's simpler to just write to a static > field to the class anyway. it's not that easy if you want the field to be final too, because you don't control when a static block is executed, and if it is not final, users of the proxy API can mess with it because the API provide them a lookup to the proxy > One advantage of creating new classloaders over defineHiddenClass is you can > just pass in the data as part of the classloader. Yes, using the classloader is what most of the dynamic languages JRuby or Groovy do. If you take a look the source of MethodHandles.Lookup, internally the VM use a something called the classData that is taken as parameter of define(...) and stored in a static field by the VM (it's not a true static field because you can not access it using regular bytecode but it is stored in the same space). When it will become part of the offcial API, defineHiddenClass will becomes even easier to use. > 2. > I wouldn't even bother with a traditional constructor but just use > MethodHandles > to set the delegate field. I want the field to be final. Final fields of Hidden Class are truly final for the JIT, so i get better perf if a proxy is, by example, stored in a static final, so has a good citizen, i'm using a constructor :) Also because final really means final, you can not use reflection or java.lang.invoke to set it after the fact. > Anyway very cool what defineHiddenClass will enable. yes, all these features were available but only internally for the jdk, i think since jdk 7, finding a safe way to expose them take times. regards, Rémi > On Sunday, April 26, 2020 at 10:31:20 AM UTC-7, Remi Forax wrote: >> Shameless plug, >> i've written a simple library that shows how lookup.defineHiddenClass [1] >> can be >> used to implement dynamic proxies >> [ https://github.com/forax/hidden_proxy | >> https://github.com/forax/hidden_proxy >> ] >> regards, >> Rémi >> [1] [ >> https://download.java.net/java/early_access/jdk15/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte%5B%5D,boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...) >> | >> https://download.java.net/java/early_access/jdk15/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte%5B%5D,boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...) >> ] >>> De: "Dr Heinz M. Kabutz" < [ javascript-blocked: | he...@javaspecialists.eu >>> ] > >>> À: "mechanical-sympathy" < [ javascript-blocked: | >>> mechanica...@googlegroups.com >>> ] > >>> Envoyé: Dimanche 26 Avril 2020 19:11:53 >>> Objet: Re: Best way to dynamically spin Java classes? >>> In Java 15 we will have hidden classes, which seem like the right model for >>> what >>> you are trying to do. >>> On Sun, 26 Apr 2020 at 19:36, Steven Stewart-Gallus < [ javascript-blocked: >>> | >>> stevensele...@gmail.com ] > wrote: >>>> I'm spinning a lot of classes dynamically for an interpreter. >>>> I'm not sure the best way to load the classes into the VM. >>>> Aside from Unsafe's defineAnonymousClass what's the best way to load >>>> classes >>>> into the VM? >>>> I believe I could create a new classloader for each spun class but IIRC >>>> classloaders are expensive. >>>> I believe as much as possible I'd want to reuse MethodHandle and >>>> LambdaMetafactory to rely on the JVMs use of defineAnonymousClass. >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "mechanical-sympathy" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email >>>> to [ javascript-blocked: | >>>> mechanical-sympathy+unsubscr...@googlegroups.com ] . >>>> To view this discussion on the web, visit [ >>>> https://groups.google.com/d/msgid/mechanical-sympathy/8ded7316-7675-4747-afe5-5150a7b6009e%40googlegroups.com >>>> | >>>> https://groups.google.com/d/msgid/mechanical-sympathy/8ded7316-7675-4747-afe5-5150a7b6009e%40googlegroups.com >>>> ] . >>> --
Re: Best way to dynamically spin Java classes?
Shameless plug, i've written a simple library that shows how lookup.defineHiddenClass [1] can be used to implement dynamic proxies [ https://github.com/forax/hidden_proxy | https://github.com/forax/hidden_proxy ] regards, Rémi [1] [ https://download.java.net/java/early_access/jdk15/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte%5B%5D,boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...) | https://download.java.net/java/early_access/jdk15/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte%5B%5D,boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...) ] > De: "Dr Heinz M. Kabutz" > À: "mechanical-sympathy" > Envoyé: Dimanche 26 Avril 2020 19:11:53 > Objet: Re: Best way to dynamically spin Java classes? > In Java 15 we will have hidden classes, which seem like the right model for > what > you are trying to do. > On Sun, 26 Apr 2020 at 19:36, Steven Stewart-Gallus < [ > mailto:stevenselectronicm...@gmail.com | stevenselectronicm...@gmail.com ] > > wrote: >> I'm spinning a lot of classes dynamically for an interpreter. >> I'm not sure the best way to load the classes into the VM. >> Aside from Unsafe's defineAnonymousClass what's the best way to load classes >> into the VM? >> I believe I could create a new classloader for each spun class but IIRC >> classloaders are expensive. >> I believe as much as possible I'd want to reuse MethodHandle and >> LambdaMetafactory to rely on the JVMs use of defineAnonymousClass. >> -- >> You received this message because you are subscribed to the Google Groups >> "mechanical-sympathy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email >> to [ mailto:mechanical-sympathy%2bunsubscr...@googlegroups.com | >> mechanical-sympathy+unsubscr...@googlegroups.com ] . >> To view this discussion on the web, visit [ >> https://groups.google.com/d/msgid/mechanical-sympathy/8ded7316-7675-4747-afe5-5150a7b6009e%40googlegroups.com >> | >> https://groups.google.com/d/msgid/mechanical-sympathy/8ded7316-7675-4747-afe5-5150a7b6009e%40googlegroups.com >> ] . > -- > Dr Heinz M. Kabutz (PhD CompSci) > Author of "The Java(tm) Specialists' Newsletter" > Sun/Oracle Java Champion > JavaOne Rockstar Speaker > [ http://www.javaspecialists.eu/ | http://www.javaspecialists.eu ] > Tel: +30 69 75 595 262 > Skype: kabutz > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email > to [ mailto:mechanical-sympathy+unsubscr...@googlegroups.com | > mechanical-sympathy+unsubscr...@googlegroups.com ] . > To view this discussion on the web, visit [ > https://groups.google.com/d/msgid/mechanical-sympathy/CACLL95rS-FtOi2511BqezhszD2ejxPp9BPUBFNUOnNNFndco_Q%40mail.gmail.com?utm_medium=email&utm_source=footer > | > https://groups.google.com/d/msgid/mechanical-sympathy/CACLL95rS-FtOi2511BqezhszD2ejxPp9BPUBFNUOnNNFndco_Q%40mail.gmail.com > ] . -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/54047174.1146571.1587922273948.JavaMail.zimbra%40u-pem.fr.
Re: does call site polymorphism factor in method overrides?
> De: "Vitaly Davidovich" > À: "mechanical-sympathy" > Envoyé: Lundi 30 Décembre 2019 19:43:27 > Objet: Re: does call site polymorphism factor in method overrides? > On Mon, Dec 30, 2019 at 1:09 PM Remi Forax < [ mailto:fo...@univ-mlv.fr | > fo...@univ-mlv.fr ] > wrote: >>> De: "Brian Harris" < [ mailto:brianfromore...@gmail.com | >>> brianfromore...@gmail.com ] > >>> À: "mechanical-sympathy" < [ mailto:mechanical-sympathy@googlegroups.com | >>> mechanical-sympathy@googlegroups.com ] > >>> Envoyé: Lundi 30 Décembre 2019 17:13:38 >>> Objet: Re: does call site polymorphism factor in method overrides? >>> Good to know Vitaly! >>> So a poor example then. Better example is an abstract class with a method >>> implementation that no subtypes override, yet multiple subtypes are found >>> to be >>> the receiver of a particular call site. Should we expect a monomorphic call >>> site in that case. >>> On Sun, Dec 29, 2019 at 12:42 PM Vitaly Davidovich < [ >>> mailto:vita...@gmail.com >>> | vita...@gmail.com ] > wrote: >>>> On Sun, Dec 29, 2019 at 10:22 AM Brian Harris < [ >>>> mailto:brianfromore...@gmail.com | brianfromore...@gmail.com ] > wrote: >>>>> Hello! >>>>> I was hoping to get one point of clarification about avoiding megamorphic >>>>> call >>>>> sites, after reading these excellent articles: >>>>> [ >>>>> http://www.insightfullogic.com/2014/May/12/fast-and-megamorphic-what-influences-method-invoca/ >>>>> | >>>>> http://www.insightfullogic.com/2014/May/12/fast-and-megamorphic-what-influences-method-invoca/ >>>>> ] >>>>> [ https://shipilev.net/blog/2015/black-magic-method-dispatch/ | >>>>> https://shipilev.net/blog/2015/black-magic-method-dispatch/ ] >>>>> [ https://gist.github.com/djspiewak/464c11307cabc80171c90397d4ec34ef | >>>>> https://gist.github.com/djspiewak/464c11307cabc80171c90397d4ec34ef ] >>>>> When the runtime type of the call receiver is being observed, is it >>>>> considered >>>>> whether that type actually overrides the method in question? For example, >>>>> when >>>>> the method is an interface's default method that none of the runtime call >>>>> receivers override, can we expect to get a monomorphic call site >>>>> regardless of >>>>> how many different receiver types are observed at runtime, given there is >>>>> only >>>>> one method body to invoke? >>>> In Hotspot, CHA is currently (AFAIK) disabled for default methods ( >>>> [ https://bugs.openjdk.java.net/browse/JDK-8036580 | >>>> https://bugs.openjdk.java.net/browse/JDK-8036580 ] ). So you have to be >>>> careful >>>> putting hot code into them. Overriding the method in the impl and just >>>> calling >>>> super will at least restore some performance if type profiling at the >>>> callsite >>>> helps. >> CHA only avoids one cheap cmp + jump that will perfectly predicted, so i'm >> not >> sure you will able be to see any perf difference apart from using a micro >> benchmark. >> And as far as i remember, CHA has never worked for abstract methods and >> nobody >> care. > Yeah, I don’t think CHA works for a type-megamorphic callsite that targets the > same method in the type hierarchy. I might be wrong, but pretty sure Hotspot > doesn’t handle this case - it ends up being a virtual call if there’s no > dominant receiver type. no, you're right. It's a known weakness of c2. But as far as i remember, it works with graal. > The big (potential) optimization loss here would be inlining; branch + call > overhead itself is unlikely to matter modulo truly trivial code called in a > tight loop. Missed optimizations due to inlining failure is the real problem. >>>>> Thanks >>>>> Brian >> Rémi Rémi -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/1385072861.66143.1577732212518.JavaMail.zimbra%40u-pem.fr.
Re: does call site polymorphism factor in method overrides?
> De: "Brian Harris" > À: "mechanical-sympathy" > Envoyé: Lundi 30 Décembre 2019 17:13:38 > Objet: Re: does call site polymorphism factor in method overrides? > Good to know Vitaly! > So a poor example then. Better example is an abstract class with a method > implementation that no subtypes override, yet multiple subtypes are found to > be > the receiver of a particular call site. Should we expect a monomorphic call > site in that case. > On Sun, Dec 29, 2019 at 12:42 PM Vitaly Davidovich < [ > mailto:vita...@gmail.com > | vita...@gmail.com ] > wrote: >> On Sun, Dec 29, 2019 at 10:22 AM Brian Harris < [ >> mailto:brianfromore...@gmail.com | brianfromore...@gmail.com ] > wrote: >>> Hello! >>> I was hoping to get one point of clarification about avoiding megamorphic >>> call >>> sites, after reading these excellent articles: >>> [ >>> http://www.insightfullogic.com/2014/May/12/fast-and-megamorphic-what-influences-method-invoca/ >>> | >>> http://www.insightfullogic.com/2014/May/12/fast-and-megamorphic-what-influences-method-invoca/ >>> ] >>> [ https://shipilev.net/blog/2015/black-magic-method-dispatch/ | >>> https://shipilev.net/blog/2015/black-magic-method-dispatch/ ] >>> [ https://gist.github.com/djspiewak/464c11307cabc80171c90397d4ec34ef | >>> https://gist.github.com/djspiewak/464c11307cabc80171c90397d4ec34ef ] >>> When the runtime type of the call receiver is being observed, is it >>> considered >>> whether that type actually overrides the method in question? For example, >>> when >>> the method is an interface's default method that none of the runtime call >>> receivers override, can we expect to get a monomorphic call site regardless >>> of >>> how many different receiver types are observed at runtime, given there is >>> only >>> one method body to invoke? >> In Hotspot, CHA is currently (AFAIK) disabled for default methods ( >> [ https://bugs.openjdk.java.net/browse/JDK-8036580 | >> https://bugs.openjdk.java.net/browse/JDK-8036580 ] ). So you have to be >> careful >> putting hot code into them. Overriding the method in the impl and just >> calling >> super will at least restore some performance if type profiling at the >> callsite >> helps. CHA only avoids one cheap cmp + jump that will perfectly predicted, so i'm not sure you will able be to see any perf difference apart from using a micro benchmark. And as far as i remember, CHA has never worked for abstract methods and nobody care. >>> Thanks >>> Brian Rémi -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/197490853.62864.1577729341131.JavaMail.zimbra%40u-pem.fr.
Re: Exotic classes
> De: "Steven Stewart-Gallus"
> À: "mechanical-sympathy"
> Envoyé: Samedi 27 Avril 2019 00:15:07
> Objet: Re: Exotic classes
> It seems to me you have to do a lot of hacky stuff to get around the "ugly"
> API
> as you call it.
> Maybe it'd be better to separate out the ObjectSupport class into two separate
> classes, a HasherSupport class and an EqualsSupport class.
> interface HashSupport < T > {
> public static < T > HashSupport < T > of ( Lookup lookup , String ... fields
> ) {
> var mh = createMh ( lookup , fields );
> return ( obj ) -> {
> mh . invokeExact ( obj );
> };
> }
> int hashCode ( T obj );
> }
> and similar for EqualsSupport.
One usual issue with people hand writing equals and hashCode is that they
doesn't play well together because there are not using the same set of fields,
grouping together the implementation of equals and hashCode alleviate this
issue.
> I feel like ObjectSupport is a bit nebulous and open ended and you'd
> inevitably
> end up needing more support methods such as a toString method.
yes, toString and perhaps compare, but i want to get right equals and hashCode
first.
Rémi
> On Friday, April 26, 2019 at 8:13:17 AM UTC-7, Remi Forax wrote:
>>> De: "Steven Stewart-Gallus" < [ javascript-blocked: |
>>> stevensele...@gmail.com ]
>>> >
>>> À: "mechanical-sympathy" < [ javascript-blocked: |
>>> mechanica...@googlegroups.com
>>> ] >
>>> Envoyé: Vendredi 26 Avril 2019 01:51:47
>>> Objet: Re: Exotic classes
>> Hi Steven,
>> thanks for spending some time on this,
>>> 1. Why
>>> public abstract class ObjectSupport {
>>> public abstract boolean equals ( Object self , Object other );
>>> public abstract int hashCode ();
>>> public static ObjectSupport of ( Lookup lookup , String ... fields ) {
>>> // impl details
>>> }
>>> // impl details
>>> }
>>> and not something like?
>>> interface ObjectSupport < T > {
>>> public boolean equals ( T self , T other );
>>> public int hashCode ( T obj );
>>> public static < T , U extends ObjectSupport < T >> T of ( Lookup lookup ,
>>> Class
>>> < U > iface , Class < T > obj ) {
>>> // impl details
>>> }
>>> }
>>> @Retention ( RetentionPolicy . RUNTIME )
>>> @Target ( ElementType . FIELD )
>>> @interface ObjectSupportField {
>>> }
>> There are three questions, why not use an interface, why not use generics to
>> make the API more typesafe and why not use an annotation to mark the fields,
>> (1), it should be an interface, yes :
>> (2), yes, the API can be more typesafe, i've implemented that. BTW, the
>> correct
>> type of equals() if generified is (T, Object), because you can call
>> equals(Person, String), it should return false.
>> (3),the API you propose can be built on top of the existing one, that's why
>> there is an overload of ObjectSupport.of() that takes a function as third
>> parameter
>> see [
>> https://github.com/forax/exotic/blob/master/src/test/java/com.github.forax.exotic/com/github/forax/exotic/ObjectSupportTests.java#L310
>> |
>> https://github.com/forax/exotic/blob/master/src/test/java/com.github.forax.exotic/com/github/forax/exotic/ObjectSupportTests.java#L310
>> ]
>> so i've updated the code according to (1) and (2).
>>> 2. I don't understand why you can't use [
>>> https://docs.oracle.com/javase/9/docs/api/java/lang/invoke/MethodHandles.Lookup.html#defineClass-byte:A-
>>> |
>>> https://docs.oracle.com/javase/9/docs/api/java/lang/invoke/MethodHandles.Lookup.html#defineClass-byte:A-
>>> ] instead of unsafe. If you can use [
>>> https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/LambdaMetafactory.html
>>> |
>>> https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/LambdaMetafactory.html
>>> ] things might be easier to optimise because the VM doesn't trust nonstatic
>>> final fields but I don't think you'll need to rely on that.
>> I need a VM anonymous class otherwise the method handles used to implement
>> equals and hashCode are not considered as constant by the JIT. A previous
>> version of the API was using one lambdas for equals and one for hashCode,
>> but it makes the API ugly. see [
>> https://github.com/forax/exotic/commit/168736c43f32520ef6e280db174bf8a848ee4421#diff-0b01bd4ba5740e6b300bfa38e337dd71R13
>> |
>> https://github.com/fora
Re: Exotic classes
> De: "Steven Stewart-Gallus"
> À: "mechanical-sympathy"
> Envoyé: Vendredi 26 Avril 2019 01:51:47
> Objet: Re: Exotic classes
Hi Steven,
thanks for spending some time on this,
> 1. Why
> public abstract class ObjectSupport {
> public abstract boolean equals ( Object self , Object other );
> public abstract int hashCode ();
> public static ObjectSupport of ( Lookup lookup , String ... fields ) {
> // impl details
> }
> // impl details
> }
> and not something like?
> interface ObjectSupport < T > {
> public boolean equals ( T self , T other );
> public int hashCode ( T obj );
> public static < T , U extends ObjectSupport < T >> T of ( Lookup lookup ,
> Class
> < U > iface , Class < T > obj ) {
> // impl details
> }
> }
> @Retention ( RetentionPolicy . RUNTIME )
> @Target ( ElementType . FIELD )
> @interface ObjectSupportField {
> }
There are three questions, why not use an interface, why not use generics to
make the API more typesafe and why not use an annotation to mark the fields,
(1), it should be an interface, yes :
(2), yes, the API can be more typesafe, i've implemented that. BTW, the correct
type of equals() if generified is (T, Object), because you can call
equals(Person, String), it should return false.
(3),the API you propose can be built on top of the existing one, that's why
there is an overload of ObjectSupport.of() that takes a function as third
parameter
see
https://github.com/forax/exotic/blob/master/src/test/java/com.github.forax.exotic/com/github/forax/exotic/ObjectSupportTests.java#L310
so i've updated the code according to (1) and (2).
> 2. I don't understand why you can't use [
> https://docs.oracle.com/javase/9/docs/api/java/lang/invoke/MethodHandles.Lookup.html#defineClass-byte:A-
> |
> https://docs.oracle.com/javase/9/docs/api/java/lang/invoke/MethodHandles.Lookup.html#defineClass-byte:A-
> ] instead of unsafe. If you can use [
> https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/LambdaMetafactory.html
> |
> https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/LambdaMetafactory.html
> ] things might be easier to optimise because the VM doesn't trust nonstatic
> final fields but I don't think you'll need to rely on that.
I need a VM anonymous class otherwise the method handles used to implement
equals and hashCode are not considered as constant by the JIT. A previous
version of the API was using one lambdas for equals and one for hashCode,
but it makes the API ugly. see
https://github.com/forax/exotic/commit/168736c43f32520ef6e280db174bf8a848ee4421#diff-0b01bd4ba5740e6b300bfa38e337dd71R13
> 3. The raw class file isn't always available at runtime so you can't
> necessarily
> use ObjectSupportImpl as a template.
yes, i will inline it (storing it as an array of bytes inside the Java code)
once the API is stable enough.
> 4. [
> https://github.com/forax/exotic/blob/master/src/main/java/com.github.forax.exotic/com/github/forax/exotic/ObjectSupport.java#L180
> |
> https://github.com/forax/exotic/blob/master/src/main/java/com.github.forax.exotic/com/github/forax/exotic/ObjectSupport.java#L180
> ] Pretty sure you want a static final field here. You can do that if you're
> using ObjectSupportImpl as a raw template. Unfortunately defineClass doesn't
> accept arguments so you have to use wonky garbage like a hashmap to pass
> runtime data that can't be embedded in a class file easily.
No need for static fields there because ObjectSupportImpl is loaded as a VM
anonymous class, so the instance fields are considered as constant if the
object itself is a constant (see the answer to your question 2).
There is a JMH test if you want to take a look to the generated assembly code
[
https://github.com/forax/exotic/blob/master/src/test/java/com.github.forax.exotic/com/github/forax/exotic/perf/ObjectSupportBenchMark.java
|
https://github.com/forax/exotic/blob/master/src/test/java/com.github.forax.exotic/com/github/forax/exotic/perf/ObjectSupportBenchMark.java
]
regards,
Rémi
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email
> to [ mailto:mechanical-sympathy+unsubscr...@googlegroups.com |
> mechanical-sympathy+unsubscr...@googlegroups.com ] .
> For more options, visit [ https://groups.google.com/d/optout |
> https://groups.google.com/d/optout ] .
--
You received this message because you are subscribed to the Google Groups
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Exotic classes
> De: "mechanical-sympathy" > À: "mechanical-sympathy" > Envoyé: Mardi 23 Avril 2019 18:23:48 > Objet: Re: Exotic classes > Replies inline > On Monday, April 22, 2019 at 12:37:19 PM UTC-7, Remi Forax wrote: >>> De: "mechanical-sympathy" < [ javascript-blocked: | >>> mechanica...@googlegroups.com ] > >>> À: "mechanical-sympathy" < [ javascript-blocked: | >>> mechanica...@googlegroups.com >>> ] > >>> Envoyé: Lundi 22 Avril 2019 20:25:01 >>> Objet: Re: Exotic classes >>> These classes (especially MostlyConstant) are pretty cool. I have some >>> questions >>> about them: >>> 1. In MostlyConstant I noticed that modifying the constant doesn't call >>> MutableCallSite.syncAll(). Should it? >> yes, you're right from a spec POV i should call syncAll(), >> the thing is that the current OpenJDK implementation doesn't need syncAll, >> but >> it may change in the future or for another implementation. >>> 2. A followup to #1: MutableCallSite.syncAll() doesn't actually seem >>> implemented >>> in OpenJDK. Is it correct to call it? >> yes, it's not implemented because the native part of setTarget() do the >> deopt, >> but it's an implementation detail. >>> 3. In my non-scientific JMH measurements, it seems like modifying the call >>> site >>> takes about 1us. Does that sound about right? From what I can tell modifying >>> the constant is akin to deoptimizing the code and recompiling it, which >>> means >>> that 1us seems really fast. >> it's quite fast but it may be because >> - it may be not optimized yet >> - the VM mark all the different generated assembly codes that reference the >> constant as should be removed from the code cache and will do it later, >> - the VM will not re-optimize directly if a code is deoptimized, but jump in >> the >> interpreter and re-optimize later. > I was running this in a JMH benchmark, and I inspected the Assembly and > Compiler > output; I believe it was reaching c2 before swapping. > A followup question: does deoptimization mean it reverts to a C1 copy of the > code, or directly back to the interpreter? i.e. how much work does it have to > undo? no, for a method, the code generated by c1 is often long gone at the time the code generated by c2 detects that it should deopt. And c1 like c2 generates the code optimistically so even if the code generated by c1 was around, there is a good chance it will have to be de-optimized too. BTW, i've just added a way to have equals and hashCode automatically implemented to exotic [1]. Rémi [1] https://github.com/forax/exotic/blob/master/src/main/java/com.github.forax.exotic/com/github/forax/exotic/ObjectSupport.java#L38 >> so there is a good chance that what you are measuring is not all >> de-optimization >> cost. >> Rémi >>> On Monday, February 26, 2018 at 11:29:19 AM UTC-8, Remi Forax wrote: >>>> Hi all, >>>> i'm preparing a talk at DevoxxFR on how to make a field value, a returned >>>> value, >>>> etc constant for any decent JITs (everything but c1), so i've bundled >>>> together >>>> several patterns i use for implementing dynamic language runtimes into an >>>> Java >>>> API >>>> [ https://github.com/forax/exotic | https://github.com/forax/exotic ] >>>> I would like to have your comments about those exotic classes (it's >>>> already has >>>> been done, it's stupid, it's not thread safe, etc) >>>> regards, >>>> Rémi > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email > to [ mailto:mechanical-sympathy+unsubscr...@googlegroups.com | > mechanical-sympathy+unsubscr...@googlegroups.com ] . > For more options, visit [ https://groups.google.com/d/optout | > https://groups.google.com/d/optout ] . -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Exotic classes
> De: "mechanical-sympathy" > À: "mechanical-sympathy" > Envoyé: Lundi 22 Avril 2019 20:25:01 > Objet: Re: Exotic classes > These classes (especially MostlyConstant) are pretty cool. I have some > questions > about them: > 1. In MostlyConstant I noticed that modifying the constant doesn't call > MutableCallSite.syncAll(). Should it? yes, you're right from a spec POV i should call syncAll(), the thing is that the current OpenJDK implementation doesn't need syncAll, but it may change in the future or for another implementation. > 2. A followup to #1: MutableCallSite.syncAll() doesn't actually seem > implemented > in OpenJDK. Is it correct to call it? yes, it's not implemented because the native part of setTarget() do the deopt, but it's an implementation detail. > 3. In my non-scientific JMH measurements, it seems like modifying the call > site > takes about 1us. Does that sound about right? From what I can tell modifying > the constant is akin to deoptimizing the code and recompiling it, which means > that 1us seems really fast. it's quite fast but it may be because - it may be not optimized yet - the VM mark all the different generated assembly codes that reference the constant as should be removed from the code cache and will do it later, - the VM will not re-optimize directly if a code is deoptimized, but jump in the interpreter and re-optimize later. so there is a good chance that what you are measuring is not all de-optimization cost. Rémi > On Monday, February 26, 2018 at 11:29:19 AM UTC-8, Remi Forax wrote: >> Hi all, >> i'm preparing a talk at DevoxxFR on how to make a field value, a returned >> value, >> etc constant for any decent JITs (everything but c1), so i've bundled >> together >> several patterns i use for implementing dynamic language runtimes into an >> Java >> API >> [ https://github.com/forax/exotic | https://github.com/forax/exotic ] >> I would like to have your comments about those exotic classes (it's already >> has >> been done, it's stupid, it's not thread safe, etc) >> regards, >> Rémi > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email > to [ mailto:mechanical-sympathy+unsubscr...@googlegroups.com | > mechanical-sympathy+unsubscr...@googlegroups.com ] . > For more options, visit [ https://groups.google.com/d/optout | > https://groups.google.com/d/optout ] . -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Exotic classes
Hi Steven, > De: "Steven Stewart-Gallus" > À: "mechanical-sympathy" > Envoyé: Samedi 19 Janvier 2019 05:19:06 > Objet: Re: Exotic classes > On Friday, January 18, 2019 at 5:37:58 AM UTC-8, Rémi Forax wrote >>> no, CHA only works on class, not on interface. > You're probably know better than me. I seem to remember there's something like > that for interfaces but very limited such as if you ever only have ever one > implementation. You have been prescient :) c2 now does CHA on interfaces. https://bugs.openjdk.java.net/browse/JDK-6986483 [...] Rémi -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Exotic classes
> De: "Steven Stewart-Gallus"
> À: "mechanical-sympathy"
> Envoyé: Jeudi 17 Janvier 2019 07:50:13
> Objet: Re: Exotic classes
> I've been working on similar issues trying to optimise something
> heavily. I made a similar class to this one (I even had a similar
> API) but I found I called it MostlyFinal instead.
> private static final MostlyConstant FOO = new MostlyConstant<>(42,
> int.class);
> private static final IntSupplier FOO_GETTER = FOO.intGetter();
> By the way using a different interface than Supplier can give the JVM
> more class hierarchy analysis info and so potentially allow for
> inlining even without static final.
no, CHA only works on class, not on interface.
> You can also simply use a closure in some cases sort of like this:
> interface IntBox {
>int get();
> }
> public IntBox makeBox(int x) {
> return () -> x;
> }
> This is better for inlining because the JVM trusts final fields in VM
> anonymous classes more than yours. Unfortunately
> TrustStaticFinalFields cannot be a thing by default yet for backwards
> compatibility reasons.
> I think a lot of these things are pretty neat but unfortunately hard
> to package in a generic and usable library because people delving into
> these will want to tear into all the internal details for maximum
> performance.
> I don't really understand your StableField class. How is it supposed
> to be any faster than MostlyConstant?
It's not the same semantics, you can not change a StableField more than once so
you have the guarantee that once the field is initialized, no deoptimization
can occur.
The other things is the object is not constant, you will get an exception so
it's hard to misuse that API.
The last point is that i expect that at some point i will change the
implementation so the slowpath will cost less than the slowpath of
MostlyConstant, but i've never had the time to think how to do that in a VM
independant way (i know how to do that with Hotspot only).
> I would suggest if you wanted the best speed (in some ways and at a cost of
> memory) you could spin a
> static final class with a method that returns a constantdynamic entry
> and then return a methodhandle to that entry. This seems possibly
> heavyweight IMO so I'm still thinking about this myself.
better, use a lazy static final field (see [
https://bugs.openjdk.java.net/browse/JDK-8209964), |
https://bugs.openjdk.java.net/browse/JDK-8209964), ]
i.e. tech javac to either emit a ldc to the ConstantDynamic or do a getfield
that will trigger the ConstantDynamic initialization if needed.
> If StringSwitchCallSite being a MutableCallSite seems possibly
> unneeded with a reworked API to me.
but it means that you have if/else branch for String that the program has never
encounter.
I prefer to not add all the branches statically but add then at runtime
dynamically when i know i need then.
> I am highly suspicious TypeSwitch will increase performance in most cases.
> instanceof checks are highly optimized and give info that allow
> further optimizations.
It depends, if instanceof else ... is slow if you have deep hierarchy, if the
test are not in the right order of occurence and if you have too many branches.
But yes, the StringSwitch and the TypeSwitch can be slower/faster than the
equivalent cascade of if/else.
> You might want to consider using/abusing the JVM's own inline caching
> behaviour for interfaces for some dispatching.
A MethodHandles.guardWithTest is exactly that !
> It's not too hard to create a bag of interface implementations at
> runtime that all dispatch to separate CallSite implementations which
> can be faster than exactInvoker/your own MethodHandle lookup logic
> sometimes.
No, believe me, it's hard. It's the reason i've created (with others) the
java.lang.invoke API.
> I considered this for a ThreadLocalCallSite class I was
> making but I'm still not sure about the design.
> So basically one hack to get quicker thread local behaviour is to
> subclass Thread and add your own fields/methods like this:
> ((MyIface)Thread.currentThread()).doSpecific();
> If you add your own bag of interface implementations then you can do
> this dynamically:
> MY_IFACE.invokeExact((BagThread)Thread.currentThread()).bag, ...);
It will not be inlined by the VM :(
About having a ThreadLocalCallSite, as part of project Loom, we are discussing
about how associate a value to a part of the callstack.
Anyway, the VM doesn't have a code cache per thread, there is only a global
code cache.
> I'm not sure about the bytecode generation here though. I don't want
> to be too blase about that.
> It looks like you have some benchmarks setup but I don't see any txt
> files with any perf data listed. I mentioned a lot of gibberish
> earlier but problem my biggest advice would be to add more benchmarks
> and look at your benchmarks again and also get real world usage data.
yes,
at least i should add the benchmark result in the javadoc.
re
Re: jHiccup for .NET?
> De: "Gil Tene" > À: "mechanical-sympathy" > Envoyé: Mardi 28 Août 2018 00:28:00 > Objet: Re: jHiccup for .NET? > There is [ https://github.com/HdrHistogram/HdrHistogram.NET | a great > implementation of HdrHistogram for .NET ] , which makes the rest of what > jHiccup does nearly-trivial to do. I think the main thing keeping from porting > jHiccup itself to .NET is that it's most common use mode is as a java agent > (adding hiccup recording to a java program without modifying it in any way), > and AFAIK .NET does not have a similar agent mechanism. I believe the .NET Profiling API provides something equivalent to the Java agent API. > jHiccup itself is fairly simple and should be easy to port into a library you > can invoke from within your application, and into a standalone program (for > measuring control hiccups on an otherwise idle process). [ > https://github.com/giltene/jHiccup/blob/master/src/main/java/org/jhiccup/HiccupMeter.java > | It's main class ] is only ~800 lines of code, over half of it in comments > and > parameter parsing logic. People have replicated some of it's logic in their C# > stuff before (e.g. Matt Warren [ > http://mattwarren.org/2014/06/23/measuring-the-impact-of-the-net-garbage-collector-an-update/ > | used it here ] ). > -- Gil. Rémi > On Monday, August 27, 2018 at 12:49:15 PM UTC-7, Mark E. Dawson, Jr. wrote: >> Does there exist a port for, or a similar tool to, jHiccup for .NET? > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email > to [ mailto:mechanical-sympathy+unsubscr...@googlegroups.com | > mechanical-sympathy+unsubscr...@googlegroups.com ] . > For more options, visit [ https://groups.google.com/d/optout | > https://groups.google.com/d/optout ] . -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Exotic classes
Hi all, i'm preparing a talk at DevoxxFR on how to make a field value, a returned value, etc constant for any decent JITs (everything but c1), so i've bundled together several patterns i use for implementing dynamic language runtimes into an Java API https://github.com/forax/exotic I would like to have your comments about those exotic classes (it's already has been done, it's stupid, it's not thread safe, etc) regards, Rémi -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Call site (optimizations)
> De: "Francesco Nigro"
> À: "mechanical-sympathy"
> Envoyé: Mardi 30 Janvier 2018 15:13:03
> Objet: Re: Call site (optimizations)
> Gil really thank you for the super detailed answer!
> I'm digesting it and I've found an interesting talk with some of these
> concepts
> referenced/mentioned: https://youtu.be/oH4_unx8eJQ?t=4503
> Douglas Hawkins:"...the compilation is shared by all threads...all threads.
> One
> thread behave badly, all threads suffer."
> After your explanation I would say: "..almost all threads..."
> But considering that is about deopt it doesn't make sense such precise!
> My initial fairytale idea of what a JVM should able to optimize was "probably"
> too imaginative eg 2 threads T1,T2 calling the same static method:
> static void foo(..){
> if(cond){
> uncommonCase();
> }
> }
> T1 with cond = true while T2 with cond = false.
> My "fairytale JVM" were able to optimize each specific call of foo() for the 2
> threads with specific compiled (inlined if small enough) versions that benefit
> each one of the real code paths executed (ie uncommonCase() inlined/compiled
> just for T1).
> Obviously the fairytale optimizations weren't only specific per-thread but per
> call-site too :P
You can hand write you own split loop optimization
static void foo(boolean flag) {
if (flag) {
uncommonCase();
}
}
and create two callsites in Runnable.run() like this
Runable r = () -> {
if(cond) {
for(;;) {
foo(true);
}
} else {
for(;;) {
foo(false);
}
}
};
this only works if everything from runnable.run() to foo() is inlined, so never
in real life :)
> After your answer I'm starting to believe that Santa Claus doesn't exists and
> it's not his fault :)
> Thanks,
> Franz
Rémi
> Il giorno sabato 27 gennaio 2018 18:45:28 UTC+1, Gil Tene ha scritto:
>> Some partial answers inline below, which can probably be summarized with
>> "it's
>> complicated...".
>> On Friday, January 26, 2018 at 8:33:53 AM UTC-8, Francesco Nigro wrote:
>>> HI guys,
>>> in the last period I'm having some fun playing with JItWatch (many thanks to
>>> Chris Newland!!!) and trying to understand a lil' bit more about specific
>>> JVM
>>> optimizations, but suddenly I've found out that I was missing one of the
>>> most
>>> basic definition: call site.
>>> I've several questions around that:
>>> 1. There is a formal definition of call site from the point of view of
>>> the JIT?
>> I don't know about "formal". But a call site is generally any location in the
>> bytecode of one method that explicitly causes a call to another method. These
>> include:
>> classic bytecodes used for invocation:
>> - Virtual method invocation (invokevirtual and invokeinterface, both of which
>> calling a non-static method on an instance), which in Java tends to
>> dynamically
>> be the most common form.
>> - Static method invocations (invokestatic)
>> - Constructor/initializer invocation (invokespecial)
>> - Some other cool stuff (private instance method invocation with
>> invokespecial,
>> native calls, etc.)
>> In addition, you have these "more interesting" things that can be viewed (and
>> treated by the JIT) as call sites:
>> - MethodHandle.invoke*()
>> - reflection based invocation (Method.invoke(), Constructor.newInstance())
>> - invokedynamic (can full of Pandora worms goes here...)
>>>1. I know that there are optimizations specific per call site, but there
>>> is a
>>> list of them somewhere (that is not the OpenJDK source code)?
>> The sort of optimizations that might happen at a call site can evolve over
>> time,
>> and JVMs and JIT can keep adding newer optimizations: Some of the current
>> common call site optimizations include:
>> - simple inlining: the target method is known (e.g. it is a static method, a
>> constructor, or a
>> we-know-there-is-only-one-implementor-of-this-instance-method-for-this-type-and-all-of-its-subtypes),
>> and can be unconditionally inlined at the call site.
>> - guarded inlining: the target method is assumed to be a specific method
>> (which
>> we go ahead and inline), but a check (e.g. the exact type of this animal is
>> actually a dog) is required ahead of the inlined code because we can't prove
>> the assumption is true.
>> - bi-morphic and tri-morphic variants of guarded inlining exist (where two or
>> three different targets are inlined).
>> - Inline cache: A virtual invocation dispatch (which would need to follow the
>> instance's class to locate a target method) is replaced with a guarded static
>> invocation to a specific target on the assumption a specific ("monomorphic")
>> callee type. "bi-morphic" and "tri-morphic" variants of inline cache exist
>> (where one of two or three static callees are called depending on a type
>> check,
>> rather than performing a full virtual dispatch)
>> ...
>> But there are bigger and more subtle things that can be optimized at and
>> around
>> a call site, which may not be directly evident from the calling code itself.
Re: Minimal Value Type
Hi Henry, > De: "Henri Tremblay" > À: "mechanical-sympathy" > Envoyé: Mercredi 27 Décembre 2017 19:47:56 > Objet: Re: Minimal Value Type First, there are actually two specs for value types, the minimal value type which is the one implemented in the early access binaries and "real" value type which will be close (closer) to the value type that will be integrated in Java. The idea of the minimal value type prototype was to see what we need in the VM to support value types without thinking too much about how reference and value type will co-exist, so you declare a value capable class which is an immutable normal Java class and the VM is able to derive a value type from it, the value capable class is the box and the derived value type is the plain value type. Since October, we are moving to a new specs, where java.lang.Object (and any interfaces) are types that hold either a value type or reference type, but currently, there is no real implementation of this spec. > Thanks. It raises a lot of interesting question. > - Will I finally be able to add a primitive type in a generic (since it's a > value type)? that's the plan, but this is not implemented in the minimal value type prototype. I'm currently developing a prototype of the generics part, but it's not clean enough to share (yet!). > - Why not considering everything an universal type (but then how to box unbox > it)? java.lang.Object (and any interfaces) can play the role of that universal type, and we now know how to box a value type on stack (or in an arena that move like the stack), we call that buffering and not boxing because the value type is seen as a reference but not a reference on the heap. > - And do I tell a value type is a value type? With the current prototype, you put the annotation @jdk.incubator.mvt.ValueCapableClass on an immutable class. In the future, javac will have a language support for that (if you take a look to the source, there is already a proto version of that support for testing). Rémi > On 27 December 2017 at 12:13, Jay Askren < [ mailto:jay.ask...@gmail.com | > jay.ask...@gmail.com ] > wrote: >> [ https://www.infoq.com/news/2017/11/ValueTypesNov10 | >> https://www.infoq.com/news/2017/11/ValueTypesNov10 ] >> On Wednesday, December 27, 2017 at 7:54:11 AM UTC-7, Henri Tremblay wrote: >>> Hi Rémi, >>> Highly interesting. >>> For those like me who are too lazy to read an annotated JVM spec, are you >>> aware >>> of a quick summary of how it works somewhere? (over (how to specify in Java >>> code and API changes) and under (JVM instructions) the hood). >>> Thanks, >>> Henri >>> On 27 December 2017 at 07:30, Remi Forax < fo...@univ-mlv.fr > wrote: >>>> Hi all, >>>> seeing the mail from Peter on how to avoid pointer chasing, instead of >>>> using >>>> off-heap data structure, use value types. >>>> Currently, there is a prototype, named the Minimal Value Type, that allows >>>> people to test value types inside the VM. >>>> The spec is here: >>>> [ http://cr.openjdk.java.net/~dlsmith/values.html | >>>> http://cr.openjdk.java.net/~dlsmith/values.html ] >>>> There are an early access build for Linux and MacOs >>>> [ http://jdk.java.net/valhalla/ | http://jdk.java.net/valhalla/ ] >>>> The version of ASM that let you generate the new bytecodes is here: >>>> [ https://gitlab.ow2.org/asm/asm/tree/MINIMAL_VALUE_TYPE | >>>> https://gitlab.ow2.org/asm/asm/tree/MINIMAL_VALUE_TYPE ] >>>> and you can also get compiled version here: >>>> [ https://github.com/forax/valuetypify/tree/master/deps | >>>> https://github.com/forax/valuetypify/tree/master/deps ] >>>> You can use the valuetypifier, that transform Java 8 code to code with >>>> value >>>> types >>>> [ https://github.com/forax/valuetypify | >>>> https://github.com/forax/valuetypify ] >>>> regards, >>>> Rémi >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "mechanical-sympathy" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email >>>> to mechanical-sympathy+unsubscr...@googlegroups.com . >>>> For more options, visit [ https://groups.google.com/d/optout | >>>> https://groups.google.com/d/optout ] . >> -- >> You received this message because you are subscribed to the Google Groups >> "mechanical-sympathy" group. >> To unsubscribe from this
Minimal Value Type
Hi all, seeing the mail from Peter on how to avoid pointer chasing, instead of using off-heap data structure, use value types. Currently, there is a prototype, named the Minimal Value Type, that allows people to test value types inside the VM. The spec is here: http://cr.openjdk.java.net/~dlsmith/values.html There are an early access build for Linux and MacOs http://jdk.java.net/valhalla/ The version of ASM that let you generate the new bytecodes is here: https://gitlab.ow2.org/asm/asm/tree/MINIMAL_VALUE_TYPE and you can also get compiled version here: https://github.com/forax/valuetypify/tree/master/deps You can use the valuetypifier, that transform Java 8 code to code with value types https://github.com/forax/valuetypify regards, Rémi -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Executing thread by JVM.
> De: "John Hening"
> À: "mechanical-sympathy"
> Envoyé: Lundi 13 Novembre 2017 00:17:32
> Objet: Executing thread by JVM.
> Hello,
> I would like to ask for threads in Java. As we know, JVM uses system threads
> (native threads). So, for example it uses Linux threads. In simplification a
> thread is a stack + piece of code to execute.
it depends on the Java VM, for Hotspot (the OpenJDK VM), it uses only one stack
with different kind of stackframes (one stackframe by method activation, method
call if you prefer).
There are different kind of stackframe depending on if the stackframe represent
a call that is executed by the interpreter, a call to C (through JNI), a call
to a JITed method (in fact there are more than one JIT and they do not use the
same calling convention for historical reason), etc.
The stackframe for the interpreter is described here
https://wiki.openjdk.java.net/display/HotSpot/JavaControlStack
> Let's consider:
> Thread t = new Thread (() -> { `any_code` });
> t . start ();
> t . join ();
> `any_code` will be compile to bytecode.
usually as a static method by the compiler at compile time, not at runtime.
> So, how the thread is executed?
you create a native thread, something like pthread_create with a C function
pointer, when you do a pthread_start, the function pointer is executed and it
will either create a stack frame entry that will either execute the code in the
interpreter or a stack frame entry that will execute the JITed code.
> We can assume that that code wouldn't be jited.
No, you can ask the JIT to always generate a JITed code with no interpreter. In
that case, the bytecode will be JITed, transformed to assembly code and the
assembly code will create the stackframe entry, run the code and pop the stack
frame entry at the end. Note that Hotspot is able to deoptimize the code in the
middle of the JITed code, so the created stack frame entry as to be large
enough to take all values from the register and spill them on the stack before
bailing out to the interpreter.
> I cannot understand what is a content of that thread? After all, bytecode must
> be interpreted
again, not necessarily
> by JVM. So, does the thread execute a JVM that interprets a bytecode
> `any_code`?
see above.
Rémi
--
You received this message because you are subscribed to the Google Groups
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Modern Garbage Collection (good article)
> De: "Vitaly Davidovich" > À: mechanical-sympathy@googlegroups.com > Envoyé: Jeudi 22 Décembre 2016 13:46:50 > Objet: Re: Modern Garbage Collection (good article) > It's hard to interpret anecdotes for more than just that - an anecdote :). > Rewrites in general tend to be better (for some definition of better, > performance included) even if done in the same language. yes, it's just an anecdote. > But, I think as a *principle* of favoring lower latency at the cost of > throughput is the right choice for them and how they see Go being used. I don't think it's a good long term strategy for Go even if it can be a good one for how Google uses Go now. There are a lot of tools written in Go, docker/kubernetes are maybe the poster children but for something like InfluxDB (disclaimer, they give me a t-shirt :) ) it's worrying. > Mind you, I'm not a fan nor a user of Go so I'm referring purely to their > stipulated strategy on how to evolve their GC. Rémi > On Thu, Dec 22, 2016 at 7:37 AM Remi Forax < fo...@univ-mlv.fr > wrote: >>> De: "Vitaly Davidovich" < vita...@gmail.com > >>> À: mechanical-sympathy@googlegroups.com >>> Envoyé: Jeudi 22 Décembre 2016 13:12:00 >>> Objet: Re: Modern Garbage Collection (good article) >>> FWIW, I think the Go team is right in favoring lower latency over >>> throughput of >>> their GC given the expected usage scenarios for Go. >>> In fact, most of the (Hotspot based) Java GC horror stories involve very >>> long >>> pauses (G1 and CMS not excluded) - I've yet to hear anyone complain that >>> their >>> "Big Data" servers are too slow because the GC is chipping away at >>> throughput >>> too much (most of those servers aren't CPU bound to begin with or can't >>> become >>> CPU bound due to bottlenecks elsewhere). >> As an anecdote, in my lab, the only go program we had was a program that >> optimizes on the fly a huge homemade RDF store depending on most the frequent >> queries. It was re-written in Java by a Phd student last September. Maybe it >> was slow because of the Go GC avoiding long pauses, but from the perspective >> of >> the team leader, it was just that Go was too slow (and getting slower at each >> release). >>> In the Hotspot world, there's also the unfortunate situation right now >>> where G1 >>> isn't really solving any problem nor advancing the performance (latency) >>> boundaries. In fact, it taxes throughput quite heavily (e.g. significantly >>> more >>> expensive write barriers) but isn't breaking any new ground. >> Rémi >>> On Wed, Dec 21, 2016 at 11:38 PM Zellyn < zel...@gmail.com > wrote: >>>> You might be interested in this Golang-group follow-up thread too… >>>> https://groups.google.com/forum/#!topic/golang-nuts/DyxPz-cQDe4 (naturally >>>> a >>>> more pro-Go >>>> take on things…) >>>> On Wednesday, December 21, 2016 at 8:23:02 AM UTC-5, Greg Young wrote: >>>>> Thought people on here would enjoy this >>>>> https://medium.com/@octskyward/modern-garbage-collection-911ef4f8bd8e#.ptdzwcmq2 >>>>> -- >>>>> Studying for the Turing test >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "mechanical-sympathy" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email >>>> to mechanical-sympathy+unsubscr...@googlegroups.com . >>>> For more options, visit https://groups.google.com/d/optout . >>> -- >>> Sent from my phone >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "mechanical-sympathy" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email >>> to mechanical-sympathy+unsubscr...@googlegroups.com . >>> For more options, visit https://groups.google.com/d/optout . >> -- >> You received this message because you are subscribed to the Google Groups >> "mechanical-sympathy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email >> to mechanical-sympathy+unsubscr...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout . > -- > Sent from my phone > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email > to mechanical-sympathy+unsubscr...@googlegroups.com . > For more options, visit https://groups.google.com/d/optout . -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Modern Garbage Collection (good article)
> De: "Vitaly Davidovich" > À: mechanical-sympathy@googlegroups.com > Envoyé: Jeudi 22 Décembre 2016 13:12:00 > Objet: Re: Modern Garbage Collection (good article) > FWIW, I think the Go team is right in favoring lower latency over throughput > of > their GC given the expected usage scenarios for Go. > In fact, most of the (Hotspot based) Java GC horror stories involve very long > pauses (G1 and CMS not excluded) - I've yet to hear anyone complain that their > "Big Data" servers are too slow because the GC is chipping away at throughput > too much (most of those servers aren't CPU bound to begin with or can't become > CPU bound due to bottlenecks elsewhere). As an anecdote, in my lab, the only go program we had was a program that optimizes on the fly a huge homemade RDF store depending on most the frequent queries. It was re-written in Java by a Phd student last September. Maybe it was slow because of the Go GC avoiding long pauses, but from the perspective of the team leader, it was just that Go was too slow (and getting slower at each release). > In the Hotspot world, there's also the unfortunate situation right now where > G1 > isn't really solving any problem nor advancing the performance (latency) > boundaries. In fact, it taxes throughput quite heavily (e.g. significantly > more > expensive write barriers) but isn't breaking any new ground. Rémi > On Wed, Dec 21, 2016 at 11:38 PM Zellyn < zel...@gmail.com > wrote: >> You might be interested in this Golang-group follow-up thread too… >> https://groups.google.com/forum/#!topic/golang-nuts/DyxPz-cQDe4 (naturally a >> more pro-Go >> take on things…) >> On Wednesday, December 21, 2016 at 8:23:02 AM UTC-5, Greg Young wrote: >>> Thought people on here would enjoy this >>> https://medium.com/@octskyward/modern-garbage-collection-911ef4f8bd8e#.ptdzwcmq2 >>> -- >>> Studying for the Turing test >> -- >> You received this message because you are subscribed to the Google Groups >> "mechanical-sympathy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email >> to mechanical-sympathy+unsubscr...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout . > -- > Sent from my phone > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email > to mechanical-sympathy+unsubscr...@googlegroups.com . > For more options, visit https://groups.google.com/d/optout . -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: private final static optimization
Hi Vitaly,
> De: "Vitaly Davidovich"
> À: mechanical-sympathy@googlegroups.com
> Envoyé: Dimanche 18 Décembre 2016 19:00:04
> Objet: Re: private final static optimization
> It doesn't care about reflection - modifying final fields via reflection is
> undefined by the JLS. Unfortunately, the same optimization isn't done for
> instance finals because some well known frameworks use that facility.
THose frameworks are not wrong, the JLS allows to change final fields when
doing deserialization (see JLS 17.5.3) and it's hard for the JIT to know if the
reflection is used during a deserialization or not.
> Oracle is working on ways to mitigate that in a backcompat manner (deopt when
> it
> detects such modifications).
I think, it's easier in the modular world of 9, you know statically if a module
uses sun.misc.Unsafe (it has to requires jdk.unsupported transitively) and if a
package is open to modification by reflection (the package is declared as open
or the module itself is declared as open). A JIT can use this heuristic instead
of trying to trap and deopt if a final field change which requires a lot of
metadata.
> But static finals work out of the box already without deopt (the modification
> isn't visible if done after code is JIT compiled).
cheers,
Rémi
> On Sun, Dec 18, 2016 at 5:12 AM Peter Veentjer < pe...@hazelcast.com > wrote:
>> Hi Martin,
>> so the JIT is able to remove the if(ENABLED) branch if ENABLED = false?
>> How does it deal with reflection? The JIT is triggered to deoptimize the code
>> when the ENABLED changes?
>> On Sunday, December 18, 2016 at 10:50:48 AM UTC+2, Peter Veentjer wrote:
>>> The following question is one out of curiosity of compiler optimization of
>>> private final static fields.
>>> I created a very contrived example. The idea is to have some kind of switch
>>> that
>>> can be enabled/disabled when the JVM starts up.
>>> public class Foo{
>>> private final static boolean ENABLED = Boolean.getBoolean("bla.enabled");
>>> private int x;
>>> public void foo(int x){
>>> if(ENABLED){
>>> if(x <0) throw new RuntimeException();
>>> }
>>> this.x = x;
>>> }
>>> }
>>> The question is if the JIT is allowed to remove the ENABLED check if
>>> ENABLED is
>>> false. My worry is that due to reflection, one could set the ENABLED to true
>>> and therefor the JIT isn't allowed to remove the ENABLED check.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "mechanical-sympathy" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email
>> to mechanical-sympathy+unsubscr...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout .
> --
> Sent from my phone
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email
> to mechanical-sympathy+unsubscr...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout .
--
You received this message because you are subscribed to the Google Groups
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
