RFR (S): 8078669: G1 applies SurvivorAlignmentInBytes to both survivor and old gen

[Filipp Zhinkin]

Hi Thomas,

sorry for a late reply, I've missed your previous question.

At the moment I can't suggest any good solution,
but I'll try to play with these tests and find out how to deal
with allocations in threads other then main one.
I'll put a comment in JDK-8081688 then.

Regards,
Filipp.

On Tue, Jun 2, 2015 at 3:54 PM, Thomas Schatzl
<thomas.schatzl at oracle.com> wrote:
> Hi all,
>
> On Mon, 2015-05-18 at 10:58 +0200, Thomas Schatzl wrote:
>> Hi,
>>
>> On Wed, 2015-05-13 at 21:57 +0300, Filipp Zhinkin wrote:
>> > Hi Thomas,
>> >
>> > On Wed, May 13, 2015 at 5:33 PM, Thomas Schatzl
>> > <thomas.schatzl at oracle.com> wrote:
>> > > Hi all,
>> > >
>> > >   can I have reviews for the following small fix: since JDK-8060025
>> > > survivor alignment has been applied to both survivor and old gen regions
>> > > (if enabled of course).
>> > >
>> > > This has gone unnoticed, because the tests somehow detected that in this
>> > > situation everyhing is fine due to "someone else that allocated
>> > > objects".
>> >
>> > Without such check tests may fail when executed with JFR or some agent.
>> > If it's an issue, then I guess it will be better to improve it instead
>> > of eliminating at all.
>>
>>   do you have any suggestion to fix this issue? I see no way how the
>> java application or the VM would be able to distinguish between objects
>> allocated by the application or any java agent.
>>
>> This check seems to make the test useless as at the moment it will
>> always "detect" that someone else allocated objects.
>
>   since there were no particular comments on how to fix this, and I do
> not have any good idea about this either, I reverted the change that
> removed that check.
>
> Also because while testing some unrelated change, this test failed once.
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8078669/webrev.1/
> Incremental webrev:
> http://cr.openjdk.java.net/~tschatzl/8078669/webrev.0_to_1/
>
> I created JDK-8081688 to investigate alternatives for the test.
>
> Thanks,
>   Thomas
>
>