RFR 8087198: G1 card refinement: batching, sorting, joining, prefetching

[Thomas Schatzl]

Hi,

On Thu, 2015-06-18 at 18:43 +0000, Erik Österlund wrote:
> Hi Thomas,
> 
> Den 18/06/15 08:58 skrev Thomas Schatzl <thomas.schatzl at oracle.com>:
> 
> >Hi,
> >
> >  some notes about the changes: the change does not compile as is, it
> >does not compile without precompiled headers, or in (fast/slow)debug
> >mode.
> >
[...]
> 
> I completely understand, and I'm sorry if my patches did not compile for
> you. I believe JPRT was designed for this very purpose so that these
> things would not happen, and I do unfortunately not have access to it. If
> I did, I could always make sure every patch compiled out of the box on all
> of your platforms before submitting changes. As it is, I can only see that
> it compiled on my platform (OS X + clang v6) and hope it works for others
> too. I could compile my prefetching patch without precompiled headers and
> have no idea why it won't compile on gcc 4.8.2.
> 
> With that being said, I removed the printf and changed that new[] operator
> to use the NEW_C_HEAP_ARRAY macros instead to make assertions in fastdebug
> happy. Sorry about those.
> 
> New webrev:
> http://cr.openjdk.java.net/~eosterlund/g1_experiments/card_refinement/webre
> v.01/
> 
> incremental:
> http://cr.openjdk.java.net/~eosterlund/g1_experiments/card_refinement/webre
> v.01_inc/
> 
> Again, this works on my platform without prefix headers in release and
> fastdebug, and I'm sorry if it does not work on your platform - I cannot
> test it.
> 
> As far as the barrier elision patch goes, it is not a proposed fix by any
> means. It was more of a curiosity and an intentionally /experimental/
> proof-of-concept prototype to demonstrate it's possible to do it so that
> if somebody is interested, it might be worth sitting down and doing it
> properly (without deoptimizing as wildly and breaking a few assertions in
> fastdebug that deoptimization shouldn't happen during GC which it totally
> now does, and do it in concurrent mark not only system gc). Sorry if I was
> not clear enough about this patch being highly experimental.
> 
> Anyway, here is a patch to fix the issue of compiling without prefix
> header so you should be able to compile and run it in release mode without
> precompiled headers:
> 
> New webrev:
> http://cr.openjdk.java.net/~eosterlund/g1_experiments/dynamic_barrier_elisi
> on/webrev.01/
> 
> incremental:
> http://cr.openjdk.java.net/~eosterlund/g1_experiments/dynamic_barrier_elisi
> on/webrev.01_inc/
> 
> Again, sorry for the trouble. I'll be more careful next time. Maybe
> submitting experimental ideas and patches is not a good idea...

 don't worry too much :) It's really nice to talk about these things,
and try out new stuff and think about it.

My response probably sounded a bit grumpy because it took a few jprt
runs (which each take a while and then when you get back from another
task you get a failure notification, need to dig through the logs, fix
stuff and resubmit) to create builds for the platforms I wanted to try
out (e.g. x64/linux, sparc/solaris) "quickly".

I am aware that particularly the dynamic barrier elision stuff is more
experimental, but for many benchmarks class unloading does not matter. I
think there is a lot of potential if the compiler were a bit more aware
about what the garbage collection does.

Thanks a lot for your effort,
  Thomas