Re: [rvm-research] turning off zeroing

Thank you all for your input. It helps! I have two questions:

(1) The OS can also zero pages before handing them out to user level libraries. Since Jikes RVM uses mmap to reserve memory for program heap, is it possible there is duplication of effort. Specifically, there is get_zeroed_page() in the kernel. Why is that not enough to provide memory safety?

(2) Do Jikes RVM (and JVMs in general) zero mature spaces? Copying is implicit initialization. Are there optimizations in place to elide zeroing of mature space? I guess the JVM can not entirely elide zeroing of mature spaces. Because the mutator may decide to pre-tenure objects in which case, the memory returned should be zeroed. 

Thanks, 
Shoaib

> On Sep 17, 2018, at 3:27 AM, Robin Garner <[email protected]> wrote:
> 
> Zeroing was studied by Xi Yang et. al. in
> 
> http://dx.doi.org/10.1145/2076021.2048092
> 
> and for plans with a contiguous nursery it is controlled by command-line option -X:gc:nurseryZeroing.
> 
> 
> Zeroing is done differently in different policies.  In a SegregatedFreeList, fresh blocks are zeroed in bulk when they are first added to a size class (SegregatedFreeListSpace::expandSizeClass).  When partially allocated blocks are reused, free cells are zeroed as the block is swept (SegregatedFreeListSpace::makeFreeList).
> 
> In a CopySpace, memory is zeroed whenever new pages are allocated (MonotonePageResource:allocPages).
> 
> 
> The zeroing strategy is (to the best of our knowledge at the time) done to
> a) comply with Java semantics (as Mike and Eliot point out, Java will crash if it's not done)
> b) Take advantage of spatial locality - we try to zero memory that is close to an existing memory reference
> c) Improve temporal locality - we try to zero objects shortly before they are written to.
> d) Exploit hardware features (e.g. with non-temporal concurrent zeroing)
> 
> More generally,
> 
> > My analysis shows that a huge fraction of total writes in Java applications happen to nursery.
> 
> Yes, I think this is true for most benchmarks.  The phrase "young, hot objects" has been used in my hearing :)
> 
> > Specifically, I would like to breakdown nursery writes into those due to bulk zeroing, and the rest.
> 
> Non-concurrent zeroing of the nursery happens in only one place (line 193 in MonotonePageResource) , so it should be easy enough to isolate in performance counters.
> 
> cheers
> 
> On 15/09/18 11:15, Michael Bond wrote:
>> I agree with Eliot that not zeroing memory would be incorrect -- and would almost certainly crash GC -- but it would be interesting to see exactly what happens / how it happens. :)
>> 
>> I believe performing zeroing of an object's bytes at allocation time is incorrect given the possibility of memory access reordering performed by the compiler and hardware. Another thread could potentially "see" a recently allocated object's un-zeroed bytes before they've been zeroed by the allocating thread. (That said, it's unlikely to see such behavior on Jikes RVM + x86 because Jikes RVM doesn't presently do much redundant memory access removal, and x86 enforces TSO.) In contrast, I think bulk zeroing happens in way that synchronizes the zeroing with all mutator threads.
>> 
>> Anyway, bulk zeroing is performed in a different place (maybe by a different thread?) from ordinary mutator writes, so it might not be too hard to differentiate the two kinds of writes.
>> 
>> Cheers,
>> Mike
>> 
>> On 09/13/2018 09:33 PM, Eliot Moss wrote:
>>> On 9/13/2018 2:25 PM, Shoaib Akram wrote:
>>> 
>>>> I am investigating writes in Java applications. My analysis shows that a huge fraction of total writes in Java applications happen to nursery. I would like to understand this more. Specifically, I would like to breakdown nursery writes into those due to bulk zeroing, and the rest. My question is is it possible to completely turn off zeroing in Jikes RVM. And would that still lead to correct application behavior? I understand the Java specification prohibits this, but just for understanding purposes, would that be possible to tease apart the effects?
>>> 
>>> How else would you guarantee Java semantics and not break applications?
>>> Java assumes that fields not mentioned are zeroed, and it is ok to read
>>> them.  Imagine a pointer field with garbage in it, and you try to follow
>>> it ...   or the GC tries to follow it ...
>>> 
>>> It is, on the other hand, possible (in principle anyway) to move around
>>> when/how zeroing happens.  It could be done way beforehand; it could be
>>> done a block at a time as space is parceled out to threads.  In theory
>>> you could also do individual object zeroing in the allocator OR you
>>> could augment the code generated by NEW to directly store zeroes to the
>>> fields (makes more sense for scalar objects than arrays, where bulk
>>> zeroing is needed ...).
>>> 
>>> Regards - Eliot Moss
>>> 
>>> 
>>> _______________________________________________
>>> Jikesrvm-researchers mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>> 
>> 
>> 
>> _______________________________________________
>> Jikesrvm-researchers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
> 
> 
> 
> _______________________________________________
> Jikesrvm-researchers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers