Re: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining

2016-09-30 Thread Stuart Marks 



On 9/28/16 4:48 AM, Claes Redestad wrote:

as discussed recently on hotspot-compiler-dev[1], having a private class with no
default constructor can lead to C2 failing to inline, due to the synthetic
bridge constructor using a dummy argument of an uninitialized class. This is
really a problem in C2, as well as something which could ultimately be resolved
by nestmates...

However, there is an easy workaround in adding an empty package-private
constructor. In the most recently found case - a microbenchmark stressing
MethodHandles.iteratedLoop - adding this to ArrayList$Itr lead to a 2.5-3x 
speedup.

This is me asking nicely to do a quick-fix for this in java.util.ArrayList$Itr 
now:

Bug: https://bugs.openjdk.java.net/browse/JDK-8166840
Webrev: http://cr.openjdk.java.net/~redestad/8166840/webrev.01/

[1]
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html


Hi, adding the package-access constructor seems like a reasonable thing to do.

However, should there be a comment explaining this? It seems like just having a 
no-op constructor is something that is liable to be cleaned up by a well-meaning 
individual who didn't happen to see this thread. Something like this:


// avoid creation of synthetic class and bridge constructor
Itr() {}

If this really is a problem in C2, should there also be a reference to a Hotspot 
bug that represents this problem?


On the other hand, addition of the constructor does remove a class from the 
runtime image, so maybe it's worth it to keep around even if the Hotspot bug is 
fixed. But having a comment would be good to prevent this code from being 
"cleaned up".


s'marks

Re: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining

2016-09-28 Thread John Rose 
On Sep 28, 2016, at 7:40 AM, Krystal Mok  wrote:
> 
> Let me post out the HotSpot version of the change and let you guys decide
> whether or not you guys want to take that version (which will take care of
> the ArrayList$1 case without the JDK-side change).

My advice is:  Both/and.  IMO the presence of a constant null should unblock
an inline blocked by an unloaded parameter class.  But that will take more 
effort
to do right in the JVM.  In general, constants should have weight with the 
inlining
heuristic.

And, nestmate access at JVM level may be coming also but that's not 
back-portable.
Tech. debt from 1997, yum.

— John

Re: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining

2016-09-28 Thread Ivan Gerasimov 

Hi Claes!

I can handle the backport.

With kind regards,
Ivan


On 28.09.2016 17:37, Claes Redestad wrote:
I dealt with this in isolation deliberately to ease backporting, but I 
don't have the 8u committer rights to do it myself.


/Claes

On 2016-09-28 16:27, Vitaly Davidovich wrote:

Thanks Claes - this is an annoying one!

Will it be backported to 8?

On Wednesday, September 28, 2016, Claes Redestad 
> wrote:


Thanks for the quick reviews!

/Claes

On 2016-09-28 14:14, Remi Forax wrote:

yes,
thumb up.

Rémi


On September 28, 2016 1:51:18 PM GMT+02:00, Michael Haupt
 wrote:

Hi Claes,

yes please. Thumbs up. :-)

Best,

Michael

Am 28.09.2016 um 13:48 schrieb Claes Redestad

:

Hi,

as discussed recently on hotspot-compiler-dev[1],
having a private

class with no default constructor can lead to C2 failing
to inline, due
to the synthetic bridge constructor using a dummy argument
of an
uninitialized class. This is really a problem in C2, as
well as
something which could ultimately be resolved by nestmates...

However, there is an easy workaround in adding an empty

package-private constructor. In the most recently found
case - a
microbenchmark stressing MethodHandles.iteratedLoop -
adding this to
ArrayList$Itr lead to a 2.5-3x speedup.

This is me asking nicely to do a quick-fix for this in

java.util.ArrayList$Itr now:

Bug: https://bugs.openjdk.java.net/browse/JDK-8166840

Webrev:
http://cr.openjdk.java.net/~redestad/8166840/webrev.01/


Thanks!

/Claes

[1]

http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html


