Re: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at runtime [v5]

2022-12-07 Thread Alan Bateman
On Tue, 6 Dec 2022 15:44:28 GMT, Doug Simon wrote: >> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 106: >> >>> 104: } >>> 105: if (props.get("oome") != null) { >>> 106: throw new OutOfMemoryError("forced OOME"); >> >> I don't think code in

Re: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at runtime [v5]

2022-12-07 Thread Alan Bateman
On Tue, 6 Dec 2022 15:44:04 GMT, Doug Simon wrote: >> src/java.base/share/classes/jdk/internal/vm/TranslatedException.java line 44: >> >>> 42: */ >>> 43: @SuppressWarnings("serial") >>> 44: final class TranslatedException extends Exception { >> >> Would it be possible to re-format this to

Re: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at runtime [v5]

2022-12-07 Thread Alan Bateman
On Tue, 6 Dec 2022 16:50:47 GMT, Doug Simon wrote: >> This parameter exists to allow a caller to pass in a `Properties` object >> that is guaranteed to have only String keys and so does not need the extra >> filtering done in this method. I'll refactor the code to make it clearer. > >

Re: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at runtime [v5]

2022-12-06 Thread Doug Simon
On Tue, 6 Dec 2022 15:41:20 GMT, Doug Simon wrote: >> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 66: >> >>> 64: * only contains String keys and values. >>> 65: */ >>> 66: private static byte[] serializePropertiesToByteArray(Properties p, >>>

Re: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at runtime [v5]

2022-12-06 Thread Doug Simon
On Tue, 6 Dec 2022 13:02:40 GMT, Alan Bateman wrote: >> Doug Simon has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - incorporate review feedback [skip ci] >> - removed hard-coded module name [skip ci] > >

Re: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at runtime [v5]

2022-12-06 Thread Alan Bateman
On Tue, 6 Dec 2022 09:47:29 GMT, Doug Simon wrote: >> Libgraal is compiled ahead of time and should not need any JVMCI Java code >> to be dynamically loaded at runtime. Prior to this PR, this is not the case >> due to: >> >> * Code to copy system properties from the HotSpot heap into the

Re: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at runtime [v5]

2022-12-06 Thread Doug Simon
> Libgraal is compiled ahead of time and should not need any JVMCI Java code to > be dynamically loaded at runtime. Prior to this PR, this is not the case due > to: > > * Code to copy system properties from the HotSpot heap into the libgraal > heap. This is in >