On 02/03/2017 10:26 AM, Chris Newland wrote:
> Do you think the HotSpot designers took this into account but found
> empirically
> that the simple algorithm is adequate (cost complexity outweighs gains and
> hotimp
> methods are generally JIT-compiled together).
Let's ask another question: do
On 01/23/2017 05:42 AM, Дмитрий Пеньков wrote:
> Hello everyone. I have following situation: multiple HotSpot JVMs with
> multiple
> GCs' (ParallelGC) threads on multiple CPUs. I've already seen recommendations
> to
> have min 2 cores per JVM, but in my case it's 80 CPU's and about 200 JVMs.
>
On 01/17/2017 12:55 PM, Vitaly Davidovich wrote:
> Atomicity of values isn't something I'd assume happens automatically. Word
> tearing isn't observable from single threaded code.
On 01/17/2017 09:17 PM, Michael Barker wrote:
> That was my understanding too. Normal load/stores on 32 bit JVMs
(triggered again)
On 01/18/2017 12:33 AM, Sergey Melnikov wrote:
> mov (%rax), %rbx
> cmp %rbx, %rdx
> jxx Lxxx
>
> But if you schedule them this way
>
> mov (%rax), %rbx
> cmp %rbx, %rdx
> ... few instructions
> jxx Lxxx
...doesn't this give up on macro-fusion, and effectively sets up for a
On 10/30/2016 05:55 AM, Peter Veentjer wrote:
> Let me clarify.
> The discussion is around removing the volatile read in the inc method.
Ah, sorry I misinterpreted the question. It usually goes the other way:
the reads vastly outnumber the writes.
Well, since the writer is single-threaded, there
On 10/29/2016 10:13 AM, Peter Veentjer wrote:
> So you get something like this:
>
> public class Counter {
>
> private final AtomicLong c = new AtomicLong();
>
> public void inc(){
> long newValue = c.get()+1;
> c.lazySet(newValue);
> }
>
> public long get(){
>
On 03/03/2017 10:51 AM, Grzegorz Gierlach wrote:
> It passes on x86 however for some reason I'm not 100% sure it is a correct
> implementation. Is there a better way of doing it?
The discussion about "correct", "way of doing it" is irrelevant if you don't
describe what is your intent with this
On 04/29/2017 07:12 PM, Aleksey Shipilev wrote:
> On 04/29/2017 06:56 PM, Aleksey Shipilev wrote:
>> On 04/29/2017 04:56 PM, J Crawford wrote:
>>> The mystery boils down to:
>>>
>>> "/The exact same block of code becomes slower after a busy spin paus
On 12/05/2017 09:26 AM, Mark Price wrote:
> I'm investigating some long time-to-safepoint pauses in oracle/openjdk. The
> application in question
> is also suffering from some fairly nasty I/O problems where latency-sensitive
> threads are being
> descheduled in uninterruptible sleep state due
On 11/17/2017 11:46 PM, John Hening wrote:
> For my eye, common objects in Java, like
>
> newString();
>
> is a CHeapObj. I looked at an implementation of new operator in that class
> and it looks like:
In related news, there is javaClasses.cpp, and therefore Java class library is
written in
On 11/18/2017 01:45 PM, John Hening wrote:
> Thanks for your replies :)
>
> @Aleksey, how to get that?
>
> |-17.12%0.00%org.openjdk.Allperf-31615.map-0x7faaa3b2d125-16.59%OptoRuntime::new_instance_C
> -11.49%InstanceKlass::allocate_instance
> 2.33%BlahBlahBlahCollectedHeap::mem_allocate
On 05/16/2018 07:33 PM, John Hening wrote:
> Subject: JMM- conservative and formal point of view.
There is no "conservative" JMM point of view. There is JSR 133 Cookbook for
Compiler Writers that
describes the conservative implementation, but it is not the JMM itself.
Reductio ad absurdum:
On 05/16/2018 09:19 PM, John Hening wrote:
> By the way, in your transcription you said:
> |
> inta;
>
> volatilebooleanready =false;
>
> voidactor(IntResult1r){
> while(!ready){};
> r.r1 =a;
> }
>
> voidobserver(){
> a =41;
> a =42;
>
On 01/25/2018 03:44 AM, 'Carl Mastrangelo' via mechanical-sympathy wrote:
> Consider the following code:
>
> public class Test {
> static volatile Integer discard;
> public static void main(String [] args) throws InterruptedException {
> printMemory();
> System.gc();
>
On 02/05/2018 09:58 PM, John Hening wrote:
> 1. Why do you find it is a bug in tierred compilation machinery? It is not on
> my eye. The
> compilation level is: C2, level 4
Wait a minute, where exactly does it say "C2, level 4" for you?
I am saying the disassembly you have provided in the
On 8/14/19 9:21 PM, Gil Tene wrote:
> The fact that they visit and parse dead objects in order to identify
> recycle-able memory is what makes them
> sweepers. Other techniques that don't visit dead objects do not perform a
> sweep.
I am trying to understand what is your central argument here.
time,
but we have to be careful to separate what is the "agreed on" definition, and
what is whatever
definition we want to be the emergent one.
> On Thursday, August 15, 2019 at 1:42:23 AM UTC-7, Aleksey Shipilev wrote:
> I am trying to understand what is your cent
On 8/6/19 7:38 AM, Peter Veentjer wrote:
> There is still some confusion on my side. This time it is regarding the
> algorithmic complexity of
> mark-sweep-compact.
>
> The complexity of the mark phase is linear to the live set.
> The complexity of the sweep phase is linear to the heap size.
>
On 7/17/19 9:06 AM, Andriy Plokhotnyuk wrote:
> 1) Using of release (and sometime store-store) fences in all constructors in
> GraalVM:
>
19 matches
Mail list logo