--

Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 |
14467 Potsdam,
Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung:
Riesstraße 25,
D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. |
Hertogswetering
163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr.
30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss,
Val Maher
> Oracle is
committed to developing
practices and products that help protect the environment




--
Sent from my phone

Re: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining

2016-09-28 Thread Claes Redestad 

Hi Kris,

right, I don't intend to meander away on a micro-optimization spree and 
chase down every case where we're hurt by this corner case in the JDK 
and elsewhere (I did check that other core collection classes aren't 
affected, though ;-)), but to get this simple and possibly high-impact 
quick fix out of the way to unblock other work I'm doing, specifically 
JDK-8161210


I think everyone would be very happy to get the root issue in HotSpot fixed!

Thanks!

/Claes

On 2016-09-28 16:40, Krystal Mok wrote:

Hi Claes,

For this particular case, this JDK-side change looks good to me.

Let me post out the HotSpot version of the change and let you guys 
decide whether or not you guys want to take that version (which will 
take care of the ArrayList$1 case without the JDK-side change).


Thanks,
Kris

On Wed, Sep 28, 2016 at 4:48 AM, Claes Redestad 
> wrote:


Hi,

as discussed recently on hotspot-compiler-dev[1], having a private
class with no default constructor can lead to C2 failing to
inline, due to the synthetic bridge constructor using a dummy
argument of an uninitialized class. This is really a problem in
C2, as well as something which could ultimately be resolved by
nestmates...

However, there is an easy workaround in adding an empty
package-private constructor. In the most recently found case - a
microbenchmark stressing MethodHandles.iteratedLoop - adding this
to ArrayList$Itr lead to a 2.5-3x speedup.

This is me asking nicely to do a quick-fix for this in
java.util.ArrayList$Itr now:

Bug: https://bugs.openjdk.java.net/browse/JDK-8166840

Webrev: http://cr.openjdk.java.net/~redestad/8166840/webrev.01/


Thanks!

/Claes

[1]

http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html

Re: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining

2016-09-28 Thread Vitaly Davidovich 
On Wed, Sep 28, 2016 at 10:37 AM, Claes Redestad 
wrote:

> I dealt with this in isolation deliberately to ease backporting, but I
> don't have the 8u committer rights to do it myself.
>
Right.  The change seems trivial enough that backporting would be easy.
Who could make the decision on that?

>
> /Claes

Thanks

>
>
> On 2016-09-28 16:27, Vitaly Davidovich wrote:
>
>> Thanks Claes - this is an annoying one!
>>
>> Will it be backported to 8?
>>
>> On Wednesday, September 28, 2016, Claes Redestad <
>> claes.redes...@oracle.com > wrote:
>>
>> Thanks for the quick reviews!
>>
>> /Claes
>>
>> On 2016-09-28 14:14, Remi Forax wrote:
>>
>> yes,
>> thumb up.
>>
>> Rémi
>>
>>
>> On September 28, 2016 1:51:18 PM GMT+02:00, Michael Haupt
>>  wrote:
>>
>> Hi Claes,
>>
>> yes please. Thumbs up. :-)
>>
>> Best,
>>
>> Michael
>>
>> Am 28.09.2016 um 13:48 schrieb Claes Redestad
>>
>> :
>>
>> Hi,
>>
>> as discussed recently on hotspot-compiler-dev[1],
>> having a private
>>
>> class with no default constructor can lead to C2 failing
>> to inline, due
>> to the synthetic bridge constructor using a dummy argument
>> of an
>> uninitialized class. This is really a problem in C2, as
>> well as
>> something which could ultimately be resolved by nestmates...
>>
>> However, there is an easy workaround in adding an empty
>>
>> package-private constructor. In the most recently found
>> case - a
>> microbenchmark stressing MethodHandles.iteratedLoop -
>> adding this to
>> ArrayList$Itr lead to a 2.5-3x speedup.
>>
>> This is me asking nicely to do a quick-fix for this in
>>
>> java.util.ArrayList$Itr now:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166840
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~redestad/8166840/webrev.01/
>> > Eredestad/8166840/webrev.01/>
>>
>>
>> Thanks!
>>
>> /Claes
>>
>> [1]
>>
>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/
>> 2016-September/024407.html
>> > /2016-September/024407.html>
>>
>> --
>> 
>> Dr. Michael Haupt | Principal Member of Technical Staff
>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>> Oracle Java Platform Group | LangTools Team | Nashorn
>> Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 |
>> 14467 Potsdam,
>> Germany
>>
>> ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung:
>> Riesstraße 25,
>> D-80992 München
>> Registergericht: Amtsgericht München, HRA 95603
>>
>> Komplementärin: ORACLE Deutschland Verwaltung B.V. |
>> Hertogswetering
>> 163/167, 3543 AS Utrecht, Niederlande
>> Handelsregister der Handelskammer Midden-Nederland, Nr.
>> 30143697
>> Geschäftsführer: Alexander van der Ven, Jan Schultheiss,
>> Val Maher
>> > > Oracle is
>> committed to developing
>> practices and products that help protect the environment
>>
>>
>>
>>
>> --
>> Sent from my phone
>>
>
>

