Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prepare for java 8,11 3.0.0 #190

Merged
merged 10 commits into from
Jul 2, 2024
Merged

Prepare for java 8,11 3.0.0 #190

merged 10 commits into from
Jul 2, 2024

Conversation

leerho
Copy link
Contributor

@leerho leerho commented Jun 11, 2024

Prepares the java 8,11 code-base for a 3.0.0 release.

@leerho
Copy link
Contributor Author

leerho commented Jun 20, 2024

This is ready for review with a target version of DS-memory 3.0.0. There are quite a few changes -- all with the intent of moving to a java 8,11 API that resembles what the API will be in Java 17. It is not perfect, but a lot closer that what it was.
DS-memory 4.0.0 will be the version implemented using FFM-Panama. It is also pretty much ready to go.

I need to release this before I can release DS-java 6.1.0 which will still be java 8,11, and depend on this.
The DS-Java 6.1.0 is ready to go as soon as this gets done.
The DS-Java 7.0.0 (FFM-panama depending on ds-memory 4.0.0 is also pretty much ready to go.

@leerho leerho marked this pull request as ready for review June 20, 2024 15:37
Improved the toString methods.

Simplified BaseBuffer API.
And BaseBufferImpl to PositionalImpl.

Cleaned up some duplicate methods.

Improved some javadocs.
Corrected some tests that were referring to the wrong exception.
Copy link

@jmalkin jmalkin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a few very, very minor things.

We should try to move all the <i> stuff to <code> but that's not a priority for this PR.

* @param currentWritableMemory the current writableMemory of the client. It must be non-null.
* @param capacityBytes The capacity being requested. It must be &ge; 0.
* @param newCapacityBytes The capacity being requested. It must be &gt; the capacity of the currentWritableMemory.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does it need to be larger?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the MemoryRequestServer and the intent is to request a larger memory. It doesn't make sense to request a memory space smaller than what you already have.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we don't support the pattern of getting a smaller amount of additional memory while keeping the current memory?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not with this interface, and never have. If you want a separate smaller memory, use the regular allocate methods for that. This is explicitly for the case where a sketch runs out of its allocated memory

* {@link #map(File, long, long, ByteOrder) map(file, 0, file.length(), ByteOrder.nativeOrder())}.
* @param file the given file to map. It must be non-null, length &ge; 0, and readable.
* {@link #map(File, long, long, ByteOrder)
* map(file, 0, file.length(), scope, ByteOrder.nativeOrder())}.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

link has 4 parameters, example has 5. Make sure it points to the right place.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep. this is a javadoc comment bug and it occurred in 3 places. Will fix. I also searched the entire ds-memory repo for this bug and it is clean.

* @param capacityBytes the size of the mapped memory. It must not be negative.
* @param byteOrder the byte order to be used for the mapped memory. It must be non-null.
* @param file the given file to map. It must be non-null, readable and length &ge; 0.
* @param fileOffsetBytes the position in the given file in bytes. It must &ge; 0.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

must be ≥ 0

currently missing the word "be"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will Fix.

* @param capacityBytes the size of the desired memory in bytes. It must be &ge; 0.
* @return WritableMemory for this off-heap resource.
* @param capacityBytes the size of the desired memory in bytes.
* @return WritableMemory for this off-heap, native resource.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's worth specifying "byte order" explicitly so it's clear what "native" refers to.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this specific context I meant native=off-heap, but it is equally valid to mean native byte-order! This double use of "native" bugs me. But the double use also exists in Panama. I'm not sure what to do about this. I could go through the entire repo and check for all uses of "native" and make sure the context is clear.

sb.append("MemReq, hashCode : ").append(memReqStr).append(LS);
sb.append("Valid : ").append(state.isValid()).append(LS);
sb.append("MemReqSvr, hashCode : ").append(memReqStr).append(LS);
sb.append("Valid : ").append(state.isAlive()).append(LS);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the text be changed to Alive to reflect the method name?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, and I will check the whole repo for this substitution.

@@ -96,15 +96,15 @@ public void checkArrayWrap() {
assertEquals(v, i);
}
// check 0 length array wraps
Memory memZeroLengthArrayBoolean = WritableMemory.writableWrap(new boolean[0]);
//Memory memZeroLengthArrayBoolean = WritableMemory.writableWrap(new boolean[0]);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should just remove these entirely instead of commenting them out

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will remove.

/**
* Example of how to use the MemoryRequestServer with a memory hungry client.
*
* <p>Note: this example only works with Java 17.</p>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this accurate? If so, is it excluded from running?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not accurate. Removed. It works fine in Java8

1. I have corrected the javadocs and code comments to use "off-heap"
instead of "direct" or "native". However, I decided not to change the
use of "Direct" in existing method calls or in the /internal/ directory.
That would cause a huge number of changes (100's).

2. I have corrected the javadocs and code comments to use "alive" or
"isAlive" instead of "valid" or "isValid". However, I decided not to
change the word "Valid" in the /internal/ directory.  That would cause a
huge number of changes (100's).
@leerho leerho requested a review from jmalkin July 2, 2024 19:11
Copy link

@jmalkin jmalkin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thankfully a single commit so I was able to look at that diff rather than try to figure out what changed in the entire PR :)

@leerho leerho merged commit 9fa68a7 into master Jul 2, 2024
1 check passed
@leerho leerho deleted the prepare_java8_11_3.0.0 branch July 2, 2024 21:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants