amogh-jahagirdar commented on code in PR #16747: URL: https://github.com/apache/iceberg/pull/16747#discussion_r4017807417
########## core/src/main/java/org/apache/iceberg/mumbling/MumblingBitmap.java: ########## @@ -0,0 +1,168 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.iceberg.mumbling; + +import java.nio.ByteBuffer; +import org.apache.iceberg.relocated.com.google.common.base.Preconditions; + +/** + * Read-only view of a Mumbling compressed bitmap stored in a {@link ByteBuffer}. + * + * <p>The bitmap is lazy: no decoding is done at construction time. On the first call to {@link + * #isSet}, the PFOR-encoded descriptor array is decoded and used to build an offsets array that + * maps each container index to its absolute byte position in the buffer. This offsets array is the + * only derived state kept by this class. + * + * <p>Format (all integers unsigned, little-endian): + * + * <ul> + * <li>Header (6 bytes): version (1), cardinality (3), container count (2) + * <li>Descriptor array: PFOR-encoded, one byte per container + * <li>Containers: concatenated sparse (0–31 bytes) or dense (32 bytes) containers + * </ul> + */ +class MumblingBitmap { + private static final int VERSION = 1; + private static final int HEADER_SIZE = 6; + private static final int DENSE_CONTAINER_BIT = 0b0010_0000; + + private final ByteBuffer data; + private final int cardinality; + private final int containerCount; + private int[] descriptors = null; + private int[] offsets = null; Review Comment: Yeah, I think locking is probably overkill. >Maybe we should at least update these arrays at once, after they are initialized? That seems reasonable? This seems better yeah. Though with non-volatile fields, assigning them together doesn't quite guarantee another thread sees the expected contents, it could see the reference set but the array values stale. One possible case is if we ever decide to scan a single manifest's entries in parallel, we would know that every worker thread would have the same reference conetents of the DV (or any other kinds of cases around caching or prefetching inline DV contents from the root). Though we'd need to have some really huge leaves for paralellism to be useful honestly so maybe it's not a valid case. So I'm mostly thinking that if it's easy to have these guarantees without relying on the 1 thread reading a manifest assumption, it's a bit more robust. It's most likely a non-issue as we probably would only have 1 thread per manifest like we do today, so not a blocker from my side just wanted to think through it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