Re: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining

2016-09-28 Thread Vladimir Ivanov 

Looks good.

Best regards,
Vladimir Ivanov

On 9/28/16 2:48 PM, Claes Redestad wrote:

Hi,

as discussed recently on hotspot-compiler-dev[1], having a private class
with no default constructor can lead to C2 failing to inline, due to the
synthetic bridge constructor using a dummy argument of an uninitialized
class. This is really a problem in C2, as well as something which could
ultimately be resolved by nestmates...

However, there is an easy workaround in adding an empty package-private
constructor. In the most recently found case - a microbenchmark
stressing MethodHandles.iteratedLoop - adding this to ArrayList$Itr lead
to a 2.5-3x speedup.

This is me asking nicely to do a quick-fix for this in
java.util.ArrayList$Itr now:

Bug: https://bugs.openjdk.java.net/browse/JDK-8166840
Webrev: http://cr.openjdk.java.net/~redestad/8166840/webrev.01/

Thanks!

/Claes

[1]
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html

Re: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining

2016-09-28 Thread Claes Redestad 
I dealt with this in isolation deliberately to ease backporting, but I 
don't have the 8u committer rights to do it myself.


/Claes

On 2016-09-28 16:27, Vitaly Davidovich wrote:

Thanks Claes - this is an annoying one!

Will it be backported to 8?

On Wednesday, September 28, 2016, Claes Redestad 
> wrote:


Thanks for the quick reviews!

/Claes

On 2016-09-28 14:14, Remi Forax wrote:

yes,
thumb up.

Rémi


On September 28, 2016 1:51:18 PM GMT+02:00, Michael Haupt
 wrote:

Hi Claes,

yes please. Thumbs up. :-)

Best,

Michael

Am 28.09.2016 um 13:48 schrieb Claes Redestad

:

Hi,

as discussed recently on hotspot-compiler-dev[1],
having a private

class with no default constructor can lead to C2 failing
to inline, due
to the synthetic bridge constructor using a dummy argument
of an
uninitialized class. This is really a problem in C2, as
well as
something which could ultimately be resolved by nestmates...

However, there is an easy workaround in adding an empty

package-private constructor. In the most recently found
case - a
microbenchmark stressing MethodHandles.iteratedLoop -
adding this to
ArrayList$Itr lead to a 2.5-3x speedup.

This is me asking nicely to do a quick-fix for this in

java.util.ArrayList$Itr now:

Bug: https://bugs.openjdk.java.net/browse/JDK-8166840

Webrev:
http://cr.openjdk.java.net/~redestad/8166840/webrev.01/


Thanks!

/Claes

[1]


http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html



-- 



Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 |
14467 Potsdam,
Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung:
Riesstraße 25,
D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. |
Hertogswetering
163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr.
30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss,
Val Maher
> Oracle is
committed to developing
practices and products that help protect the environment




--
Sent from my phone

Re: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining

2016-09-28 Thread Krystal Mok 
Hi Claes,

For this particular case, this JDK-side change looks good to me.

Let me post out the HotSpot version of the change and let you guys decide
whether or not you guys want to take that version (which will take care of
the ArrayList$1 case without the JDK-side change).

Thanks,
Kris

On Wed, Sep 28, 2016 at 4:48 AM, Claes Redestad 
wrote:

> Hi,
>
> as discussed recently on hotspot-compiler-dev[1], having a private class
> with no default constructor can lead to C2 failing to inline, due to the
> synthetic bridge constructor using a dummy argument of an uninitialized
> class. This is really a problem in C2, as well as something which could
> ultimately be resolved by nestmates...
>
> However, there is an easy workaround in adding an empty package-private
> constructor. In the most recently found case - a microbenchmark stressing
> MethodHandles.iteratedLoop - adding this to ArrayList$Itr lead to a 2.5-3x
> speedup.
>
> This is me asking nicely to do a quick-fix for this in
> java.util.ArrayList$Itr now:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166840
> Webrev: http://cr.openjdk.java.net/~redestad/8166840/webrev.01/
>
> Thanks!
>
> /Claes
>
> [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/
> 2016-September/024407.html
>

Re: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining

2016-09-28 Thread Vitaly Davidovich 
Thanks Claes - this is an annoying one!

Will it be backported to 8?

On Wednesday, September 28, 2016, Claes Redestad 
wrote:

> Thanks for the quick reviews!
>
> /Claes
>
> On 2016-09-28 14:14, Remi Forax wrote:
>
>> yes,
>> thumb up.
>>
>> Rémi
>>
>>
>> On September 28, 2016 1:51:18 PM GMT+02:00, Michael Haupt <
>> michael.ha...@oracle.com> wrote:
>>
>>> Hi Claes,
>>>
>>> yes please. Thumbs up. :-)
>>>
>>> Best,
>>>
>>> Michael
>>>
>>> Am 28.09.2016 um 13:48 schrieb Claes Redestad

>>> :
>>>
 Hi,

 as discussed recently on hotspot-compiler-dev[1], having a private

>>> class with no default constructor can lead to C2 failing to inline, due
>>> to the synthetic bridge constructor using a dummy argument of an
>>> uninitialized class. This is really a problem in C2, as well as
>>> something which could ultimately be resolved by nestmates...
>>>
 However, there is an easy workaround in adding an empty

>>> package-private constructor. In the most recently found case - a
>>> microbenchmark stressing MethodHandles.iteratedLoop - adding this to
>>> ArrayList$Itr lead to a 2.5-3x speedup.
>>>
 This is me asking nicely to do a quick-fix for this in

>>> java.util.ArrayList$Itr now:
>>>
 Bug: https://bugs.openjdk.java.net/browse/JDK-8166840
 Webrev: http://cr.openjdk.java.net/~redestad/8166840/webrev.01/

 Thanks!

 /Claes

 [1]

>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/
>>> 2016-September/024407.html
>>>
>>> --
>>>
>>> 
>>> Dr. Michael Haupt | Principal Member of Technical Staff
>>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>>> Oracle Java Platform Group | LangTools Team | Nashorn
>>> Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam,
>>> Germany
>>>
>>> ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25,
>>> D-80992 München
>>> Registergericht: Amtsgericht München, HRA 95603
>>>
>>> Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering
>>> 163/167, 3543 AS Utrecht, Niederlande
>>> Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
>>> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>>>   Oracle is committed to
>>> developing
>>> practices and products that help protect the environment
>>>
>>
>

-- 
Sent from my phone

Re: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining

2016-09-28 Thread Claes Redestad 

Thanks for the quick reviews!

/Claes

On 2016-09-28 14:14, Remi Forax wrote:

yes,
thumb up.

Rémi


On September 28, 2016 1:51:18 PM GMT+02:00, Michael Haupt 
 wrote:

Hi Claes,

yes please. Thumbs up. :-)

Best,

Michael


Am 28.09.2016 um 13:48 schrieb Claes Redestad

:

Hi,

as discussed recently on hotspot-compiler-dev[1], having a private

class with no default constructor can lead to C2 failing to inline, due
to the synthetic bridge constructor using a dummy argument of an
uninitialized class. This is really a problem in C2, as well as
something which could ultimately be resolved by nestmates...

However, there is an easy workaround in adding an empty

package-private constructor. In the most recently found case - a
microbenchmark stressing MethodHandles.iteratedLoop - adding this to
ArrayList$Itr lead to a 2.5-3x speedup.

This is me asking nicely to do a quick-fix for this in

java.util.ArrayList$Itr now:

Bug: https://bugs.openjdk.java.net/browse/JDK-8166840
Webrev: http://cr.openjdk.java.net/~redestad/8166840/webrev.01/

Thanks!

/Claes

[1]

http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html

--


Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam,
Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25,
D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering
163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
Oracle is committed to developing
practices and products that help protect the environment

Re: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining

2016-09-28 Thread Remi Forax 
yes,
thumb up.

Rémi


On September 28, 2016 1:51:18 PM GMT+02:00, Michael Haupt 
 wrote:
>Hi Claes,
>
>yes please. Thumbs up. :-)
>
>Best,
>
>Michael
>
>> Am 28.09.2016 um 13:48 schrieb Claes Redestad
>:
>> 
>> Hi,
>> 
>> as discussed recently on hotspot-compiler-dev[1], having a private
>class with no default constructor can lead to C2 failing to inline, due
>to the synthetic bridge constructor using a dummy argument of an
>uninitialized class. This is really a problem in C2, as well as
>something which could ultimately be resolved by nestmates...
>> 
>> However, there is an easy workaround in adding an empty
>package-private constructor. In the most recently found case - a
>microbenchmark stressing MethodHandles.iteratedLoop - adding this to
>ArrayList$Itr lead to a 2.5-3x speedup.
>> 
>> This is me asking nicely to do a quick-fix for this in
>java.util.ArrayList$Itr now:
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166840
>> Webrev: http://cr.openjdk.java.net/~redestad/8166840/webrev.01/
>> 
>> Thanks!
>> 
>> /Claes
>> 
>> [1]
>http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html
>
>-- 
>
> 
>Dr. Michael Haupt | Principal Member of Technical Staff
>Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>Oracle Java Platform Group | LangTools Team | Nashorn
>Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam,
>Germany
>
>ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25,
>D-80992 München
>Registergericht: Amtsgericht München, HRA 95603
>
>Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering
>163/167, 3543 AS Utrecht, Niederlande
>Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
>Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
> Oracle is committed to developing
>practices and products that help protect the environment

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining

2016-09-28 Thread Michael Haupt 
Hi Claes,

yes please. Thumbs up. :-)

Best,

Michael

> Am 28.09.2016 um 13:48 schrieb Claes Redestad :
> 
> Hi,
> 
> as discussed recently on hotspot-compiler-dev[1], having a private class with 
> no default constructor can lead to C2 failing to inline, due to the synthetic 
> bridge constructor using a dummy argument of an uninitialized class. This is 
> really a problem in C2, as well as something which could ultimately be 
> resolved by nestmates...
> 
> However, there is an easy workaround in adding an empty package-private 
> constructor. In the most recently found case - a microbenchmark stressing 
> MethodHandles.iteratedLoop - adding this to ArrayList$Itr lead to a 2.5-3x 
> speedup.
> 
> This is me asking nicely to do a quick-fix for this in 
> java.util.ArrayList$Itr now:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166840
> Webrev: http://cr.openjdk.java.net/~redestad/8166840/webrev.01/
> 
> Thanks!
> 
> /Claes
> 
> [1] 
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment